Anthropic, Cursor, GitHub i OpenAI opracowują cztery podejścia do skalowania Gita dla systemów agentycznych
12 listopada 2026 · Czas czytania: 2 min
Cztery wiodące firmy zajmujące się sztuczną inteligencją i narzędziami programistycznymi opracowują alternatywne systemy zarządzania wersjami, aby zastąpić tradycyjnego Gita w środowiskach, gdzie agenci autonomiczni generują ogromne ilości zmian kodu. Każda z firm uznała, że rozproszone przechowywanie pełnej historii Gita na każdym węźle nie jest już wykonalne w skali agentycznej.
Anthropic całkowicie porzucił Gita na rzecz wewnętrznego systemu o nazwie Scion, opracowanego w ciągu pięciu miesięcy. Monorepo firmy doświadczył gwałtownego wzrostu z około 2500 scalań dziennie w maju 2026 roku do ponad 30 000 we wrześniu. Przy głównej historii zbliżającej się do 100 gigabajtów i prawie 25 milionach codziennych pobrań dla ciągłej integracji, tradycyjne użycie Gita wymagałoby przesyłania ponad 600 petabajtów danych dziennie. Scion zastępuje zdecentralizowany model Gita architekturą, w której serwer obsługuje operacje wymagające dużych zasobów, takie jak scalenia i rebazy, podczas gdy klient lokalny działa jako lekka warstwa zarządzająca ograniczoną pamięcią podręczną. Zestaw zmian Sciona przechowuje tylko listę zmodyfikowanych plików w stosunku do pierwszego rodzica, a nie pełne drzewo obiektów jak Git. Firma twierdzi, że ta infrastruktura zużywa 200 razy mniej zasobów obliczeniowych i pamięci niż poprzednia flota Gita, a ciągła integracja zyskała 25 procent pojemności procesora, przy czym pobrania odbywają się teraz w ciągu kilku sekund.
Cursor zachował natywny format i narzędzia Gita na lokalnych dyskach NVMe, ale opracował alternatywny silnik o nazwie Continuity, aby przezwyciężyć ograniczenia poprzedniej architektury replikacji. Continuity opiera się na koncepcji dzienników zapisu z wyprzedzeniem na S3, gdzie każde push stanowi odrębny wpis dziennika. Żadne push nie jest potwierdzane, dopóki nie zostanie utrwalone na S3. Repliki na lokalnych dyskach NVMe działają jedynie jako pamięci podręczne, które są ponownie zasilane z dziennika. Każdy węzeł może odbierać zapisy i działać jako główny, a atomowość operacji porównania i zamiany na S3 gwarantuje integralność. System osiąga 120 pushów na sekundę na S3 Standard i ponad 300 z S3 Express One Zone, wykazując liniowy wzrost wydajności odczytu do 100 replik bez wpływu na zapisy.
OpenAI opracował system o nazwie Pando w ciągu dziesięciu tygodni w odpowiedzi na dramatyczne wyzwania skalowania. Liczba commitów trafiających do głównej gałęzi monorepo firmy wzrosła około 25-krotnie w ciągu dwóch lat, a niezawodność kontroli wersji spadła poniżej 90 procent. Pando odrzuca wymóg, aby serwer dostarczał spójny stan wszystkich gałęzi w danym momencie podczas klonowania lub pobierania. Zamiast tego implementuje model spójności przyczynowej, w którym aktualizacje każdej gałęzi są niezależne i serializowalne indywidualnie. Klient pobierający gałąź respektuje historię autora, który ją utworzył, bez narzucania globalnego porządku z niezwiązanymi gałęziami. Pando ponownie wykorzystuje istniejące niezmienne pliki pakietów zamiast dynamicznego obliczania różnic i kompresji plików pakietów na zamówienie, co eliminuje znaczne obciążenie serwera.