Anthropic wymienił gita na własny system Scion Agenci Claude scalają tam ponad 30 tys. zmian dziennie

13 października 2026 roku Anthropic opisał na swoim blogu inżynierskim Scion, wewnętrzny system kontroli wersji, na który w pięć miesięcy przeniósł z gita całe monorepo. Powód stoi już w pierwszym akapicie wpisu: pisanie kodu przestało być w Anthropic wąskim gardłem, bo Claude produkuje go tyle, że zaczęła się dławić infrastruktura zaprojektowana dla ludzi, czyli kontrola wersji, buildy i CI.

W maju 2026 roku Anthropic scalał średnio ok. 2500 zmian dziennie, a we wrześniu już ponad 30 000, czyli dwanaście razy więcej w cztery miesiące. Firma nie spodziewa się spowolnienia, bo jej zdaniem „ukryty popyt na scalanie kodu jest praktycznie nieskończony”, a każde usunięte wąskie gardło od razu zwiększa ilość produkowanego kodu.

Zebrałem tu, co o Scionie wiadomo z wpisu Anthropic oraz z relacji Pragmatic Engineer, The Register i Simona Willisona. Opisuję też, dlaczego git i GitHub coraz gorzej znoszą ruch od agentów AI, i co z tego wynika dla zespołów, które nie scalają 30 tysięcy zmian dziennie, łącznie z kilkoma komendami, które warto ustawić w CI już dziś.

Scion w skrócie

Kwestia	Szczegóły
Co to jest	Wewnętrzny, scentralizowany system kontroli wersji Anthropic
Ogłoszenie	13 października 2026 (wpis zaktualizowany 15 października)
Skala	Ponad 30 000 scalonych zmian dziennie (wrzesień 2026)
Czas budowy i migracji	5 miesięcy, zespół 7 osób
Technologia	Serwer i klient w Ruście, dane w Google Spanner i Cloud Storage (wg Pragmatic Engineer)
Narzędzia towarzyszące	Antique (code review), wyszukiwarka kodu, system uprawnień (IAM) do repozytoriów
Dostępność	Tylko wewnętrznie, bez planów udostępnienia ani open source
Inspiracje	Piper (Google), Sapling i jego serwer Mononoke (Meta)

Dlaczego git przestał wystarczać Anthropic

Git jest systemem rozproszonym. Każdy klon to kompletne repozytorium, które bez sieci policzy diff, pokaże historię i blame oraz przełączy się na dowolną rewizję. Anthropic przyznaje, że dla zdecydowanej większości repozytoriów to właściwy projekt i spora część powodu, dla którego git stał się standardem.

Monorepo Anthropic przestało jednak pasować do tych założeń:

• historia samej gałęzi main ma prawie 100 GB,
• skompresowana kopia robocza zajmuje ponad 25 GB,
• samo CI wykonuje ok. 25 mln checkoutów dziennie, nie licząc środowisk deweloperskich, sandboksów agentów i zadań badawczych.

Gdyby każdy checkout pobierał repozytorium w naiwny sposób, według Anthropic dawałoby to ponad 600 PB ruchu gita dziennie (25 mln × 25 GB).

Firma przeszła wcześniej przez wszystkie standardowe obejścia: płytkie klony, sparse checkout, częściowe klony, wewnętrzne mirrory (w szczycie kilkaset) i gotowe snapshoty repozytorium w blob storage. Kupiło to trochę czasu, ale snapshoty odjeżdżały od czubka main między odświeżeniami, operacje zależne od historii na częściowych klonach wymagały coraz więcej zachodu, a mirrory przestały się skalować, kiedy repozytorium przerosło ich dyski i pamięć.

Anthropic, jak większość firm, i tak używał gita jako systemu scentralizowanego z jedną autorytatywną kopią, a niemal wszyscy klienci to agenci i zadania CI, które z definicji są online. Cechy, dzięki którym git dobrze sprawdza się w pracy rozproszonej i offline, zaczęły więc przeszkadzać w skalowaniu. Zespół zapytał, jak wyglądałaby kontrola wersji projektowana od zera dla klientów, którzy zawsze są online.

Jak działa Scion

Sześć zasad projektu

