Anthropic opublikowało 13 października opis Scion — własnego systemu kontroli wersji, który w ciągu pięciu miesięcy zastąpił Gita w firmowym monorepo. Powód: liczba merge'y dziennie wzrosła z około 2500 w maju do ponad 30 000 we wrześniu, a Git przestał nadążać.
Najważniejsze w skrócie
- Merge'e dziennie: około 2500 w maju 2026, ponad 30 000 we wrześniu
- Historia głównej gałęzi: prawie 100 GB, skompresowana kopia robocza ponad 25 GB
- 25 mln checkoutów kodu dziennie na potrzeby CI — pobierane naiwnie dałyby ponad 600 PB ruchu git
- Zespół siedmiu osób zbudował Scion i narzędzie do code review Antique, migracja w pięć miesięcy
- Infrastruktura 200 razy mniejsza niż poprzednie mirrory gita, CI odzyskało 25% mocy CPU
Git jako system rozproszony w świecie agentów online
Git projektowano pod pracę offline — każdy klon jest kompletnym repozytorium. U Anthropic niemal wszyscy klienci to agenty i joby, które z definicji są online. Firma w szczycie utrzymywała kilkaset wewnętrznych mirrorów gita, ale snapshoty coraz bardziej odstawały od czoła gałęzi main.
Scion odwraca założenia: serwer tworzy commity, liczy diffy i odpowiada na pytania o blame oraz historię, a klient trzyma tylko ograniczony cache lokalny. Wzorem były Piper od Google i Sapling od Meta.
| Metryka | Maj 2026 | Wrzesień 2026 |
|---|---|---|
| Merge'e dziennie | ~2500 | 30 000+ |
| Historia gałęzi main | — | ~100 GB |
| Skompresowana kopia robocza | — | 25+ GB |
| Checkouty kodu dziennie (CI) | — | 25 mln |
Changeset, derived data i trzy warstwy cache
Jednostką pracy jest changeset?changeset: Pojedynczy zapis zmiany w Scionie: lista zmienionych plików plus wskaźniki do ich treści. Odpowiednik commita, ale tworzony po stronie serwera. — wpis w write-ahead logu z listą zmienionych plików i wskaźnikami content-addressed do skompresowanych treści w blob storage. Zapytania o blame czy historię ścieżki obsługują osobne struktury derived data?derived data: Dane wtórne wyliczane z historii zmian — na przykład blame albo historia jednej ścieżki. Liczone rekurencyjnie z rodziców changesetu i cache'owane., liczone rekurencyjnie z rodziców changesetu.
Checkouty idą przez trzy warstwy: scion-daemon na węźle, regionalny scion-cache i autorytatywny scion-server nad Spannerem. Każda warstwa trafia w cache w ponad 99% przypadków, a cała infrastruktura jest 200 razy mniejsza od poprzednich mirrorów gita.
Faktem są nazwy warstw, kolejność odpytywania, skuteczność cache powyżej 99% i 200-krotna redukcja infrastruktury. Uproszczeniem jest pominięcie ścieżki zapisu — commity i merge'e powstają po stronie serwera, poza tym przepływem. Diagram nie pokazuje, ile instancji liczy każda warstwa.
Claude po obu stronach problemu
Scion powstał w tym samym czasie, co wewnętrzna dostępność Claude Mythos Preview. Ręcznie napisany prototyp pipeline'u ingestu z gita Claude przepisał bez dodatkowych instrukcji — nowa wersja zużywała 20 razy mniej pamięci i działała 4 razy szybciej.
Do monitoringu zespół uruchomił na Slacku „superfanów": osobne instancje modelu pilnujące po jednym komponencie. Anthropic pisze też, że rolą inżynierów często było mówienie modelowi „nie" — przeglądy w trybie adwersaryjnym bywają krótkowzroczne i prowadzą do nadmiernego inżynierowania.
Dlaczego to ważne?
Anthropic nie opisuje produktu, lecz pierwszy udokumentowany przypadek, w którym infrastruktura deweloperska pęka pod ciężarem kodu pisanego przez modele. Pytanie, co właściwie znaczy CI, gdy w trakcie testów merguje się tysiąc zmian, przestaje być hipotetyczne. Skala Anthropic jest wyjątkowa, ale kierunek czytelny.
Co dalej?
- Scion nie trafi na zewnątrz — wymaga własnego code review, code search i migracji całego cyklu wytwarzania
- Firma zrezygnowała z globalnej blokady merge queue i przeniosła testy na etap post-merge oraz pre-deploy
- Antique, nowe narzędzie code review, nie ma jeszcze osobnej publikacji technicznej
Źródła
- Anthropic Engineering — Redesigning source control at Anthropic
- Simon Willison's Weblog — Redesigning source control at Anthropic
