Így költöztette át a Cline 11 millió fejlesztőjét az új motorra

A régi monolit helyére közös SDK került

A Cline bővítményét 2024-ben, a Claude 3.5 Sonnet megjelenése után építették fel. Azóta a modellek és az úgynevezett agent harness-ek, vagyis az ügynökök működését vezérlő keretrendszerek is sokat változtak. A Cline közben VS Code-bővítményből JetBrains-plugin, parancssori eszköz, majd SDK lett.

A vállalat 2026. szeptember 2-i beszámolója szerint az újabb felületek már a Cline SDK-ra épültek, a legrégebbi és legszélesebb körben használt VS Code-bővítmény viszont egy saját, körülbelül 76 ezer soros monolitikus magot használt. Ebben minden új modell, szolgáltatói integráció vagy ügynökfejlesztés kézi munkát és új kiadást igényelt.

Az SDK-ra épülő új változat a Cline szerint automatizálja ennek a munkának jelentős részét. A vállalat emellett újraírt utasításokat, egyszerűsített működési ciklust, szorosabb kontextuskezelést, jobb visszajelzési és hibakezelési folyamatokat, valamint átdolgozott eszközkezelést említ. Ezek a változtatások minden Cline-felületen megjelenhetnek, mivel a futtatási környezetben találhatók.

Két bővítmény egy csomagban

A migráció első próbálkozása hónapokig tartott, a kiadás után azonban olyan súlyos hibák jelentkeztek, hogy a Cline azonnal visszaállította a korábbi verziót. A problémát az is nehezítette, hogy a VS Code Marketplace egyetlen kiadási lehetőséget kínál: a közzétett verziót mindenki megkapja, fokozatos terítésre, tesztcsoportra és azonnali visszavonásra nincs beépített mód. A verziószám csak előre léphet, ezért hiba esetén egy újabb kiadás elkészítésére és a frissítésre várni kell.

A Cline erre saját megoldást készített. Egyetlen kiadásba csomagolta a régi és az új bővítményt, valamint egy körülbelül 46 kilobájtos betöltőprogramot. A betöltő minden ablakindításkor eldönti, melyik változat fusson. A döntést egy PostHog-funkciójelző vezérli, amelyhez fokozatosan lehetett növelni az új verziót használók arányát.

Ha az új bővítmény aktiválása közben összeomlik, a betöltő automatikusan elindítja a régi változatot, és az adott gépet ott tartja. A funkciójelző egyben leállítókapcsolóként is működik, így szükség esetén a bevezetés aránya nullára csökkenthető. A két változat közösen használja a beállításokat, a hitelesítő adatokat és a feladatok tárolóját.

Hónapok helyett fokozatos ellenőrzés

A két kódág csak akkor működhetett ugyanabban a csomagban, ha azonos nézeteket és bővítmény-életciklushoz kapcsolódó belépési pontokat biztosítottak. A VS Code integrációjának jelentős része statikusan, a package.json fájlban szerepel, ezért a Cline buildfolyamata közös jegyzéket generált a két változatból. A rendszer hibával áll le, ha a nézetek vagy a beállítási sémák eltérnek.

A Cline minden mérési eseményhez hozzáadta, hogy a felhasználó a next vagy a legacy változatot futtatja. A vállalat a régi rendszert is felmérési adatokkal egészítette ki, hogy összehasonlítható legyen az új SDK-val. Kiemelt mutatóként kezelték a task.mistake_limit_reached eseményt. Ez akkor történik, amikor az ügynök három egymást követő hibát vét, majd emberi segítséget kér.

A bevezetési arányt közel egy hónapon keresztül emelték lassan. Több mint egy hétig körülbelül 50, 50 százalékos megosztást tartottak fenn, ezután állították 100 százalékra az új változat javára. A Cline szerint a lassú mechanizmus szándékosan szolgálta a biztonságot. Az új munkamenet csak a következő ablakindításkor lépett életbe, így egy futó feladat közben nem váltott motort a rendszer.

A történet a felhasználók számára azt jelenti, hogy a Cline a nagy háttérátalakítást úgy vezette be, hogy közben megtartotta a korábbi kezelőfelületet, megosztotta az állapotot a két változat között, és lehetőséget biztosított az automatikus visszaállásra. A vállalat szerint ezzel az SDK-alapú futtatási környezetet eljuttatta a több mint 11 millió fejlesztő által telepített VS Code-bővítménybe.