1. Klienci są zawsze online. Klient nie trzyma pełnej kopii repozytorium i pobiera dane wtedy, gdy ich potrzebuje.
2. Asymetria klienta i serwera. To serwer odpowiada na pytania o historię i blame, tworzy commity, wykonuje merge i rebase. Klient trzyma ograniczony cache obiektów, układa pliki kopii roboczej i śledzi zmiany, więc sam policzy niewiele, ale potrzebuje dużo mniej danych.
3. Pełne API do kontroli wersji. Zadanie CI, które chce wiedzieć, kto ostatnio zmienił daną linię albo jak powiązane są dwa commity, nie musi mieć lokalnego repozytorium. Bez tego automatyczne potoki do bisectu i revertów nie działałyby w tej skali.
4. Wszystko skaluje się poziomo. Dane repozytorium są rozproszone i nigdzie, nawet na serwerze, nie istnieje jego pełna, zmaterializowana kopia. Nie ma packfile’ów, więc odpada też utrzymanie repozytorium (gc, repack).
5. Commity są tanie, przyrostowe i bez blokad. Commit, rebase i merge dzieją się na serwerze, więc nie ma czego wypychać, a koszt commita rośnie z rozmiarem zmiany, nie repozytorium. Gałęzie i tagi poza main i gałęziami wydań są niemile widziane, bo globalny stan, na który muszą się zgodzić wszystkie serwery, Anthropic nazywa tykającym problemem skalowania.
6. Kopia robocza jest opcjonalna i częściowa. Wiele odczytów i zapisów idzie wyłącznie przez API. Gdy zadanie naprawdę potrzebuje plików na dysku, dostaje checkout częściowy (tylko wskazane katalogi) albo wirtualizowany, w którym plik pojawia się dopiero przy pierwszym odczycie.

Changeset zamiast commita

Podstawową jednostką w Scionie jest changeset, wpis w dzienniku zapisu z wyprzedzeniem (write-ahead log). Zamiast wskazywać na całe drzewo plików jak commit w gicie, przechowuje listę plików zmienionych względem pierwszego rodzica i adresowane treścią (content-addressed) wskaźniki do skompresowanej zawartości w blob storage. Changesety powstają po stronie serwera i od razu są dostępne wszędzie, a serwer przyjmuje je z bardzo dużą przepustowością, bo nie ma packfile’ów do przyjęcia, blokad ani koordynacji między serwerami.

Pytania, na które sam changeset nie odpowie szybko (kto ostatnio edytował linię, które commity zmieniały plik), obsługują dane pochodne (derived data): indeksy blame, historia ścieżek i skip listy dla grafu commitów, liczone jednym generycznym mechanizmem rekurencyjnie z wartości dla rodziców. Nowy indeks łatwo dodać, gdy przyspieszy jakąś operację, a ponieważ klient nie widzi wnętrza tych struktur, serwer może je zmieniać bez zmian po stronie klienta.

Trzy warstwy cache

Klient Sciona (scn) nie mówi serwerowi, co już ma. Zaczyna od korzenia drzewa, sprawdza lokalnie, których poddrzew brakuje, i prosi o nie rekurencyjnie. Każde żądanie dotyczy konkretnego obiektu, który nigdy się nie zmienia, więc obsłuży je dowolny cache, a przerwane pobieranie da się wznowić. Infrastruktura ma trzy warstwy: scion-daemon na każdej maszynie, scion-cache w każdym regionie (drzewa i pliki prosto z pamięci) i autorytatywne scion-server czytające ze Spannera i chmurowego magazynu obiektów. Wszystkie odpowiadają na te same wywołania RPC, ale Anthropic pilnuje ich kolejności, żeby awaria regionalnego cache’a nie zalała serwerów.

Wyniki według Anthropic

Wskaźnik	Wynik
Trafienia w cache	Ponad 99% na każdej warstwie
CPU i pamięć w porównaniu z mirrorami gita	200 razy mniej
Checkout w CI i zadaniach badawczych	Sekundy zamiast minut (o dwa rzędy wielkości szybciej)
Moc CPU odzyskana w CI	25%
Pipeline importu git → Scion przepisany przez Claude Mythos Preview	20 razy mniej pamięci, 4 razy szybciej

