Przeprojektowanie kontroli wersji w Anthropic: Claude przerósł Git
Anthropic zastąpił Git po tym, jak Claude pomógł zwiększyć liczbę merge’y w jego monorepo z około 2 500 dziennie w maju 2026 roku do ponad 30 000 we wrześniu. Ten wzrost sprawia, że przeprojektowanie kontroli wersji w Anthropic jest czymś więcej niż historią migracji infrastruktury. Pokazuje, co dzieje się, gdy AI generuje kod szybciej, niż systemy wytwarzania oprogramowania potrafią go bezpiecznie przyswoić.
Firma zbudowała Scion, wewnętrzny system kontroli wersji zaprojektowany wokół działających online agentów, operacji po stronie serwera i selektywnego dostępu do gigantycznego repozytorium. Siedmiu inżynierów stworzyło również Antique, nowy system przeglądu kodu, oraz kilka powiązanych usług. Anthropic podaje, że zespół ukończył migrację w pięć miesięcy.
Kluczowy konflikt nie dotyczy po prostu Scion kontra Git. Chodzi o produkcję kodu na skalę agentów kontra praktyki programistyczne zaprojektowane wokół ludzkiej uwagi. Google i Meta zbudowały już wyspecjalizowane systemy dla ogromnych monorepozytoriów. Anthropic dotarł do podobnego miejsca pod wpływem innego źródła presji: rojów agentów programistycznych, które nigdy nie muszą pracować offline.
Przeprojektowanie kontroli wersji w Anthropic zaczęło się od 30 000 dziennych merge’y
Anthropic nie porzucił Git dlatego, że jego inżynierowie nie lubili Git. Porzucił go, ponieważ Claude zmienił charakter i skalę ruchu w repozytorium.
Według relacji inżynierskiej Anthropic, liczba dziennych merge’y wzrosła ponad dziesięciokrotnie między majem a wrześniem 2026 roku. Firma przedstawia ten wzrost jako trwały popyt, a nie krótkotrwały skok związany z migracją.
Wynikające z tego obciążenie wykraczało daleko poza tworzenie commitów. Historia głównej gałęzi Anthropic zbliżyła się do 100 GB, podczas gdy skompresowana kopia robocza przekroczyła 25 GB. Ciągła integracja, czyli CI, wykonywała około 25 milionów checkoutów kodu dziennie, zanim uwzględniono środowiska deweloperskie, piaskownice agentów i zadania badawcze.
Jak wyliczyło Anthropic, naiwne pobieranie tych checkoutów generowałoby ponad 600 petabajtów dziennego ruchu Git. Firma wykorzystywała płytkie klony, selektywne checkouty, snapshoty repozytorium i kilkaset wewnętrznych mirrorów Git, aby kontrolować ten koszt.
Środki te kupiły czas, ale repozytorium nadal zmieniało się szybciej. Snapshoty stawały się nieaktualne między odświeżeniami. Częściowe klony komplikowały również operacje takie jak przeszukiwanie historii, diffy i blame, które wskazuje, kto ostatnio zmienił daną linię.
Problem firmy wynikał z niedopasowania między mocnymi stronami Git a dominującymi klientami Anthropic. Git zapewnia każdemu klonowi wystarczającą ilość informacji, aby działał jako samodzielne repozytorium. Taka konstrukcja wspiera pracę offline, lokalną historię i zdecentralizowaną współpracę.
Agenci Anthropic i zautomatyzowane zadania były już online. Nie potrzebowali pełnej lokalnej historii ani możliwości działania jako niezależne serwery. Mimo to infrastruktura wielokrotnie dystrybuowała i utrzymywała dane repozytorium tak, jakby każdy klient był programistą korzystającym z laptopa.
Scion odwraca to założenie. Jego serwer wykonuje zapytania do historii, tworzy commity, oblicza diffy oraz obsługuje merge’e i rebase’y. Lekki klient utrzymuje ograniczony cache i materializuje tylko pliki wymagane przez bieżące zadanie.
Różnica ma znaczenie, gdy zadanie badawcze potrzebuje jednego katalogu zamiast całego monorepozytorium. Jest istotna także wtedy, gdy usługa CI potrzebuje wyłącznie diffu lub obliczenia merge base. Scion może odpowiedzieć na takie żądania przez API, bez tworzenia tradycyjnej kopii roboczej.
Według Anthropic nowa architektura przyniosła znaczące wewnętrzne korzyści. Każda warstwa cache’u ma podobno utrzymywać współczynnik trafień powyżej 99 procent. Infrastruktura zużywa 200 razy mniej CPU i pamięci niż poprzednia flota mirrorów Git.
Anthropic podaje również, że checkouty CI i zadań badawczych skróciły się z minut do sekund. Zmiana zwróciła 25 procent mocy CPU CI do szerszej puli obliczeniowej.
Są to pomiary raportowane przez firmę, pochodzące z wewnętrznego systemu. Zewnętrzni badacze nie mogą ich odtworzyć bez dostępu do obciążeń, repozytoriów i infrastruktury Anthropic. Mimo to liczby wyjaśniają, dlaczego kolejna runda strojenia Git przestała wyglądać na wystarczającą.
System musiał obsługiwać więcej niż duże repozytorium. Musiał obsługiwać repozytorium, którego główni autorzy, czytelnicy i zautomatyzowani odbiorcy działali z prędkością maszyn.
Claude uczynił infrastrukturę programistyczną wąskim gardłem
Prawdziwe znaczenie Scion polega na tym, że generowanie kodu przestało być w Anthropic zasobem deficytowym. Ograniczeniami stały się zdolność do przeglądu, infrastruktura i osąd.
Asystenci AI do programowania początkowo mieścili się w znanym procesie wytwarzania oprogramowania. Człowiek prosił o funkcję, sprawdzał wynik, uruchamiał testy i zgłaszał pull request. Asystent zwiększał szybkość pisania pojedynczego programisty, nie zmieniając otaczającego go systemu.
Anthropic opisuje bardziej zaawansowany model działania. Claude ma podobno iterować w pętlach badawczych, optymalizować złożone programy, tworzyć usługi, monitorować komponenty produkcyjne i pomagać w dużych migracjach. Każda z tych aktywności może tworzyć nowe zmiany albo wymagać nowego dostępu do repozytorium.
Taki wzorzec tworzy zwielokrotnioną presję. Jeden agent może uruchomić kolejne zadanie, podczas gdy wcześniejsza zmiana przechodzi przez testowanie. Zautomatyzowani recenzenci mogą żądać poprawek, które generują dodatkowe zmiany. Systemy CI tworzą następnie checkouty i wywołują więcej zapytań do repozytorium dla każdego kandydata.
Wykres wyróżniony przez Simona Willisona pokazuje gwałtowny wzrost w 2026 roku. Willison powiązał przyspieszenie z nowszymi wewnętrznymi generacjami modeli Anthropic, ostrożnie odróżniając ich wewnętrzną dostępność od dat publicznych premier.
Anthropic przedstawia bardziej szczegółowe powiązanie. Podaje, że rozwój Scion rozpoczął się mniej więcej wtedy, gdy Claude Mythos Preview i Claude Tag stały się dostępne wewnętrznie. Modele te miały zwiększyć potrzebę Scion, jednocześnie pomagając zespołowi go zbudować.
Jeden z przykładów dotyczył potoku przenoszącego dane z Git do Scion. Inżynierowie Anthropic napisali początkowy prototyp ręcznie. Wczesna wewnętrzna wersja Claude Mythos Preview miała następnie przepisać potok przy niewielkiej dodatkowej liczbie wskazówek.
Zastąpione rozwiązanie zużywało podobno 20 razy mniej pamięci i działało cztery razy szybciej. Anthropic twierdzi, że zachowało ukryte wymagania dotyczące kolejności ingestii i struktur danych. To uderzające twierdzenie, ale pozostaje wynikiem opisanym przez firmę, a nie niezależnym benchmarkiem.
Szerszą pętlę sprzężenia zwrotnego łatwiej ustalić. Szybsze generowanie kodu zwiększyło aktywność repozytorium. Aktywność ta uzasadniła nową infrastrukturę. Claude pomógł następnie zbudować tę infrastrukturę, która usunęła kolejne ograniczenie generowania kodu.
Ta pętla wywiera presję na każdą część cyklu życia wytwarzania oprogramowania. Usługa budowania obsługująca zmiany w tempie ludzkiej pracy może stać się kosztowna, gdy agenci tworzą tysiące współbieżnych zadań. Kolejka przeglądów staje się mniej użyteczna, jeśli repozytorium przesuwa się o setki zmian, gdy uruchomiony jest zestaw testów.
Dostęp do wiedzy również staje się częścią ograniczenia. Agenci potrzebują specyfikacji, decyzji architektonicznych, historii incydentów i kontekstu własności, a nie tylko plików źródłowych. Zespoły budujące podobne procesy potrzebują przeszukiwalnej bazy wiedzy inżynierskiej obok szybszej infrastruktury kodu.
Anthropic podaje, że obecnie korzysta z trwałych monitorów Claude zwanych „superfans” dla poszczególnych komponentów Scion. Agenci ci obserwują telemetrię i logi przez dedykowane kanały Slack. Tradycyjne alerty pozostają aktywne, podczas gdy agenci szukają wzorców, które mogą umknąć stałym progom.
Ten model operacyjny przesuwa pracę inżynierską na wyższy poziom. Ludzie definiują niezmienniki, wybierają granice architektoniczne, interpretują awarie i decydują, co powinno trafić na produkcję. Agenci generują implementacje i analizują telemetrię w ramach tych granic.
Zmiana nie eliminuje inżyniera. Zmienia deficytową umiejętność z tworzenia kodu na decydowanie, który kod zasługuje na istnienie.
Scion zastępuje model offline Git usługą na skalę agentów
Scion zyskuje przepustowość, rezygnując z definiującej Git symetrii: klient nie nosi już pełnej inteligencji repozytorium.
Commity Git zawierają wskaźniki do kompletnych drzew katalogów. Klienci wymieniają skompresowane kolekcje obiektów zwane packfile’ami, dzięki czemu lokalne repozytoria zachowują historię i działają niezależnie. Ten model nadal jest odpowiedni dla większości projektów programistycznych.
Scion używa changesetu, wpisu w dzienniku write-ahead rejestrującego zmienione pliki względem rodzica. Zawartość plików jest kompresowana, adresowana zawartością i przechowywana osobno. Adresowanie zawartością oznacza, że klucz przechowywania wynika z danych, dzięki czemu niezmienne obiekty można bezpiecznie cache’ować.
Changesety są tworzone na serwerze i stają się dostępne w całym systemie. Nie wymagają od klienta skonstruowania i przesłania dużego packfile’a. Pozwalają też uniknąć przesuwania globalnego wskaźnika gałęzi podczas każdej operacji commitu.
Scion nadal obsługuje referencje, czyli wskaźniki takie jak gałęzie i tagi. Anthropic zniechęca jednak do używania większości referencji poza główną linią i gałęziami wydań. Stan wymagający globalnej koordynacji staje się coraz droższy wraz ze wzrostem liczby commitów.
System oblicza informacje o historii osobno, jako dane pochodne. Buduje dedykowane indeksy dla historii plików, blame, kopiowania oraz relacji w obrębie grafu commitów. Indeksy te mogą być generowane natychmiast albo odłożone do czasu, gdy zażąda ich odbiorca.
To rozdzielenie pozwala Anthropic zmienić indeks bez zmieniania każdego klienta. Umożliwia też usłudze unikanie obliczania danych, których nie potrzebuje żadne zadanie.
Protokół checkoutu Scion opiera się na tej samej zasadzie. Klienci proszą o określone drzewa i obiekty plików, zamiast negocjować pełny obraz tego, co już posiadają. Regionalne serwery cache mogą obsłużyć większość żądań, ponieważ przechowywane obiekty nigdy się nie zmieniają.
Demon na każdym węźle obliczeniowym współdzieli obiekty cache’owane między lokalnymi zadaniami. Regionalne usługi cache znajdują się następnie między tymi demonami a autorytatywnymi serwerami Scion. Anthropic wymusza tę hierarchię, aby awaria regionalnego cache’u nie przeciążyła usługi centralnej.
Selektywne checkouty żądają tylko wybranych katalogów. Wirtualizowane checkouty tworzą pliki, gdy proces je odczytuje. Niektóre zadania całkowicie pomijają system plików i pytają API o diff, wynik historii lub merge base.
Projekt ten przypomina wcześniejsze odpowiedzi na skalę monorepozytoriów. Google opisało Piper jako część infrastruktury wspierającej ogromną, scentralizowaną bazę kodu. Opublikowana analiza monorepozytoriów udokumentowała zalety współdzielonego kodu, ujednoliconych zależności i zmian obejmujących całą organizację.
Meta wybrała inną drogę z Sapling, systemem zachowującym znane rozproszone koncepcje kontroli wersji przy jednoczesnym skalowaniu do jej wewnętrznego repozytorium. Meta podaje, że jej serwer może obsłużyć dziesiątki milionów plików, commitów i gałęzi. Publiczny projekt Sapling obsługuje również repozytoria Git i lokalne procesy pracy programistów.
Scion czerpie lekcje z obu tych historii, ale jego główne założenie jest węższe. Dominujący klient jest zawsze online, często zautomatyzowany i raczej nie potrzebuje całego repozytorium. To sprawia, że serwer staje się bazą danych kontroli wersji i usługą obliczeniową, a nie partnerem synchronizacji.
Kompromisem jest zależność. Klient Scion nie może odtworzyć pełnego działania Git w trybie offline, ponieważ celowo przechowuje mniej danych i wykonuje mniej operacji lokalnie. Awaria sieci lub centralnej usługi ma więc inne znaczenie.
Koszty migracji wykraczają również poza klienta wiersza poleceń. Anthropic musiał zbudować wyszukiwanie kodu, kontrolę tożsamości i dostępu, integracje CI oraz Antique. Firma wdrażająca ten sam projekt musiałaby zastąpić znaczną część swojej platformy programistycznej.
To wyjaśnia, dlaczego Scion nie jest alternatywą Git od Anthropic dla zwykłych zespołów. To pionowo zintegrowany system dla jednego wyjątkowego obciążenia.
Szybsze mergowanie sprawia, że code review staje się trudniejszym problemem
Nierozstrzygnięte pytanie nie brzmi, czy Scion może przyjąć 30 000 zmian. Chodzi o to, czy Anthropic może zachować odpowiedzialność przy takim tempie.
Anthropic twierdzi, że każda zmiana w Scion nadal otrzymuje ludzką recenzję. Recenzenci koncentrują się teraz na intencji zmiany, zamiast czytać każdą linię. Ten wybór wynika ze skali, ale przesuwa też zaufanie w stronę testów, wyjaśnień agentów i zautomatyzowanej analizy.
Przegląd intencji pyta, czy proponowana zmiana odpowiada celom systemu i zasadom architektonicznym. Przegląd linii pyta, czy jej implementacja działa poprawnie. Silne automatyczne kontrole mogą łączyć te poziomy, ale żaden zestaw testów nie obejmuje wszystkich ukrytych wymagań.
Anthropic przyznaje, że inżynierowie często musieli mówić Claude „nie”. Agenci czasami wybierali lokalnie wiarygodne wzorce, które naruszały ograniczenia obejmujące cały system. Niektóre wygenerowane komponenty próbowały liniowo skanować log commitów, zamiast odpytywać Antique o autorytatywny czas mergowania.
Recenzja adversarialna ujawniła kolejny tryb awarii. Claude mógł reagować na hipotetyczne ryzyka nadmierną walidacją i złożonością. Ludzcy inżynierowie musieli decydować, kiedy programowanie defensywne przestawało ulepszać system.
Te przykłady komplikują proste twierdzenie, że lepsze modele bezpośrednio tworzą lepsze oprogramowanie. Agenci mogą znajdować wartościowe optymalizacje, jednocześnie tworząc niepotrzebne mechanizmy. Duża skala produkcji wzmacnia oba te zachowania.
Anthropic twierdzi, że jego zespół stworzył dla Scion symulacje, fuzz testing i limity szybkości. Fuzzing dostarcza nieoczekiwane dane wejściowe, aby ujawnić defekty, podczas gdy hermetyczne symulacje odtwarzają zachowanie infrastruktury w odizolowanych środowiskach. Te mechanizmy kontrolne dostarczają silniejszych dowodów niż same liczby merge’ów.
Mimo to wolumen merge’ów nie jest miarą jakości. Zmiana może być niewielka, eksperymentalna, wygenerowana, cofnięta albo niezwiązana z postępem widocznym dla klientów. Trzydzieści tysięcy codziennych zmian ujawnia niezwykłą aktywność, ale nie dowodzi niezależnie ani niezawodności, ani wartości biznesowej.
Publiczne reakcje programistów koncentrowały się na tym rozróżnieniu. W dyskusji na Hacker News niektórzy czytelnicy zastanawiali się, czy Anthropic nie powinien ponownie rozważyć swojego monorepo. Inni argumentowali, że intencja, pochodzenie zmian i ciągła weryfikacja mają większe znaczenie niż tradycyjna mechanika commitów.
Inżynier Anthropic odpowiadający w tym wątku bronił spójnych narzędzi monorepo i atomowych zmian. Ten sam inżynier wyjaśnił, że Scion blokuje konflikty tekstowe, ale nie może wyeliminować semantycznych konfliktów między równoległymi zmianami.
Konflikt semantyczny występuje, gdy dwie indywidualnie poprawne edycje razem powodują nieprawidłowe działanie. Jedna zmiana może modyfikować funkcję i aktualizować jej wywołania, podczas gdy inna jednocześnie dodaje nowe wywołanie. Pliki mogą zostać połączone bez problemów, mimo że wynikowy program jest błędny.
Tradycyjne kolejki merge’ów ograniczają to ryzyko, testując proponowany stan repozytorium przed przyjęciem kolejnej partii. Anthropic twierdzi, że globalna blokada repozytorium staje się niepraktyczna, gdy setki lub tysiące zmian trafiają do niego podczas jednego uruchomienia testów.
Firma przesunęła inwestycje w stronę testów po mergowaniu i przed wdrożeniem. Takie podejście pozwala utrzymać przepustowość repozytorium, podczas gdy kontrole określają, co może bezpiecznie trafić na produkcję.
To centralny kompromis w przeprojektowaniu kontroli wersji w Anthropic. Scion usuwa serializację z kontroli wersji, ale pewna forma serializacji nadal istnieje przy wdrożeniu, migracji danych lub w punktach ludzkiego podejmowania decyzji. Ryzyko się przemieszcza, zamiast znikać.
Anthropic twierdzi, że Claude może rozwiązywać równoczesne konflikty szybciej, niż ludzie potrafią je zidentyfikować. Ta odpowiedź dotyczy szybkości naprawy, a nie kosztu niewykrytej interakcji. Bezpieczeństwo zależy od tego, jak szybko monitoring wykrywa problem i jak skutecznie systemy go izolują lub odwracają.
Pomagają kontrola dostępu na poziomie katalogów i semantyczne reguły zatwierdzania. Według Anthropic Antique może odróżnić zmianę zawierającą wyłącznie komentarz od wrażliwej zmiany logiki. Ludzka uwaga może wtedy skupić się na zmianach o większych konsekwencjach.
Pozostała luka w weryfikacji jest znaczna. Anthropic nie opublikował niezależnych wskaźników defektów, częstotliwości rollbacków, trendów incydentów ani proporcji zmian pisanych i recenzowanych przez agentów. Bez tych miar osoby z zewnątrz nie mogą porównać wzrostu przepustowości z późniejszym ryzykiem.
Najbardziej użyteczna lekcja dla innych zespołów nie polega więc na pogoni za liczbą merge’ów Anthropic. Polega na mierzeniu całej ścieżki od specyfikacji do wdrożenia. Przydatne wskaźniki obejmują defekty, które przedostały się dalej, opóźnienie recenzji, nieudane zmiany, rollbacki, powieloną pracę i czas poświęcony na odzyskiwanie kontekstu.
Osobisty workflow AI może pomóc inżynierom zachować decyzje i pochodzenie informacji, gdy agenci generują więcej materiału. Przechowywany kontekst pomaga jednak tylko wtedy, gdy zespoły łączą go z egzekwowalnymi testami, odpowiedzialnością i polityką recenzji.
Co eksperyment Anthropic z kontrolą wersji zmieni dalej
Kolejna faza sprawdzi, czy rozwój oprogramowania w skali agentów stanie się przenośnym modelem inżynierii, czy pozostanie kosztownym wyjątkiem Anthropic.
Pierwszym sygnałem wartym obserwacji jest zapowiadana przez Anthropic dyskusja o Antique. Kontrola wersji wyjaśnia, jak zmiany są przechowywane i pobierane, ale code review określa, jak intencja, odpowiedzialność i zatwierdzanie przetrwają ekstremalny wolumen.
Szczegóły modelu recenzji Antique wzmocniłyby argument Anthropic, gdyby pokazały wyraźne pochodzenie zmian i zależną od ryzyka interwencję człowieka. Argument osłabłby, gdyby recenzja opierała się głównie na podsumowaniach modelu bez mierzalnej walidacji.
Drugim sygnałem jest jakość oprogramowania w czasie. Twierdzenia Anthropic dotyczące infrastruktury zyskają na wadze, jeśli firma opublikuje wskaźniki rollbacków, defektów, które przedostały się dalej, incydentów usługowych lub innych miar rezultatów obok przepustowości merge’ów.
Stabilna lub rosnąca niezawodność wspierałaby tezę, że agenci mogą zwiększać wolumen zmian bez proporcjonalnego zwiększania ryzyka. Wzrost regresji lub awaryjnych napraw sugerowałby, że Scion przyspieszył produkcję szybciej niż zarządzanie ryzykiem.
Trzecim sygnałem jest reakcja platform Git i dużych organizacji inżynieryjnych. Większość firm nie zastąpi Git, ale może wdrożyć serwerowe API metadanych, zwirtualizowane przestrzenie robocze, recenzje uwzględniające ryzyko oraz lepsze wsparcie dla równoległych agentów.
Sapling od Meta już pokazuje jedną ścieżkę, która zachowuje kompatybilność ze znanymi workflow. Scalar Microsoftu i powiązane ulepszenia Git pokazują inną, rozszerzając Git dla dużych repozytoriów zamiast zastępować jego model danych.
Samo Anthropic oczekuje, że te presje rozprzestrzenią się w ciągu sześciu do dwunastu miesięcy. Ta prognoza jest oceną firmy, a nie zmierzonym trendem rynkowym. Jej znaczenie zależy od tego, czy inne organizacje osiągną podobne limity bez wewnętrznego dostępu Anthropic do tokenów i nietypowej koncentracji użycia Claude.
Scion wprowadza również strategiczną zależność, której konkurenci mogą unikać. Anthropic kontroluje model, usługę repozytorium, powierzchnię recenzji, agentów obserwowalności i workflow wdrożeniowy. Ta integracja przyspiesza iterację, ale utrudnia odtworzenie lub zastąpienie środowiska programistycznego.
Dla większości organizacji Git pozostanie rozsądnym domyślnym wyborem. Oferuje szeroką interoperacyjność, dojrzałe narzędzia, przenośną historię i odporność na pracę offline. Architektura Scion staje się atrakcyjna dopiero wtedy, gdy ruch w repozytorium już przytłoczył te zalety.
Bardziej bezpośrednia zmiana dotyczy zarządzania. Liderzy inżynieryjni muszą przestać traktować wolumen wygenerowanego kodu jako cel. Większa produkcja tworzy wartość tylko wtedy, gdy zespoły potrafią ją bezpiecznie recenzować, testować, wdrażać, obserwować i cofać.
Programiści powinni również spodziewać się zmiany swojej pracy. Relacja Anthropic przypisuje większą wagę projektowaniu systemów, ograniczeniom architektonicznym, ewaluacji i odmowie. Inżynier w coraz większym stopniu definiuje granice, w których agent może działać szybko.
Przeprojektowanie kontroli wersji w Anthropic oferuje więc ostrzeżenie obok historii o wydajności. Gdy kod staje się tani, każda słaba specyfikacja, brakujący test i niejasna granica odpowiedzialności mogą zostać odtworzone z prędkością maszyny.
Użyteczne pytanie nie brzmi, czy twój zespół potrzebuje Scion. Brzmi ono: czy istniejące systemy recenzji, CI i wiedzy pozostałyby godne zaufania, gdyby agenci wyprodukowali dziesięć razy więcej zmian w następnym kwartale? Zmierz tę zdolność już teraz, zidentyfikuj pierwszą zawodzącą kontrolę i wzmocnij ją, zanim nadejdzie większy wolumen merge’ów.
