Már nem a kódírás, hanem a programozást kiszolgáló infrastruktúra a szűk keresztmetszet a fejlesztésekben. A Claude és a hozzá hasonló kódolástámogató MI-k olyan tempóban ontják magukból a commitokat és a build requesteket, hogy azzal a fejlesztési infrastruktúra nem tud lépést tartani. Már korábban is voltak jelek arra, hogy ez probléma lesz.

A GitHubon idén tavasszal kétszer volt súlyos szolgáltatáskiesés, de a kisebbek is egyre gyakoribbá váltak. A problémák szaporodását egy blogbejegyzésben azzal magyaráztak, hogy exponenciálisan nő a tárhelyek létrehozása, a pullrequest-aktivitás, az API-használat, az automatizálás és a nagyméretű tárhelyekre kiterjedő munkaterhelés. 2025-ben még azt tervezték, hogy tízszeresére növelik a repository kapacitását, de idén már februárban kiderül, hogy legalább harmincszorosára kellene bővíteni ahhoz, hogy lépést tudjanak tartani az igényekkel.

Június elején Kyle Daigle, a GitHub operatív igazgatója azzal illusztrálta a The New Stacknek a terhelés drámai növekedését, hogy míg 2025-ben egymilliárd commitot kellett feldolgozni, júniusban már havi 1,4 milliárdot. Csak az ügynökök havi 17 millió pull requestet hoznak létre havonta.

A szolgáltatás hivatalos státuszkövető oldala szerint jól bírták a terhelésnövekedést. A hobbiprojektként indított Missing GitHub Status Page azonban azt hozta ki, hogy a repository rendelkezésre állása február és április között bezuhant: februárban 87,2, márciusban 87,8 százalék volt. A mélypontot áprilisban érte el, akkor 78,3 százalékos rendelkezésre állást mértek. Mióta pedig a szolgáltatás rendezte a sorait, 92 és 95 százalék között ingadozik az elérhetősége. (Az eltérés valószínűleg a mérési metódusból ered, pl. milyen hosszú szolgáltatáskiesést vesznek bele a statisztikába.)

Az Anthropicnak is lépnie kellett

Most ugyanezt a helyzet egyik felelőse, az Anthropic is megerősítette – ráadásul saját példájával. Egy tegnap közzétett blogbejegyzésében arról számolt be, hogy idén májusában még csak átlagosan napi 2500 kódmódosítást olvasztottak be a központi kódtárukba, szeptemberre már több mint 30 ezret.

Erre a növekedésre a hagyományos fejlesztőeszközöket nem készítették fel. A legnagyobb probléma, hogy a Git verziókezelő rendszer nem skálázható ugyanilyen ütemben. A Gitet decentralizált működésre optimalizálták: a fejlesztők helyi másolatokkal dolgoznak. Ez a legtöbb projektben jól működik, az Anthropic egyetlen központi kódtárban kezelt kódbázisánál azonban egyre nagyobb erőforrásigénnyel jár.

A vállalat fő fejlesztési ágának története önmagában csaknem 100 gigabájtot tesz ki, a tömörített munkapéldány mérete pedig meghaladja a 25 gigabájtot. A CI- (continuous integration, azaz folyamatos integrációs) folyamatok naponta mintegy 25 millió alkalommal kérnek le kódot, és ebben még nincsenek benne a fejlesztői környezetek, valamint a mesterségesintelligencia-ügynökök munkafolyamatai. Ez durva becsléssel napi több mint 600 petabájtnyi Git-forgalmat jelent. Az Anthropic tehát egyszerűen kinőtte a Git kínálta kereteket.

A vállalat korábban több száz belső Git-tükörrel és más optimalizálási módszerekkel próbálta kezelni a terhelést. A kódváltoztatások számának gyors növekedésével azonban ezek üzemeltetése is egyre bonyolultabbá vált. A hagyományos fejlesztési infrastruktúra tehát már nem pusztán lassította a munkát, hanem a mesterséges intelligencia által lehetővé tett termelékenységnövekedés egyik fő korlátjává vált.

Hosszú felvezetés után a csattanó: saját verziókövető

Az Anthropic végül megépítette a Scion nevű saját verziókezelő rendszerét, amihez fejlesztett egy kódellenőrzőt (Antique) és más kiegészítőket. A Sciont eleve olyan környezetre tervezték, amelyben a kliensek túlnyomó része folyamatosan online működő MI-ügynök vagy automatizált feladat. A rendszer ezért szerveroldalon végzi a verziókezelési műveletek jelentős részét, és csak a ténylegesen szükséges adatokat továbbítja. Így elkerülhető, hogy minden munkafolyamatnak a teljes kódtárat le kelljen töltenie és karbantartania.

A cég szerint az eredmények jók: az új infrastruktúra processzor- és memóriaigénye a korábbi Git-tükrözési megoldásokéhoz képest századára-kétszázadára csökkent, míg a CI-folyamatok akár százszorosukra is gyorsultak.