Nick G., autor wpisu, powiedział Pragmatic Engineer, że każdy komponent może się autoskalować, ale na razie nie było takiej potrzeby, choć liczba scaleń wzrosła w tym roku ponad dziesięciokrotnie. Większość pracy wykonuje cache, bo dane adresowane treścią raz zapisane nigdy się nie zmieniają. Dla agentów ważniejsze od liczb jest jednak to, że bisect, revert czy diff względem main to wywołania API, a nie klonowanie dziesiątek gigabajtów. Agentowi zwykle bardziej przyda się odpowiedź niż kopia robocza.

Antique, koniec merge queue i nowa rola inżynierów

Ten sam zespół zbudował równolegle Antique, narzędzie do code review (według Pragmatic Engineer z backendem w Go i frontendem w React), a także wyszukiwarkę kodu i system uprawnień. Antique potrafi wyrażać semantyczne warunki akceptacji zmian, np. odróżnić zmianę w samych komentarzach od wrażliwej zmiany w logice, a Scion obsługuje uprawnienia na poziomie pojedynczych katalogów, więc najwrażliwszy kod da się chronić bez dzielenia monorepo.

Mnie najbardziej zaciekawiła rezygnacja z klasycznej kolejki scaleń (merge queue). Anthropic pyta, co w ogóle znaczy CI, skoro w czasie jednego przebiegu testów do main mogą trafić setki zmian. 30 000 scaleń na dobę to ok. 21 zmian na minutę, więc przy testach trwających 20 minut w trakcie jednego przebiegu do main trafia ok. 400 innych zmian. Globalnej blokady repozytorium na czas testów nie dało się w tej skali odtworzyć, więc Anthropic testuje automatycznie po scaleniu, a przed wdrożeniem. Konflikty między równoległymi zmianami się zdarzają, ale według firmy Claude zwykle naprawia je szybciej, niż człowiek zdążyłby je zauważyć.

Wpis sporo mówi też o tym, jak zmienia się praca inżynierów:

• Siedem osób zbudowało Sciona, Antique i kilka powiązanych systemów, a potem w pięć miesięcy przeprowadziło migrację. Anthropic pisze, że dawniej taki projekt zająłby firmie lata.
• Wszyscy inżynierowie zespołu oceniają dziś, że Claude pisze kod lepiej od nich, więc ich rola przesunęła się w stronę architektury i pilnowania ograniczeń systemu. Agenci potrafią łamać kluczowe założenia, żeby dopasować się do wzorca, którego nigdy nie powinno się było dopuścić. Przykład z migracji: kilka systemów ustalało moment scalenia zmiany, czytając liniowo log commitów, zamiast zapytać narzędzie do code review.
• Review robiony przez innego agenta jest skuteczny, ale bywa krótkowzroczny i pcha kod w nadmierną inżynierię. Ludzie nadal przeglądają każdą zmianę, tyle że oceniają jej intencję, a nie każdą linię.
• Zespół testuje więcej niż kiedykolwiek: hermetyczne symulacje interakcji z infrastrukturą, fuzzing, rate limiting. Claude znalazł też optymalizacje, których analiza zajęłaby ekspertowi dni albo tygodnie.
• Przez Claude Tag zespół utworzył kanały na Slacku, w których Claude jako „superfan” obsesyjnie pilnuje jednego komponentu, ma dostęp do telemetrii i logów i według Anthropic wyłapuje subtelne problemy, przy których klasyczne alerty wydają się jednowymiarowe.

Dlaczego git i GitHub coraz gorzej znoszą agentów AI

Anthropic jest przypadkiem skrajnym, ale ten sam trend widać na GitHubie, który już w kwietniu wstrzymał rejestracje w Copilot Pro i Pro+, bo agenci zużywali więcej mocy obliczeniowej, niż zakładały plany. Trzy liczby z tego roku, wszystkie od samego GitHuba:

• Kwiecień 2026. Kyle Daigle, COO GitHuba, napisał, że w całym 2025 roku na platformie powstał 1 mld commitów, a teraz powstaje ich 275 mln tygodniowo, co daje tempo 14 mld rocznie, „jeśli wzrost będzie liniowy (spoiler: nie będzie)”.
• Sierpień 2026. Po awarii z 17 sierpnia, która trwała 7 godzin i 47 minut, CTO GitHuba Vlad Fedorov podał, że liczba commitów miesięcznie wzrosła od kwietnia z 1,4 do 2,9 mld. GitHub dołożył w tym roku ponad 3 mln rdzeni CPU i 120 PB pamięci masowej, a awarię spowodował brak mocy w centrum danych Central US.
• Październik 2026. GitHub podał, że w samym wrześniu powstało 7,38 mld commitów, ponad pięć razy więcej niż rok wcześniej, a GitHub Actions uruchomiono 3,26 mld razy. Ta liczba jest wyraźnie wyższa niż sierpniowe 2,9 mld z wpisu CTO, a GitHub nie wyjaśnia, czy obie liczono tak samo, więc porównywałbym je ostrożnie.

Git powstał w 2005 roku dla ludzi, którzy klonują repozytorium raz, pracują na nim tygodniami i wypychają kilka commitów dziennie. Agenci pracują inaczej i przy nich każde z założeń gita zaczyna kosztować:

• Każdy klon to pełne repozytorium. Agent startuje w świeżym sandboksie, więc każde zadanie zaczyna od nowego klonu. GitHub pisze, że CI i skanowanie kodu pobierają ten sam czubek gałęzi tysiące razy na minutę.
• Proste pytania wymagają lokalnej historii. git blame, git log czy wyznaczenie merge base liczy się u klienta, więc zadanie CI musi mieć u siebie historię. Płytki klon nie wystarcza, pełny jest drogi.
• Negocjacja i packfile’y obciążają serwer. Przy git fetch serwer liczy brakujące obiekty i buduje packfile z kompresją delta. Odpowiedź jest inna dla każdego klienta, więc trudno ją zcache’ować, a po zerwaniu połączenia trzeba ją pobierać od nowa.
• Każdy zapis to globalny stan. Agent w ciasnej pętli commituje niemal po każdej akcji, a każdy push przesuwa refy, które wymagają zgody między replikami. W architekturze GitHuba (Spokes) każde repozytorium leży na pięciu serwerach i w każdym zapisie uczestniczą wszystkie, więc dokładanie replik dla odczytów spowalnia zapisy.
• Repozytorium trzeba utrzymywać. Okresowe gc i repack konkurują z obsługą ruchu, gdy bez przerwy zapisują setki agentów.
• Procesy są szyte na ludzką skalę. Pull request, review linijka po linijce i kolejka scaleń zakładają, że zmian jest na tyle mało, że człowiek je obejrzy. The New Stack pisał w lipcu, że gdy agentów przybywa, bramka przed scaleniem zamienia się w obciążenie.

GitHub przebudowuje swoją infrastrukturę według bardzo podobnych zasad jak Scion. W październikowym wpisie opisał rozdzielenie przechowywania danych od mocy obliczeniowej: autorytatywne dane repozytoriów trafiają do Azure Blob Storage, odczyty obsługują lekkie serwery z cache’em, zgody między replikami wymaga już tylko aktualizacja refów, a kompaktowanie i garbage collection odbywają się na osobnych maszynach. W wewnętrznych testach GitHub mierzy do 35 razy wyższą przepustowość zapisu. Zostaje przy gicie i jego protokole, więc to nadal nie Scion, ale kierunek jest wspólny: niezmienne obiekty w tanim magazynie, warstwa cache przed nimi i jak najmniej globalnej koordynacji.

Na ten sam problem odpowiadają też startupy. Entire Thomasa Dohmkego, byłego CEO GitHuba (60 mln dolarów w rundzie seed w lutym 2026), buduje rozproszoną sieć gita dla zespołów, w których agenci piszą kod szybciej, niż ludzie go przeglądają. Cursor udostępnia płatnym użytkownikom Origin, własny hosting gita z wbudowanymi agentami, a Pierre Computer Company sprzedaje Code Storage, infrastrukturę gita sterowaną przez API. Cała trójka trzyma się jednak kompatybilności z gitem, z której Scion zrezygnował.

Wady, ryzyka i wątpliwości

• Brak pracy offline. Inżynier Sciona odpowiedział na Hacker News, że skoro najwięcej korzysta z niego Claude, który z natury jest online, praca offline „po prostu nie była ważna”. Dla agentów to prawda, dla ludzi w pociągu czy samolocie już nie.
• Centralizacja to pojedynczy punkt awarii. Gdy pada centralny serwer, staje cała firma, co dobrze widać po tegorocznych awariach GitHuba. Warstwowa architektura ma temu przeciwdziałać, ale wpis nie opisuje żadnych incydentów, więc nie wiadomo, jak Scion radzi sobie z awariami w praktyce.
• Uzależnienie od jednej chmury. Według Pragmatic Engineer changesety leżą w Google Spanner, a pliki w Google Cloud Storage.
• Nikt poza Anthropic go nie użyje. Scion jest zamknięty, a Pragmatic Engineer podaje, że chodzi głównie o brak czasu zespołu, bo nawet jednorazowe wydanie kodu bez wsparcia to dużo pracy. Firma pisze też, że Scion „w żadnym razie nie nadaje się na zamiennik gita do ogólnego użytku”. Otwarte zostaje, czy Anthropic odda cokolwiek do gita w postaci kodu, a nie tylko pomysłów.
• Trzeba przebudować cały ekosystem. Własne code review, wyszukiwarka i CI to jedno, ale integracje z IDE, GitHub Actions i wszystkie narzędzia, które zakładają gita, przestają działać. Gergely Orosz porównuje to do Google, gdzie inżynierowie po odejściu z firmy odkrywają, że wypadli z obiegu standardowych narzędzi.
• Main może być czerwony. Bez kolejki scaleń zepsuty kod może trafić do main, a Anthropic polega na tym, że Claude szybko naprawia konflikty. Ile to kosztuje, firma nie podaje, przyznaje za to, że wydaje na tokeny do użytku wewnętrznego znacznie więcej, niż jakakolwiek inna firma realnie chciałaby wydać.
• Uproszczona historia i przegląd intencji zamiast kodu. Scion zapisuje zmiany tylko względem pierwszego rodzica i zniechęca do gałęzi, a ludzie oceniają, co zmiana ma zrobić, a nie każdą linię. W trunk-based development w monorepo to działa, ale oznacza mniejszą kontrolę nad kodem.
• Czy 30 tys. scaleń to produktywność? W dyskusji na Hacker News (blisko tysiąc komentarzy) często wracało pytanie, czy to miara wartości, czy po prostu duży ruch. Wszystkie liczby pochodzą od Anthropic i nikt ich niezależnie nie sprawdził.

Spór o Mononoke i uznanie autorstwa

Dwa dni po publikacji Anthropic zaktualizował wpis o przypis, który wiele technik użytych w Scionie przypisuje Mononoke, serwerowi systemu Sapling od Meta, i jego modelowi danych Bonsai. Wcześniej wpis wymieniał tylko Pipera i Saplinga.

Aktualizacja była reakcją na krytykę. Osoba, którą Pragmatic Engineer opisuje jako twórcę Mononoke, zarzuciła Anthropic skopiowanie projektu, w tym modelu Bonsai i koncepcji danych pochodnych, bez należytego uznania, i to nieprzypadkowo, bo nad oboma projektami pracowali częściowo ci sami ludzie. Nick G. odpowiedział na Hacker News, że zespół wymienił Saplinga, bo pod tą nazwą Meta pokazuje publicznie cały system razem z Mononoke, że nie chciał niczego ukrywać i że Mononoke „zasługuje na duże uznanie”. Nikt nie zarzucał złamania licencji. Gergely Orosz zauważa, że z open source można swobodnie korzystać w jej granicach, ale to, że Anthropic przyznał się do inspiracji dopiero po publicznej skardze, ocenia źle.

Co w Scionie jest naprawdę nowe

Scion nie jest pierwszym scentralizowanym systemem kontroli wersji. The Register i Simon Willison od razu porównali go do Subversion, a duże firmy budowały własne systemy wcześniej: Google Pipera, gdy przerósł Perforce’a, Meta Saplinga po latach na Mercurialu, Microsoft VFS for Git dla repozytorium Windowsa (ok. 3,5 mln plików i 300 GB). Widzę w tej historii cztery nowe rzeczy:

• Problemy wielkich firm przychodzą wcześniej. Google i Meta potrzebowały dziesiątek tysięcy inżynierów, żeby dojść do ściany, a Anthropic doszedł do niej z kilkoma tysiącami pracowników, bo każdy pracuje z wieloma agentami. Gergely Orosz szacuje, że firma produkuje tyle kodu, co organizacja zatrudniająca 35-70 tys. osób.
• Klientem nie jest człowiek. Git zakłada człowieka z laptopem, który bywa offline, a Scion agenta, który jest zawsze online, dostaje sandbox na kilka minut i potrzebuje odpowiedzi zamiast kopii repozytorium.
• Wąskie gardło się przesuwa. Najpierw był nim kod, potem kontrola wersji i CI, a teraz review i weryfikacja. Rezygnacja z merge queue pokazuje, gdzie pojawi się następny problem.
• Konkretne propozycje dla gita. Anthropic nie namawia do porzucenia gita. Proponuje, żeby serwer gita nie musiał działać tak samo jak klient, żeby platformy oferowały pełne API po stronie serwera (najlepiej wspólne dla GitHuba, GitLaba i innych) i żeby częściowe i płytkie klony lepiej ze sobą współpracowały. Czy GitHub, GitLab albo projekt git to podejmą, dopiero się okaże.

Anthropic spodziewa się, że w ciągu 6-12 miesięcy problemy tej klasy staną się powszechne, a dane GitHuba sugerują, że to realna prognoza.

Co to oznacza dla Ciebie

Jeśli Twój zespół scala kilkadziesiąt czy kilkaset zmian dziennie, git i GitHub zostają i nic nie musisz zmieniać. Sam Anthropic pisze, że koncepcje Sciona mają sens tylko w ogromnych monorepo z dziesiątkami tysięcy inżynierów albo rojami agentów. Kilka lekcji przyda się jednak każdemu, kto puszcza agentów (Claude Code, Codex, Copilot) w CI albo równolegle na swojej maszynie:

• Nie klonuj więcej, niż potrzebujesz. Do zwykłego builda zwykle wystarczy płytki klon (--depth=1). Do zadań, które potrzebują historii, ale nie wszystkich plików, użyj częściowego klonu i sparse checkoutu:

git clone --filter=blob:none --sparse https://github.com/firma/repo.git

git sparse-checkout set src/app docs

• Przy wielu agentach na jednej maszynie używaj worktree zamiast kolejnych klonów. Każdy agent dostaje osobny katalog roboczy na wspólnych obiektach:

git worktree add ../repo-agent-2 -b agent-2

• Pytaj API zamiast klonować. Porównanie gałęzi czy blame pojedynczego pliku pobierzesz z API GitHuba (REST compare, pole blame w GraphQL) bez lokalnej kopii.
• Ogranicz liczbę pushy. Agent może zapisywać checkpointy lokalnie, a wypychać jedną uporządkowaną zmianę.
• Przygotuj plan na awarię GitHuba. Po tegorocznych przestojach mirror repozytorium i możliwość wdrożenia bez GitHuba przestały być paranoją.
• Kieruj uwagę ludzi tam, gdzie jest potrzebna. CODEOWNERS i reguły ochrony gałęzi dla wrażliwych katalogów to prosta wersja tego, co Anthropic robi w Antique.

Podsumowanie

Scion to odpowiedź Anthropic na problem, którego większość firm jeszcze nie ma: agenci AI piszą kod tak szybko, że git, zaprojektowany dla ludzi pracujących offline, zaczął hamować pracę. Anthropic odwrócił jego założenia: klient jest cienkim cache’em, serwer odpowiada na pytania przez API i sam tworzy commity, a niezmienne dane łatwo cache’ować.

Scion nie zastąpi gita i nie wyjdzie poza Anthropic, ale dobrze pokazuje, gdzie git i GitHub będą pękać, gdy agentów będzie przybywać. GitHub już przebudowuje infrastrukturę w podobnym duchu, a nowe firmy budują hosting gita dla agentów. Najbardziej praktyczny wniosek na dziś: zanim puścisz flotę agentów na swoje repozytorium, sprawdź, ile razy dziennie każdy z nich je klonuje.

Często zadawane pytania

Czym jest Scion od Anthropic?

To wewnętrzny, scentralizowany system kontroli wersji, na który Anthropic przeniósł swoje monorepo z gita. Zaprojektowano go dla agentów AI, którzy są zawsze online: serwer wykonuje commity, merge i zapytania o historię, a klient trzyma tylko ograniczony cache i w razie potrzeby częściową kopię plików.

Czy Scion zastąpi gita?

Nie. Anthropic pisze, że Scion „w żadnym razie nie nadaje się na zamiennik gita do ogólnego użytku” i ma sens tylko w ogromnych monorepo. Firma proponuje raczej, żeby platformy gita przejęły część pomysłów, np. pełne API po stronie serwera.

Czy mogę pobrać albo przetestować Sciona?

Nie. Scion jest zamknięty i Anthropic nie planuje publicznej wersji ani open source. Opublikował tylko zasady projektu i opis struktur danych.

Dlaczego git nie radzi sobie z agentami AI?

Git zakłada, że każdy klon to pełne repozytorium, a obliczenia (blame, diff, merge) odbywają się u klienta. Agenci startują w świeżych sandboksach, więc klonują repozytorium przy niemal każdym zadaniu, commitują po niemal każdym kroku i są zawsze online. Przy dużym repozytorium daje to ogromny ruch, obciążenie serwerów i rywalizację o zapisy.

Czym jest Antique?

To narzędzie do code review, które Anthropic zbudował razem ze Scionem. Pozwala definiować semantyczne reguły akceptacji, np. odróżniać zmiany w komentarzach od wrażliwych zmian w logice, żeby ludzie zajmowali się najważniejszymi zmianami.

Czy Anthropic odchodzi z GitHuba?

Wewnętrznie tak: monorepo jest w całości na Scionie, a mniejsze repozytoria są w trakcie migracji. Według Pragmatic Engineer projekty publiczne, takie jak repozytorium Claude Code, skille i pluginy, zostają na GitHubie. Anthropic deklaruje też chęć współpracy z GitHubem i GitLabem nad skalowaniem gita.

Źródła

1. Anthropic: Redesigning source control at Anthropic https://www.anthropic.com/research/redesigning-source-control
2. The Pragmatic Engineer: The Pulse: Anthropic builds its own source control system https://blog.pragmaticengineer.com/the-pulse-anthropic-builds-its-own-source-control-system/
3. The Register: Anthropic reinvents source control as Claude floods the world with code https://www.theregister.com/a/5302943
4. Simon Willison: Redesigning source control at Anthropic https://simonwillison.net/2026/oct/13/redesigning-source-control-at-anthropic/
5. Simon Willison: cytat Kyle'a Daigle'a (GitHub) o liczbie commitów https://simonwillison.net/2026/Apr/4/kyle-daigle/
6. GitHub Blog: The August 17 outage, and the work ahead https://github.blog/news-insights/company-news/the-august-17-outage-and-the-work-ahead/
7. GitHub Blog: Building Git infrastructure for agent-scale development https://github.blog/engineering/infrastructure/building-git-infrastructure-for-agent-scale-development/
8. The New Stack: Your merge gate was a compromise. Coding agents are making it a liability https://thenewstack.io/merge-gate-coding-agents/
9. Engineering at Meta: Sapling: Source control that's user-friendly and scalable https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/
10. Brian Harry (Microsoft): The largest Git repo on the planet https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/
11. TechCrunch: Former GitHub CEO raises record $60M dev tool seed round at $300M valuation https://techcrunch.com/2026/02/10/former-github-ceo-raises-record-60m-dev-tool-seed-round-at-300m-valuation/
12. IT Brief: Cursor rolls out Origin code hosting to paid users https://itbrief.com.au/story/cursor-rolls-out-origin-code-hosting-to-paid-users
13. Pierre Computer Company: Code Storage https://code.storage/