O czym jest ten film
- Anthropic opublikowało tekst o migracji całego monorepa z Gita na własny system kontroli wersji Scion — cała operacja trwała 5 miesięcy.
- Liczba scalanych zmian wzrosła z ok. 2,5 tys. dziennie w maju do ponad 30 tys. we wrześniu; wąskim gardłem przestał być kod, a infrastruktura deweloperska projektowana dla ludzi.
- Liczby tłumaczą, dlaczego Git nie wyrabia: sama historia głównej gałęzi to prawie 100 GB, a CI robi około 25 mln checkoutów dziennie — natywnie dałoby to 600 petabajtów ruchu.
- Kluczowa obserwacja: niemal wszyscy „klienci” repozytorium to agenci i joby CI, które z definicji są cały czas online — rozproszona architektura Gita to w tym świecie balast.
- Scion odwraca logikę Gita: serwer liczy historię, blama i scalenia, klient trzyma tylko mały cache, a wszystkie zapytania są dostępne przez API.
- Changesety są niezmienne i dopisywane na końcu logu, treść plików leży w blob storage, metadane w Spannerze, a dane pochodne (blame, historia ścieżek) liczone rekurencyjnie.
- Efekty: infrastruktura 200 razy mniejsza pod względem CPU i pamięci, checkouty w sekundy zamiast minut, status nawet 207 razy szybciej, skuteczność cache’y ponad 99%.
- Rola inżynierów się zmienia: oceniają intencję zmiany zamiast czytać każdą linijkę, a ich częstym zadaniem jest mówienie Claude’owi „nie”, gdy model hoduje przerost formy.
- Anthropic świadomie rezygnuje z globalnej blokady kolejki scalania na rzecz testów po scaleniu i przed wdrożeniem — konflikty naprawia Claude szybciej, niż człowiek zdąży je zauważyć.
- Scion nie jest ogólnym zamiennikiem Gita, ale jego pomysły — RPC po stronie serwera, inny protokół negocjacji, składalne rzadkie checkouty — mogą przejąć GitHub, GitLab i społeczność open source.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zrewiduj założenia: Git powstał w czasach, gdy kod był drogi
Na czym polega: Git urósł w epoce, w której napisanie i scalenie kodu kosztowało dużo, więc rewie, gałęzie i blokady chroniły człowieka przed drogim błędem. Gdy agenty produkują dziesiątki tysięcy zmian dziennie, te zabezpieczenia stają się limitującym czynnikiem, a nie ochroną.
Jak stosować: Zrób audyt własnego procesu: wypisz mechanizmy (globalne blokady, kolejki, obowiązkową rewię każdej linijki) i przy każdym zapytaj, przed jakim kosztem chroni i czy ten koszt nadal istnieje. Tam, gdzie odpowiedź brzmi „już przed niczym istotnym”, tnij tarcie.
Na co uważać: Nie wszędzie błąd jest tani — w systemach finansowych czy medycznych barierki przed scaleniem wciąż mają sens; redukuj je tylko tam, gdzie masz naprawdę szybki mechanizm naprawy.
2.Jeśli klienci są zawsze online, projektuj od serwera
Na czym polega: Anthropic zauważyło, że używa Gita jak systemu scentralizowanego, a niemal wszyscy klienci — agenci i CI — i tak są nieprzerwanie w sieci. Scion odwraca architekturę: serwer jest sercem systemu, klient tylko lekkim terminalem z cache’em.
Jak stosować: W narzędziach wewnętrznych zamień schemat „sklonuj repozytorium i licz lokalnie” na API odpowiadające na pytania o historię, autorów i różnice. Job, który potrzebuje samych metadanych, nie powinien płacić za pełną kopię źródeł.
Na co uważać: Serwer staje się punktem krytycznym — Anthropic mogło sobie pozwolić na własne gwarancje dostępności; jeśli polegasz na zewnętrznej platformie, sprawdź jej realną dostępność.
3.Wystaw zapytania o źródła przez API
Na czym polega: W Scionie wszystkie operacje dostępne dla klienta są dostępne też programowo, więc narzędzia wewnętrzne — jak automatyczne cofanie błędnych zmian z bisekcją — działają bez lokalnego repozytorium.
Jak stosować: Policz, ile czasu CI traci na klonowanie i utrzymywanie repozytoriów tylko po to, by zapytać o dane. Theo zmierzył u siebie prawie 1000 godzin samego czekania na gita. Sprawdź, które joby wystarczyłoby zasilić endpointem.
Na co uważać: API musi być tanie i dobrze cache’owalne, inaczej tylko przenosisz koszt z dysków klientów na procesory serwera.
4.Niezmienność i adresowanie treści to fundament skalowania
Na czym polega: Changesety dopisuje się do logu i nigdy nie zmieniają treści; pliki leżą w blob storage pod adresem wynikającym z zawartości. Dzięki temu każdy serwer może cache’ować dane bez uzgadniania czegokolwiek z resztą.
Jak stosować: We własnych systemach unikaj mutowalnego stanu globalnego. Log dopisywany na końcu plus dane pochodne liczone na życzie to sprawdzony schemat skalowania poziomego.
Na co uważać: Dane pochodne (blame, historia ścieżek) trzeba gdzieś liczyć i przechowywać — to nowy koszt operacyjny i nowa powierzchnia błędów.
5.Pobieraj tylko to, co faktycznie czytasz
Na czym polega: Scion buduje protokół wokół rzadkich i wirtualizowanych checkoutów: pliki materializują się na żądanie, a job CI proszący o różnicę między zmianą a bazą scalenia dostaje z serwera dokładnie to i nic więcej.
Jak stosować: Zanim dokupisz moce obliczeniowe, zmierz, jaka część czasu CI to czekanie na klonowanie i checkout. Rzadkie checkouty i dostęp do metadanych przez API często zwracają się szybciej niż sprzęt.
Na co uważać: Narzędzia zakładające pełną lokalną kopię repozytorium (sporo wtyczek i skryptów) przestaną działać — migracja wymaga przeglądu całego łańcucha.
6.Ograniczaj globalny stan: refy, blokady, kolejki
Na czym polega: Wszystko, o czym muszą się zgodzić wszystkie serwery — gałęzie, tagi, globalna blokada kolejki scalania — nie skaluje się. Anthropic zostawiło sobie main i gałęzie release’owe, resztę zastąpiło changesetami.
Jak stosować: Przy projektowaniu systemów rozproszonych traktuj globalny stan jak podejrzany składnik: najpierw zapytaj, czy da się go usunąć albo ograniczyć do jednego miejsca.
Na co uważać: Zespoły przyzwyczajone do pracy na feature branchach potrzebują czasu na zmianę nawyków — to nie tylko kwestia techniki, ale i kultury.
7.Przesuwaj bezpieczeństwo za scalenie, nie przed nie
Na czym polega: Anthropic nie odtworzyło globalnej blokady kolejki; zamiast tego inwestuje w automatyczne testy po scaleniu i przed wdrożeniem, testy na wąskiej grupie odbiorców oraz szybkie cofanie zmian. Równoległe zmiany kolidują częściej, ale Claude rozwiązuje konflikty szybciej, niż człowiek zauważa problem.
Jak stosować: Zbuduj szybki, automatyczny revert i detekcję regresji po wdrożeniu. Mierz czas od „zepsuło się” do „naprawione” — to dziś często ważniejsza metryka niż liczba warstw weryfikacji przed merge’em.
Na co uważać: Model zakłada, że błąd szybko widać i można go zneutralizować; tam, gdzie regresja długo pozostaje niewidoczna (dane, bezpieczeństwo), potrzebne są dodatkowe siatki ochronne.
8.Przeglądaj intencję, nie każdą linijkę
Na czym polega: Inżynierowie Anthropic oceniają cel zmiany, a kod pisze Claude — i sami przyznają, że model robi to lepiej od nich. Człowiek wnosi wiedzę o całości systemu i kompromisach projektowych; często jego rolą jest powiedzieć „nie” rozwiązaniu łamiącemu zasady.
Jak stosować: Wprowadź przegląd intencji: krótki opis celu zmiany plus automatyczna rewie kodu. Człowiek wchodzi tam, gdzie stawka jest wysoka — logika, bezpieczeństwo, architektura.
Na co uważać: Recenzje prowadzone przez modele popadają w przesadną ostrożność i wymuszają przerost formy („na wszelki wypadek” dołożona walidacja, rozjeżdżający się zakres). Ktoś musi tego pilnować.
9.Koszt zmiany technologii runął — fundamenty da się przepisać
Na czym polega: Siedem osób w pięć miesięcy zbudowało system kontroli wersji, narzędzie do rewi, wyszukiwanie kodu i model uprawnień, migrując przy tym monorepo, w którym tempo zmian rosło dziesięciokrotnie. Jeszcze niedawno podobne projekty liczyły się w latach i dużych zespołach.
Jak stosować: Zrób prosty rachunek: koszt napisania własnej alternatywy w tokenach versus koszt utrzymania i przestojów obecnego rozwiązania. Theo policzył, że jego przepisanie kompilatora TypeScriptu kosztowało 20–25 tys. dolarów w tokenach.
Na co uważać: Własne narzędzie to własny dług operacyjny. Nie wszystko warto budować samemu — tam, gdzie liczy się wiedza dziedzinowa (np. mobile), nadal opłaca się sięgnąć po ekspertów.
10.Nie kopiuj Sciona — przenieś jego wnioski do Gita
Na czym polega: Anthropic wprost pisze, że Scion nie nadaje się na ogólny zamiennik Gita: ma sens tylko przy gigantycznych monorepach z tysiącami inżynierów albo chmarami agentów. Wskazuje za to, co może wejść do głównego nurtu: RPC po stronie serwera na platformach Gita, inny protokół negocjacji, lepiej składające się tryby rzadkie i płytkie.
Jak stosować: Jeśli prowadzisz platformę albo wewnętrzną forżę, zacznij od wystawienia API po stronie serwera — to najtańszy krok o największym zwrocie. Jeśli tylko korzystasz, śledź rozwój protokołów: zmiany nadejdą w perspektywie 6–12 miesięcy.
Na co uważać: Przepisywanie fundamentów „bo można” kończy się chaosem; rób to tam, gdzie ból — skala, koszty, przestoje — jest mierzalny.
Redakcyjne tłumaczenie
Git przestaje pasować do sposobu, w jaki dziś powstaje kod
Od momentu, w którym zacząłem pisać kod, pracuję w Gicie i na GitHubie. Zabawnie, że z Gita korzystałem nawet wcześniej, niż napisałem pierwszą linię — zarządzałem nim pluginy do serwerów Minecrafta jeszcze w niższych klasach liceum. Git to fundament mojego warsztatu, ale ostatnio coraz wyraźniej widzę jego słabe punkty. Spora część jego konstrukcji wychodziła z założenia, że kod jest drogi, a ludzie muszą go recenzować, zatwierdzać i kontrolować, dokąd trafia — bo utrata kodu albo scalenie złego kodu kosztowały bardzo dużo. To założenie ukształtowało całą branżę: sposób pracy zespołów, konstrukcję produktów takich jak GitHub, a nawet myślenie o sprawach, które powinny być podstawowe, jak zarządzanie sekretami. Pozdrawiam mój wiralowy klip o tym, że powinniśmy móc commitować zmienne środowiskowe. A mówiąc poważnie: Git nie jest właściwym „klockiem” na czasy, które nadchodzą.
GitHub to osobny rozdział
Będę z wami szczery: duża część moich problemów z Gitem to tak naprawdę problemy z GitHubem, bo to po prostu powolna i irytująca platforma. Zewnętrzne szacunki mówią o przestojach rzędu nawet 7% w różnych obszarach. Nie zliczę sytuacji, w których release utknął, bo akurat padały Actions, albo nie mogłem scalić ważnej zmiany, bo strona się nie ładowała. Gdy wykres dostępności GitHubu przypomina raczej choinkę niż ciągły zielony pasek, mówi sam za siebie wszystko, co trzeba.
Ale GitHub nie jest jedynym winowajcą. Sam Git nie jest właściwym narzędziem, gdy pracuje się mocno równolegle — z wieloma ludźmi, a tym bardziej z jeszcze większą liczbą agentów. Myślę o tym dużo, bo w grudniu bawiłem się JJ i po prostu pokochałem ten projekt. Od tamtej pory zastanawiam się, jak mogłoby wyglądać narzędzie zaprojektowane od zera do błyskawicznego dostarczania kodu razem z agentami. I, jak się okazuje, nie jestem w tych rozmyślaniach sam.
(Informacja dodatkowa: JJ, czyli Jujutsu, to eksperymentalny system kontroli wersji uważany za możliwego następcę Gita — upraszcza m.in. pracę z historią i scalanie zmian.)
Anthropic opublikowało właśnie artykuł o własnym, wewnętrznym systemie kontroli źródeł. W maju scalało 2,5 tys. zmian dziennie, we wrześniu — ponad 30 tysięcy. Wąskim gardłem okazała się infrastruktura deweloperska zbudowana dla ludzi, nie dla agentów. Postanowili stworzyć coś własnego. Brzmi to trochę szaleńczo — że agenty są już na tyle sprawne, by takie projekty w ogóle miały sens — ale naprawdę są. I bardzo podoba mi się ta postawa: kwestionowanie fundamentów własnego warsztatu po to, żeby zbudować rozwiązanie dopasowane do siebie. To zapowiada świetny materiał na głębokie zagłębienie się w temat — zwłaszcza że sam właśnie wyrywam ze swojego stacka TypeScript na rzecz własnych, „vibe coded” zamienników.
Przerwa sponsorska (w skrócie). Theo zastrzega, że nie wszystko trzeba przepisywać własnym sumptem — jest mnóstwo miejsc, gdzie sensowny jest produkt od dostawcy, na przykład u sponsora odcinka: Infinite Red. To specjaliści od mobile’a (React Native i Expo, a także Swift i Kotlin), z którymi pracowali m.in. Domino’s i Microsoft. Ich zdaniem rola konsultingu zmieniła się fundamentalnie: nie płaci się już za pisanie kodu — to robią agenty — tylko za wiedzę dziedzinową, ustawienie pipeline’ów tak, by dało się budować i wypuszczać aplikacje, oraz za sprawienie, że zmiany agentów da się weryfikować. Więcej: swrve.link/infinitered.
Czytamy artykuł
Tytuł brzmi „Redesigning source control at Anthropic” — „Przeprojektowanie kontroli źródeł w Anthropic”. Skoro dzienna liczba scalanych zmian wzrosła ponad dziesięciokrotnie, kontrola źródeł stała się największym blokerem developmentu; w pięć miesięcy przenieśli się na własny system. Nie ukrywam: te pięć miesięcy brzmi jak jedna z claude’owych halucynacji dotyczących czasu — pytasz „jak długo to zajmie?”, dostajesz „dwa, trzy dni”, a robota jest skończona po godzinie. Tak czy inaczej — robi to wrażenie. Podmiana Gita w firmie wielkości Anthropic, liczącej w przybliżeniu dwa tysiące pracowników, brzmi obłędnie.
Z artykułu: w Anthropic pisanie kodu przestało być wąskim gardłem budowania systemów i badań. Claude samodzielnie przeprowadza pętle badawcze, mikrooptymalizuje złożone programy i stawia nowe usługi od zera — w tempie i skali, jakiej wcześniej nie widziano. Teraz wszystko spowalnia infrastruktura deweloperska projektowana na miarę człowieka: kontrola źródeł, buildy, CI. W maju 2026 Anthropic scalało średnio około 2,5 tys. zmian dziennie; we wrześniu — ponad 30 tysięcy. I nikt tam nie spodziewa się wyhamowania: naturalne zapotrzebowanie na scalanie jest praktycznie nieskończone, a każdy usunięty bloker natychmiast przekłada się na jeszcze większą produkcję kodu.
Sam to kiedyś ująłem jako „odbieranie ryzyka przyciskowi merge”. Chodzi o dwie rzeczy. Po pierwsze: gdy człowiek patrzy na zmianę przed scaleniem, kod jest już z dużym prawdopodobieństwem bezpieczny. Po drugie: jeśli mimo wszystko trafi się coś złego, systemy do testowania zmiany na wąskiej grupie odbiorców i błyskawicznego cofnięcia drastycznie ograniczają zasięg zniszczeń. Widziałem różnicę po wprowadzeniu takich mechanizmów: po prostu dostarcza się szybciej.
Jedna noc, trzy strony historii scalonych zmian
Zostałem wczoraj do późna, bo zirytowały mnie niszowe problemy wydajnościowe przy naprawdę dużej bazie danych w T3 Code. Postanowiłem naprawić tyle, ile się da w jednym posiedzeniu, przy okazji posprzątać stare issuesy i PR-y oraz przejąć te niedoprowadzone do końca tak, jak bym chciał. Między północą a trzecią–czwartą nad ranem scalałem zmiany od pewnego punktu aż na samą górę historii. Trzy pełne strony scalonych zmian w cztery godziny, praktycznie wszystkie podpisane t3.gg. Skąd wiem, że cztery godziny? Bo zrobiłem to między nocnymi buildami, które wydajemy co sześć godzin — chciałem zdążyć z jak największą ilością przed nocnym wydaniem, żeby przed snem pobrać je, przetestować, naprawić co się zepsuło, wycofać build w razie potrzeby i pójść spać z uśmiechem, wiedząc, że rano wydajność będzie lepsza dla wszystkich.
To, że mogę pewnie scalić ponad pięćdziesiąt PR-ów za jednym razem, po prostu nie mieści mi się w głowie. Wyobraźcie sobie, że rok temu ktoś powiedziałby wam, że będziecie scalać 50+ PR-ów dziennie. Gdybym sam tego nie przeżył, a tylko słyszał od innych, uznałbym to za ściemę. Ale to rzeczywistość. Jeśli jeszcze nie pracujecie w takim tempie, to albo jesteś w miejscu, gdzie naprawdę nie wolno — bo ktoś może ucierpieć — albo po prostu nie zdajesz sobie sprawy, jak potężne są te narzędzia, i nie poświęciłeś czasu na zbudowanie tego, co obniża ryzyko.
Przepisywanie kontroli wersji ma swoją tradycję
Na wykresie w artykule niebieskie słupki to pull requesty, a pomarańczowe — „antique change requests”. To ich nowość: widać, że Antique to nazwa całego ich systemu, i pasuje do sposobu, w jaki Anthropic nazywa swoje wynalazki. Jeżeli ktoś uważa, że Anthropic odreagowuje tu w osamotnieniu — nieprawda. Firmy od dawna przepisują kontrolę źródeł pod siebie. Meta zbudowała szalony system wokół Mercuriala — sądzę, że będący wręcz hard forkiem — żeby ich model „stacked diffs”, czyli łańcuchowo ułożonych, zależnych od siebie zmian, działał jak najlepiej, gdy ludzie prowadzili długie wątki pracy i zatwierdzali fragmenty, by scalić wszystko naraz. Graphite to z kolei cała firma, która przenosiła sposób pracy Mety na GitHub — była daleko przed tym, jak budowaliśmy, gdy dostarczaliśmy szybko. W mojej firmie, Ping Labs, byliśmy intensywnymi użytkownikami Graphite; dziś należą do Cursora i budują Origin, alternatywę dla GitHuba wewnątrz Cursora.
Jay Gold — były pracownik Mety, potem Graphite, dziś Cursor — przypomina, że Meta budowała swoje systemy samodzielnie m.in. dlatego, że gigantyczne checkouty po prostu kiepsko działały w Gicie. Z grubsza pamiętam tę historię: Meta próbowała przekonać opiekunów Gita, by lepiej wspierał ogromne monorepa zamiast zmuszać do rozdrabniania repozytoriów. Opiekunowie nie ustąpili, więc Meta poszła własną drogą. I dobrze — nie trzeba wciskać standardu branżowego do swojego procesu, jeśli nie pasuje. Miło widzieć, że więcej firm to kwestionuje, bo Git nie jest doskonały. A na pewno nie jest doskonały dla agentów.
Scion, Antique i pięć miesięcy migracji
Żeby udźwignąć swój wzrost, Anthropic zbudowało Sciona — wewnętrzny system kontroli wersji — i w pięć miesięcy w całości przeniosło monorepo z Gita. A teraz naprawdę zabawna ciekawostka: i Anthropic, i OpenAI pracują w monorepach. Cała ich działalność to projekt po projekcie i folder po folderze w jednym gigantycznym repozytorium. Jeśli kiedykolwiek zastanawialiście się, dlaczego pasek boczny w aplikacji ChatGPT i Codex jest taki słaby — to właśnie dlatego. Przytłaczająca większość pracowników OpenAI ma jeden projekt: OpenAI. I wciąż siedzą, nawiasem mówiąc, na github.com. Praktycznie cały ich kod leży w openai/openai, które wywala 404, jeśli nie jesteś pracownikiem — więc dla tych, którzy twierdzą, że u nich po cichu pracuję, oto dowód, że nie. Taka organizacja pracy sprawia zresztą, że ich sposób myślenia jest dziwny dla ludzi prowadzących więcej niż jeden projekt.
Wróćmy do Anthropic. Oprócz Sciona, w tym samym półroczu zbudowali i wdrożyli: usługę rewi kodu o nazwie Antique, wyszukiwarkę kodu, rozbudowany system uprawnień do kontroli źródeł oraz nowe sposoby zarządzania i wprowadzania dużych paczek sprawdzonych zmian. W tekście skupiają się na samym Scionie — i to ciekawy przypadek do rozkładania na czynniki: zdolność Claude’a do pisania kodu z jednej strony wpychnęła ich w ten problem, a z drugiej pozwoliła zbudować wysokiej jakości, skalowalny system, który go rozwiązuje.
Dlaczego Git przestał wystarczać — twarde liczby
Zanim opiszą, co zbudowali, sami zaznaczają, że ich obciążenie jest nietypowe. Nic zaskakującego: Anthropic korzysta z Claude’a do pisania oprogramowania bardziej niż prawie każda inna firma. Możecie się zdziwić, ludzie — tak, na pewno robią to bardziej niż my, choć my też nieźle. A że korzystają tak intensywnie, jako pierwsi widzą, gdzie narzędzia budowane na skalę człowieka zaczynają pękać. Kontrola źródeł to tylko jeden z przykładów. Nie spodziewają się, by wiele organizacji miało te problemy od razu, ale podejrzewają, że nie minie dużo czasu, zanim intensywni użytkownicy AI w kodzie wpadną na te same ściany — dlatego dzielą się tym, co zbudowali.
Git jest systemem rozproszonym: każdy klon to kompletne, samodzielne repozytorium, potrafiące liczyć diffy, czytać historię i blama oraz odtwarzać dowolną rewizję w pełni offline. Dla zdecydowanej większości repozytoriów to właściwy projekt — i w dużej mierze właśnie dlatego Git stał się standardem. Ale ich monorepo wyrósł z tej przestrzeni projektowej. Sama historia głównej gałęzi ma prawie 100 GB, a spakowana kopia robocza — ponad 25 GB. Wykonują około 25 milionów checkoutów dziennie na potrzeby CI, nie licząc środowisk deweloperskich, sandboxów agentów i zadań badawczych. Przy pobieraniu natywnym byłoby to 600 petabajtów ruchu gita dziennie.
Git oferuje narzędzia do pracy z wycinkiem repozytorium — płytkie klony, rzadkie checkouty, promisor remotes — a poza tym istnieją standardowe obejścia dla wielkich monorep: wewnętrzne mirrory i snapshoty repozytoriów (tzw. seeds) trzymane w blob storage. Próbowali wszystkiego i wszystkiego używali. W szczycie utrzymywali kilkaset wewnętrznych mirrorów Gita, żeby udźwignąć obciążenie. Kupili sobie tym czas, ale wraz ze wzrostem tempa scalania coraz trudniej było to wszystko utrzymywać: seedsy coraz bardziej odstawały od czubka main między odświeżeniami, a utrzymanie operacji zależnych od historii — diffów i blama — na tych częściowych klonach wymagało coraz więcej uwagi.
W pewnym momencie spojrzeli na to z dystansu: tak jak większość firm, używali Gita jako systemu scentralizowanego — z jedną nadrzędną kopią. Tymczasem niemal wszyscy ich klienci to agenci i joby, które z definicji są online. To bardzo trafna obserwacja: nie da się używać Claude’a offline, bo Claude działa w gigantycznym centrum danych pełnym procesorów graficznych, których nie masz — chyba że jesteś do niego fizycznie podpięty i akurat leży internet tego centrum, jesteś online. Budowanie wszystkiego wokół idei, że każdy musi mieć wszystko zsynchronizowane, przestaje mieć sens. Cechy, które czynią Gita znakomitym do rozproszonej pracy bez sieci, aktywnie podkopywały zdolność Anthropic do skalowania.
Zadali sobie więc pytanie: jak wyglądałaby kontrola źródeł, gdyby od pierwszej linijki projektować ją z założeniem, że agenci są zawsze online? Przy kodowaniu agentskim zmienia się wiele podstawowych założeń o tym, jak powstaje oprogramowanie — i Scion te zmiany konsekwentnie przyjął. Dla ogromnych monorep istnieją oczywiście poprzednicy: Google’a Piper i Mety Sapling, więc mogli budować na cudzych, okupionych bólem doświadczeniach. Zresztą warto odnotować, ilu ludzi w Anthropic pochodzi z Mety i Google’a i jak często pracowało tam właśnie nad takimi systemami. Wiem na przykład, że Boris siedział głęboko w narzędziach deweloperskich w Mecie, a teraz robi Claude’a dobrym.
Siedem zasad, na których stoi Scion
1. Klient jest zawsze online. Skoro niemal wszyscy klienci to agenci i joby, klienta i protokoły zaprojektowano wokół zawsze dostępnego serwera — dane pobierane są wtedy, gdy są potrzebne. Zresztą samo to już eliminuje GitHuba: nawet gdy ty jesteś online, nie możesz zakładać, że on jest.
2. Asymetria klient–serwer. W Gicie każdy klient może być pełnoprawnym serwerem — to jeden z filarów jego prawdziwej decentralizacji. W Scionie serwer odpowiada na pytania o historię plików i blama, tworzy commity, wykonuje scalenia i rebase’y. Klient trzyma ograniczony lokalny cache obiektów, rozkłada pliki robocze na dysku, pilnuje zmian w systemie plików i daje wygodne sposoby rozmowy z serwerem. Sam potrafi policzyć niewiele — w zamian potrzebuje znacznie mniej danych lokalnie.
3. Wszystkie zapytania dostępne także programowo. W Gicie job CI pytający o coś w rodzaju „kto ostatnio ruszył tę linię” albo „jak te commity są powiązane” musi trzymać całą lokalną kopię albo mieć nadzieję na API dostawcy. W Scionie wszystkie zapytania, z których korzysta klient, są wystawione też jako interfejs programistyczny — więc w wielu przypadkach job w ogóle nie potrzebuje lokalnego repozytorium. Narzędzia wewnętrzne, jak automatyczne pipeline’y cofania zmian z bisekcją, nie byłyby w tej skali możliwe bez taniego programistycznego dostępu do źródeł.
4. Wszystko skaluje się poziomo. W szczycie kilkaset mirrorów Gita mocno obciążało moce i przestało się skalować, gdy repozytorium przerosło dyski albo limity pamięci mirrorów. Wiecie, że jest źle, gdy waszym mirrorom Gita kończy się miejsce na dysku — a dyski, nie ukrywajmy, mocno podrożały. Dzięki, Anthropic. W Scionie dane repozytorium są rozproszone, a każdy komponent skaluje się niezależnie. Nie ma nigdzie materialnej kopii repozytorium — nawet na serwerze. Nie ma też odpowiednika packfiles, czyli skompresowanych paczek obiektów Gita, więc nie ma konserwacji repozytorium.
5. Commity są tanie, przyrostowe i bez blokad. Brak blokad to rzecz kluczowa: commit jednej osoby nie może blokować drugiej — a w praktyce: pięciuset agentów commitujących nie może blokować kolejnych pięciuset. W Gicie commitujesz lokalnie, a potem pushujesz, żeby podzielić się pracą. W Scionie każdy commit, rebase i scalenie dzieje się na serwerze — nie ma czego pushować. Ale każda z tych operacji musi być szybka: koszt utworzenia commita i aktualizacji zależnych struktur musi rosnąć z rozmiarem zmiany, a nie z rozmiarem całego repozytorium — inaczej serwer nie nadąży.
6. Minimum refów. Cykl pracy w Scionie zniechęca do refów — wskaźników na commity, czyli gałęzi i tagów — poza mainem i gałęziami release’owymi. Powód jest prosty: globalny stan, o którym muszą się zgodzić wszystkie serwery, zawsze powoduje problemy ze skalowaniem. Rzeczy globalne są złe, gdy działacie w takim tempie. Zawsze.
7. Kopia robocza jest opcjonalna i z założenia rzadka. Repozytorium jest tak duże, a kod odtwarzany dziesiątki milionów razy dziennie na potrzeby CI, że wszędzie tam, gdzie da się uniknąć checkoutu, unika się go. Job CI potrzebujący tylko różnicy między commitem a bazą scalenia pyta serwer dokładnie o to. To samo przy zapisie: wiele operacji działa w całości przez API, z pominięciem checkoutu. Protokół Sciona jest zbudowany wokół rzadkich checkoutów, zawierających wyłącznie żądane katalogi, oraz checkoutów wirtualizowanych, w których pliki materializują się na żądanie — job płaci tylko za to, co faktycznie czyta.
Bawiłem się podobnymi pomysłami pod koniec zeszłego roku i na początku tego: jak zarządzać stanem bazy kodu tak, żeby nie trzymać jej całości na swoim komputerze, a agenty i tak miały dostęp. Fajnie widzieć prawdziwą wersję tego konceptu, bo moja była chaotycznym eksperymentem.
Changesety, bloby i dane pochodne
Wchodzimy w sekcję o strukturach danych — tu będą smaczne szczegóły. Jednostką pracy jest changeset (widzę inspirację Metą), a changesety są wpisami w logach typu write-ahead, czyli takich, w których najpierw dopisuje się zdarzenie, a dopiero potem aktualizuje pozostałe struktury. Changeset przechowuje to, czego można się spodziewać po commicie w Gicie, ale tam, gdzie commit gita trzyma wskaźnik na drzewo plików, changeset przechowuje listę plików zmienionych względem pierwszego rodzica — wraz ze wskaźnikami adresowanymi treścią, prowadzącymi do skompresowanych zawartości plików w blob storage. Changesety tworzy serwer i są natychmiast dostępne wszędzie.
To fascynujące. Wiedziałem, że dużo opierają na blob storage, ale aż tak wprost przyznać, że kod źródłowy nie istnieje „w systemie” — że gdy prosisz o źródła, trzeba je sprowadzić z magazynu blobów, a całość jest w praktyce bazą danych wskazującą na te bloby — to mocne. Wygląda na to, że wszystkie metadane siedzą w Spannerze. Ma sens, znowu mocno po googlowsku.
(Informacja dodatkowa: Spanner to rozproszona, globalnie spójna baza danych Google Cloud.)
Ciekawe, że mają osobne pola autora i committera. Ma to sens: autor to ten, kto zmianę zainicjował, a committer to agent, który ją wykonał, albo system, w którym to się stało — bardzo praktyczne, gdy różne systemy robią różne rzeczy. Do tego zwykłe pola: daty, komunikat, rodzic — oraz lista zmienionych plików ze wskaźnikami na bloby.
Taka konstrukcja pozwala przyjmować changesety z ogromną przepustowością: nie ma packfiles, nie ma blokad i koordynacji, nie ma refów do przestawiania. Chodzi o to, że wystarczy dopisać na końcu: nie przechodzisz przez historię przed dodaniem wpisu, nie przenosisz wskaźników z miejsca na miejsce, nie przebudowujesz drzewa, nie synchronizujesz danych tam i z powrotem. Wstawiasz changeset, zapisujesz bloby — gotowe. Zauważyłem przy okazji coś jeszcze: nie ma tu nawet zapisanych diffów. Blob to pełny nowy stan pliku — a gdyby przechowywać diffy, ich przeliczanie byłoby piekłem.
Changesety zapisują tylko to, co się zmieniło, więc same z siebie nie odpowiadają szybko na pytania w rodzaju „kto edytował tę linię” albo „który commit dotknął ten plik”. Do tego Scion buduje dodatkowe struktury: dedykowane dla blama plików i historii ścieżek oraz skip listy dla grafu commitów. Wszystko, co nie jest bezpośrednio częścią changesetu, nazywają danymi pochodnymi — i liczą je jednym uniwersalnym mechanizmem. Każdy typ danych pochodnych jest zdefiniowany rekurencyjnie: jego wartość dla danego changesetu wylicza się z jego wartości dla rodziców. Mechanizm daje trzy korzyści. Po pierwsze, łatwo dodawać nowe typy, gdy jakaś operacja wymaga przyspieszenia — dodawali ich wielokrotnie, na przykład indeksy do wykrywania kopiowania kodu czy wyszukiwania plików po ścieżce. Po drugie, dla każdego typu można wybrać, czy liczyć go od razu, czy odłożyć na później — i nie materializować danych, które nie są potrzebne. Po trzecie, klient nigdy nie widzi wnętrza struktur, więc można je optymalizować bez ruszania klientów.
Spróbuję to uprościć, bo wchodzimy głęboko w szczegóły — co uwielbiam. Duża część siły Gita polega na tym, że po klonie masz wszystkie dane. Chcesz sprawdzić, kiedy plik się zmienił albo co robiła dana osoba — przerabiasz dane sam. Problem w tym, że jeśli chcesz coś nowego dodać albo coś przyspieszyć, jesteś w kropce, bo musiałbyś wywrócić wszystkim ich Gita. A jeśli ludzie nie muszą klonować całości, tylko pytają API, to ty decydujesz, co wystawiasz. Serwer — pełen warstw cache i zapasów mocy — obserwuje, o co klienci pytają, i buduje dla tego wydajne obliczenia bez zmiany modelu danych. Twarda granica API zapobiega też kombinowaniu po stronie klientów. Widziałem to wielokrotnie: gdy klient dostanie dostęp do wnętrza systemu, wymyśli genialne w swojej głupocie, powolne i żrące procesor rozwiązania. Sztywna granica to niemal na pewno ogromna zaleta.
Skalowanie: niezmienność jako paliwo
U podstaw leży niewielka flota serwerów Sciona, dających API kontroli źródeł dla każdej operacji, jakiej potrzebuje klient: pobieranie changesetów, liczenie diffów, szukanie baz scalania, pobieranie blobów. Liczenie diffów to ciekawy przypadek, bo — jak wspomnieliśmy — system trzyma końcowe stany plików. Gdy pytasz, co się zmieniło między dwoma changesetami, nie ma czego odczytać: różnica jest wyliczana na żądanie — serwer bierze blobi wszystkich dotkniętych plików i porównuje ich stany.
Wszystkie dane kontroli źródeł są adresowane treścią: raz zapisany kawałek danych nigdy się nie zmienia. To ważne. W Gicie nadpisywanie historii nie jest katastrofą, bo przy forcowaniu pusha zmieniają się wszystkie hashe commitów. Ale gdyby dało się edytować treść kryjącą się pod danym hashem, Git pękłby w samych fundamentach. Niezmienność skaluje się praktycznie zawsze lepiej niż zmienność — a zbudowanie całego systemu na trwałych, niezmiennych changesetach, z całą elastycznością jako obliczeniami na wierzchu, trafia mnie prosto w serce programisty funkcyjnego.
A skoro changesety są niezmienne i adresowane treścią, każdy serwer może je cache’ować bez sprawdzania z innymi: gdy jeden serwer już jakiś ma, wie, że jest unikalny, i ufa mu bez namysłu. W efekcie serwery skalują się poziomo i prawie się nie koordynują — to w istocie wielkie cache’e, które potrafią jeszcze w locie liczyć dane pochodne i wyniki zapisywać do Spannera.
Klient SCN i trzy warstwy architektury
Wszyscy korzystający ze Sciona przestali utrzymywać własne lokalne repozytoria. Pobieranie i utrzymywanie repozytorium było poważnym obciążeniem dla jobów CI i narzędzi zadających pytania o pokrewieństwo commitów czy blama. Na początku migracji, zanim powstały własny format klienta i protokoły, Scion służył wyłącznie do odpowiadania na takie zapytania o metadane. Pobieranie treści plików i materializowanie kopii roboczych to operacje znacznie bardziej zasobożerne — i tu trzeba było zaprojektować coś od zera.
Klient SCN odchodzi od protokołów fetcha Gita w kilku istotnych miejscach, dzięki czemu pasuje do architektur wymagających znacznie mniej mocy procesora niż serwery gita. Negocjacja nie mówi serwerowi, co klient już ma — operuje wyłącznie na drzewach i blobach, których klient chce. Startując od drzewa korzenia, klient sprawdza lokalny magazyn pod kątem brakujących drzew i prosi o nie rekurencyjnie, potem powtarza to dla blobów. Najpierw więc znajduje changesety potrzebne do tego, co chce zrobić, potem zbiera blobi z potrzebnymi plikami — i dopiero wtedy zabiera się do pracy. Każde żądanie dotyczy konkretnego obiektu, który nigdy się nie zmienia, więc odpowie dowolny cache — architektura przypomina klasyczne, wielopoziomowe cache’e. Proces jest wydajny i wznawialny, bo nie ma jednej, wielogigabajtowej paczki w odpowiedzi. Rzadkie, a nawet wirtualizowane checkouty nie wymagają żadnego specjalnego wsparcia — klient po prostu nie prosi o drzewa, których nie chce.
Ten akapit napisany jest w języku, którego autorzy nigdzie nie zdefiniowali, więc spróbuję przełożyć z claude’izmów na ludzki. Klienci nie łączą się bezpośrednio z serwerami Sciona, bo te zarządzają całością changesetów. Rozmawiają z demonem przez socket, a demon przechowuje obiekty dla całego węzła — w praktyce cache’uje ostatnią wersję każdego pliku pod każdą ścieżką. Dzięki temu odpowiada na prośby o pliki bez schodzenia po całym drzewie, żeby wyliczyć bieżący stan. (Bardzo nie lubię, jak używają tu słowa „node”.) Każdy z tych demonów jest okresowo resetowany do najnowszego snapshotu, żeby nie musiał odtwarzać wszystkiego, co zmieniło się przez ostatnie trzy dni. Ma to sens: ludzie i agenci i tak startują pracy od najnowszego stanu, więc lepiej doprowadzić cache do aktualności i rozliczać tylko zmiany od tego momentu. Serwery cache strumieniują obiekty prosto z pamięci, a nie z dysku, co znacznie przyspiesza pobieranie po stronie klienta — i trzymają dane w tym samym formacie, w jakim leżałyby na dysku, żeby nic nie trzeba było przekształcać w drodze sieć–pamięć–dysk. Gdy w cache czegoś brakuje, pyta nadrzędne serwery Sciona, a te czytają ze Spannera lub storage’u w chmurze. Demon, cache i serwer odpowiadają na identyczne wywołania RPC, więc klient nie musi znać topologii. Teoretycznie każda warstwa mogłaby rozmawiać z każdą, ale hierarchia jest sztywno wymuszona, żeby odseparować domeny awarii — nie chcą sytuacji, w której padnięcie regionalnego cache’a przykłada się do serwerów nadrzędnych i wywraca cały system.
Czyli jeszcze raz, prosto: mamy autorytatywną warstwę serwerów Sciona, która zarządza prawdziwym stanem — Spanner dla changesetów, chmura dla treści. Nad nią regionalną warstwę cache, w którą uderzają maszyny deweloperów pobierające kod do pracy; czegoś brakuje, cache dociąga to z serwera. A dla CI nawet to nie jest właściwa abstrakcja — tu wchodzi demon z okresowymi snapshotami, gotowy jak najszybciej podnosić joby. Każda warstwa utrzymuje skuteczność cache’a powyżej 99% i nie wymaga długotrwałego stanu, więc łatwo ją skalować. Ślad całego układu w CPU i pamięci jest 200 razy mniejszy niż poprzednia infrastruktura mirrorów Gita. To szaleństwo.
Dygresja Theo: oprogramowanie szyte na miarę
I tu do mnie uderza myśl, która od jakiegoś czasu mnie uwiera: całe oprogramowanie budowano tak, by było w miarę uniwersalne. Teraz możemy budować je pod konkretne potrzeby. To głupi moment na dygresję, ale posłuchajcie. Jednym z moich dziwacznych projektów typu YOLO jest Lust, a dokładniej „Lust lang”: próbuję wziąć podzbiór Rusta dający większość korzyści Rusta, ale kompilowany 100 razy szybciej, bo czasy buildów TS Rust — mojego przepisania kompilatora TypeScriptu w Ruście — są za wolne. To obłędny projekt, w który nie wierzyłem, a już kompiluje ponad 40% plików z TS Rust i spodziewam się, że do końca tygodnia może faktycznie zadziałać. Czy to zadziała dla typowych projektów Rusta? Absolutnie nie, o to nie chodzi. To eksperyment szyty na miarę: mam konkretną bazę kodu z nieakceptowalnym czasem kompilacji — czy potrafię wymyślić język, który skompiluje ją szybciej? To, że w ogóle da się o czymś takim pomyśleć, a tym bardziej to zrobić, jest chore. Zwłaszcza że ja używam modelu dużo słabszego niż to, co mają oni: zdystylowanej wersji o dwie generacje starszej od ich wewnętrznego Fable Ultra Max 7 — ja sobie radzę na Opusie 5.5. Spodziewam się, że coraz więcej firm z wielkimi, bolesnymi problemami skalowania będzie przepisywać te bolesne kawałki od nowa. A tak przy okazji, dla Jana: borrow checker nie jest powodem, dla którego buildy w Ruście trwają wieczność — to cała masa dziwnych spraw wokół LLVM.
Pierwsze wyniki: sekundy zamiast minut
Joby CI i badawcze odtwarzają kod o dwa rzędy wielkości szybciej — w sekundy zamiast minut — co uwalnia spore rezerwy mocy w całej flocie. Samo CI odzyskało 25% zapasu procesora. Ani klienci, ani cache’e nie wymagają konserwacji repozytorium, co upraszcza zarządzanie cyklem życia jobów. Z ciekawości zacząłem właśnie wyciągać twarde liczby, ile czasu buildy T3 Code w CI spędziły na gicie i klonowaniach — mam przeczucie, że bardzo mnie zaboli. Wrócę do tego za chwilę.
Czego nauczyli się, budując Sciona
Zaczęli budować mniej więcej w tym samym czasie, w którym wewnętrznie udostępniono Mythos preview i Claude Tag — i obie te rzeczy naraz zwiększyły potrzebę na Sciona, i mocno przyspieszyły jego budowę. Przykład z artykułu robi wrażenie: pierwszą wersję pipeline’u importującego dane z Gita do Sciona napisali na wstępie ręcznie i uważali, że jest niezła — dopóki nie wzięli do ręki wczesnych, wewnętrznych snapshotów Mythos preview. Poprosili model, żeby przepisał całość, i bez dalszych instrukcji powstała wersja zużywająca 20 razy mniej pamięci, cztery razy szybsza, zachowująca wszystkie niepisane niezmienniki dotyczące importu, kolejności i struktur danych.
(Informacja dodatkowa: Theo wymienia tu nazwy narzędzi i modeli Anthropic — „Mythos” (wersja preview) i „Claude Tag” (wewnętrzny bot w Slacku) — bez szerszego wyjaśnienia; to nazwy własne z tekstu źródłowego.)
Na wykresie historii zmian Sciona i Antique widać zresztą zabawną rzecz: chwalą się 30 tys. zmian dziennie, ale do samej architektury Sciona i Antique wylądowało łącznie 12 250 zmian. Ich dzienne tempo pracy jest więc ponad dwukrotnie wyższe niż całkowita liczba zmian, jakie w ogóle trafiły do ich systemu kontroli źródeł. Chore.
Małe zespoły, wielkie migracje
Z budowy i eksploatacji Sciona płyną ciekawe lekcje o tym, jak będzie wyglądało tworzenie oprogramowania w skali agentów. Szybki rozwój małymi zespołami stanie się normą — potwierdzam. Sciona i Antique (narzędzie do rewi, o którym mogliby napisać osobny post) zbudowało siedem osób. Do tego pół tuzina powiązanych systemów, wszystkie w całości zmigrowane w pięć miesięcy — i to w czasie, gdy dzienna liczba scalanego kodu rosła dziesięciokrotnie. Kiedyś systemy kontroli źródeł powstawały latami iteracyjnych migracji i przy dużo większych składach osobowych. Tego typu szybkie, zwinne migracje będą się zdarzać coraz częściej.
Będą, mówię wam. Koszt zmiany technologii spadł bardziej niż prawie czegokolwiek innego. Kiedyś przyjmowało się technologię, rozwiązanie albo dostawcę i tkwiło się w nim, bo przesiadka była droższa niż koszty pozostania. Dziś łatwiej napisać własną alternatywę i się przenieść.
Sam niedawno złożyłem rozwiązanie, które klonuje, mirroruje i backfilluje wszystkie dane analityczne, jakie mam u jednego dostawcy — tak, żeby trzymał je mój własny, zarządzany przeze mnie ClickHouse na R2. Wyszło ponad dziesięciokrotnie taniej i dużo wygodniej dla moich agentów. Robiłem to dorywczo, kilkoma wątkami obok normalnej pracy. Kiedyś takie przedsięwzięcia były męką, dziś to względnie prosta sprawa. Naprawdę chore. Jak słusznie ktoś zauważa: dosłownie napisałem własny kompilator TypeScriptu, który dziś uruchamia się tysiące razy dziennie w T3 Code i ma ponad 40 tys. pobrań tygodniowo — a zaczął się jako żart, żeby sprawdzić, czy to w ogóle możliwe.
I właśnie dostałem swoje liczby. Z całego CI T3 Code prawie 1000 godzin poszło na czekanie na checkouty Gita. To 42 dni czekania na git pull — i to tylko w CI, bez ludzi ciągnących kod lokalnie. Szacunkowo samo czekanie na pobranie zmian kosztowało 350–600 dolarów za sam wynajem procesora. Dla małego projektu startupu z pięcioma pracownikami. Wyobraźcie sobie, jak to wygląda w skali Anthropic.
Rola inżynierów: mówić Claude’owi „nie”
Ta sekcja bardzo mi się podoba — i nie pamiętam, bym coś takiego od Anthropic słyszał. „Inżynierowie nie są mniej wartościowi, ale ich praca się zmienia.” Dziękuję, Anthropic, że nie stwierdziliście, że inżynierowie przestają się liczyć — miła odmiana. Wszyscy inżynierowie pracujący nad systemem oceniliby dziś Claude’a jako lepszego od siebie w pisaniu kodu. Ale to ludzie wnoszą bezcenne zrozumienie powiązań między podsystemami i kompromisów projektowych — to oni świadomie wybierają, które problemy rozwiązywać i na jaką skalę. Bardzo często rola inżyniera sprowadzała się do mówienia Claude’owi „nie”: agent czasem łamie podstawowe ograniczenia systemu, żeby zaspokoić wzorzec, który w ogóle nie powinien był być dozwolony. No dobrze — może jednak używają tego samego Claude’a co my. Szczególnie często zdarzało się to w migracjach: kilka systemów próbowało na siłę ustalić, kiedy zmiana weszła do maina, czytając liniowo cały log commitów, zamiast po prostu zapytać narzędzie do rewi.
Anthropic masowo stosuje też wzajemne recenzje modeli w trybie „adwersarskim” — nastawione na wyłapywanie słabości — i choć bywają niezwykle skuteczne, potrafią być krótkowzroczne. Sprawni inżynierowie muszą odciągać Claude’a od przerostu formy wywoływanego hipotetycznymi zagrożeniami. Jest jeszcze gorzej, gdy recenzje przychodzą z innych rodzin modeli — gorzej się nawzajem przekonują. Zadbanie o to, żeby recenzujące systemy AI nie wywoływały przerostu formy i rozjeżdżania się zakresu prac, to prawdziwe wyzwanie. Przykład z artykułu: jedna z recenzji była nadmiernie podejrzliwa wobec zaufania wewnętrznym usługom, przez co Claude dołożył zbędną walidację i komplikacje. Członkowie zespołu nadal przeglądają każdą propozycję zmiany — ale patrzą na jej intencję, a nie czytają każdej linijki. Jakże to świat się zmienił.
Jakość i optymalizacje podnieśli natomiast dzięki temu, że Claude pisze gigantyczne ilości kodu znacznie szybciej niż oni sami. Scion to jedna z najlepiej przetestowanych i najlepiej zabezpieczonych baz kodu, nad którymi pracowali. Nawet przy ścisłych terminach zrobili hermetyczne symulacje każdej nietrywialnej interakcji infrastruktury i kontroli źródeł, z jaką się zetknęli, do tego fuzzing, czyli automatyczne pompowanie losowych danych w celu wyłapywania błędów, i wyrafinowane limity żądań. Nadal mnie zawiesza, że mogę powiedzieć: „Claude, zbuduj fuzzer do tego systemu i znajdź bugi” — i on to po prostu robi. Surrealne. Claude znalazł też znaczące optymalizacje — na przykład algorytmiczne ulepszenia zapytań o pokrewieństwo, które nie trafiały w jeden z indeksów. Taka analiza i strojenie zajęłoby ekspertowi dni albo tygodnie — a Claude zrobił to wszystko od nowa następnego dnia. To tym zabawniejsze, że właśnie nagrałem materiał o Gemini 4 Argon: Gemini halucynował kolumny w moich tabelach SQLite — po przeczytaniu pliku z całością schematu i tak strzelał zapytania o nieistniejące kolumny. A Claude w tym czasie algorytmicznie obchodzi brakujące indeksy. Skoro ktoś twierdzi, że Gemini jest teraz w dobrej formie, trudno mu ufać jako inżynierowi. Wyobraźnia Gemini’ego jest niesamowita — halucynuje znakomicie. Naprawdę kreatywny model.
Codzienne operacje: przyspieszenie w liczbach
Widać tu różnicę na zwykłych komendach, gdy zamiast Gita działa system SCN. W środowiskach deweloperskich: pulle 25 razy szybciej, checkouty 14 razy, rebase 5 razy, status 207 razy szybciej, commity tylko o 30% szybciej (rozczarowujące), diffy 6 razy, a nowe drzewa robocze (worktree) — 84 razy szybciej. Ten ostatni wynik to ogromna wygrana: tworzenie worktree, gdy trzeba klonować wszystko, jest naprawdę drogie — sam to przeżywałem w T3 Code. W środowiskach agentowych: pobranie najnowszego stanu 20 razy szybciej, commity 24 razy, status 20 razy. Wszystkie te różnice są gigantyczne.
Bezpieczeństwo monorepa i jeden punkt, w którym nie wierzę
Obok wyników wydajnościowych Anthropic położyło fundamenty pod nowe formy bezpieczeństwa monorepa. Zarządzanie bezpieczeństwem, ochroną i zgodnością w wielkich monorepach jest równie ważne jak zarządzanie samą skalą. Scion od początku wspiera rozbudowaną kontrolę dostępu do repozytoriów oraz nakładanie uprawnień na pojedyncze katalogi — dzięki czemu najczulszy kod da się chronić bez rezygnowania z zalet monorepa. No i proszę — kto tu miał rację co do commitowania zmiennych środowiskowych.
Idąc dalej: ich narzędzia do rewi potrafią wyrażać złożone semantyczne ograniczenia dla zatwierdzeń — pozwalają odróżnić trywialne zmiany, jak poprawki w komentarzach, od wrażliwych zmian logicznych, tak by ludzcy recenzenci skupili się na tym, co naprawdę ma znaczenie. I tu, prawdę mówiąc, jestem najbardziej sceptyczny w całym materiale. Nie trzeba tego robić programistycznie. Nie trzeba budować kodu kategoryzującego changesety. Nie wiem, czy słyszeliście, ale istnieje coś takiego jak Claude: dajecie mu kod, zadajecie pytanie, dostajecie odpowiedź. Jeśli Anthropic jest na tyle ograniczone mocą obliczeniową, że nie może odpalić Claude’a do streszczania i filtrowania diffów i czuje potrzebę robienia tego programowo — to może naprawdę skończyły im się zasoby. A wtedy mamy wszyscy poważny problem.
Niezawodność i „superfani”
Przy całym tym pakiecie Anthropic twierdzi, że możliwy stał się nowy poziom doskonałości operacyjnej. I wiecie co — trzeba im przyznać, bo jest. Dostępność jest wyraźnie lepsza niż kiedyś, a kiedyś bywało słabo. Nie pamiętam, kiedy ostatnio Claude leżał: strona bywa niedostępna dość często, ale Claude Code i API działają ostatnio niezawodnie. Co zabawne, w ostatnim czasie miałem więcej problemów z awariami OpenAI i Codexa niż z Claude’em — co jeszcze niedawno brzmiałoby jak żart, tak wielka była różnica.
Ich zespół mocno używa Claude Tag — tego Slackbota, w którym wszyscy są zakochani — do monitorowania każdego komponentu. Mają kanały na Slacku, gdzie Claude dostaje zadanie być obsesyjnie skupionym na zdrowiu pojedynczego elementu. Nazywają te byty „superfanami”; używają też liczby mnogiej „Clauds”. To mnie trochę boli, ludzie. Ja was broniłem, Anthropic, i było mi z tym dobrze. A teraz robicie takie rzeczy. Jest superfan demona Sciona, superfan cache’a Sciona, superfan kolejki scalania Antique i tak dalej. Mają dostęp do telemetrii i logów i zachowują się jak doświadczeni inżynierowie, którzy nie mają nic lepszego do roboty niż odświeżać wykresy i szukać czegoś podejrzanego. Żartujecie? To moja robota. Anthropic zaznacza, że tradycyjne alerty też istnieją, ale superfany wyłapują subtelne, nowe problemy, przy których alerty wyglądają jednowymiarowo. I wiecie — to brzmi naprawdę fajnie. Wcześniej oszczędzali moc obliczeniową na rozwiązaniach programistycznych, a tu jest dokładnie odwrotnie: palą moc dla zabawy.
Koniec kolejki scalania? Przemyślenie wszystkiego od nowa
I oto chyba najważniejsza lekcja z całości: całkowite przemyślenie własnych przekonań. Inżynierowie utrwalamy nawyki z dobrych powodów — żeby być światowej klasy, trzeba wiedzieć, że modny, nagłośniony nowy wynalazek prawie nigdy nie jest najlepszym rozwiązaniem długoterminowym. Najlepsi z nas przeżyli już tyle razy, że domyślnie są sceptyczni: ufają temu, co znają i co działa, i niechętnie testują nowości. Trzeba to odwrócić. Rzeczy zmieniają się za szybko. Trzeba wywrócić własne myślenie do góry nogami: wiesz, co działa, a co nie, gdzie coś pęka i gdzie działa — ale zamiast na tej podstawie wybierać narzędzia, użyj tej wiedzy, żeby przepisać od nowa rzeczy, którym ufałeś całe życie, tak by były idealne dla twoich potrzeb. Piszę w TypeScripcie od blisko dekady — i dla zabawy przepisałem samego TypeScripta.
Anthropic ujmuje to tak: ten projekt skłonił ich do bardzo krytycznego spojrzenia na inne procesy projektowane dla skali człowieka. Kolejka scalania po prostu nie ma sensu w skali agentów. Co w ogóle znaczy CI, gdy setki, a nawet tysiące zmian może wejść do maina w trakcie trwania testów? Nie udało im się skutecznie odtworzyć branżowego standardu globalnej blokady repozytorium w kolejce scalania — więc zamiast tego zainwestowali w automatyczne testy po scaleniu i przed wdrożeniem.
No i patrzcie — znowu miałem rację. Przepraszam, że się z tego cieszę, ale nie macie pojęcia, jak długo dawano mi w kość za przekonanie, że zdolność cofnięcia złej zmiany jest ważniejsza niż dorzucanie tysięcy warstw przed zmianami, żeby tylko odrobinę utrudnić zrobienie złej. Tyle inżynierii poświęcono na podnoszenie tarcia, żeby zmniejszyć szansę, że coś się zepsuje. Ja zawsze szedłem w drugą stronę: tarcie minimalne — i żeby kod wychodził, i, co ważniejsze, żeby dało się szybko naprawić, gdy się zepsuje. Bo bez względu na to, jak surowe macie procesy, kiedyś wypuścicie coś zepsutego. Serio: jeśli wierzycie, że nigdy nie dostarczycie zepsutego kodu, że zbudowaliście system, w którym bugi się nie zdarzają — no cóż, w prawdziwym świecie rzeczy się psują. A gdy się psują, trzeba je naprawiać. Dbanie o szybkie naprawianie i ograniczanie szkód jest fundamentalnie ważne.
Anthropic dodaje, że przy takim modelu równoległe zmiany czasem kolidują — ale Claude zwykle naprawia te konflikty szybciej, niż człowiek zdąży je w ogóle zauważyć. Też nad tym myślałem. Mój pomysł: a gdyby kolejka scalania nie była łańcuchem PR-ów wpuszczanych jeden po drugim, tylko czymś w rodzaju uniwersalnego „oto zmiany, które chcemy mieć na pokładzie — Claude, wprowadź wszystko”? Agent próbowałby łączyć zatwierdzone kawałki w paczki i wciągać je do maina tak efektywnie, jak się da, rozwiązując konflikty po drodze. Bo Claude jest dziś w rozwiązywaniu konfliktów scalania lepszy ode mnie.
Dlaczego Scion nie trafi na rynek — i co z tego wynika dla Gita
Ostatnia sekcja: wkład do szerszego ekosystemu. Anthropic widzi Sciona jako jedną z odpowiedzi na wyzwania skalowania stawiane przez coraz zdolniejsze agenty. Dzielą się szczegółami jako przykładem — ale nie spodziewają się, że ich rozwiązanie pasuje do każdego przypadku. Zaznaczają wprost: to w żaden sposób nie jest zamiennik Gita w typowym użyciu. Te koncepcje mają sens tylko dla naprawdę ogromnych monorepów — z dziesiątkami tysięcy inżynierów albo z chmarami agentów sypiących kodem. Poza tym Anthropic jest w wyjątkowej sytuacji: jego zdolność wydawania tokenów na potrzeby wewnętrzne wielokrotnie przewyższa to, co jakakolwiek firma realnie chciałaby wydać. Nigdy nie myślałem, że takie zdanie usłyszę.
Choć, uczciwie mówiąc, tokeny tanieją — i to szybko. Dana inteligencja kosztuje z miesiąca na miesiąc mniej. Przepisanie Buna w Ruście na Fable pochłonęło ponad 300 tys. tokenów; moje odważniejsze przedsięwzięcie — TypeScript w Ruście — około 20–25 tys. dolarów w tokenach Opusa 5.5. Tempo, w jakim ceny lecą w dół, jest obłędne. Za rok może być tak, że własnego Sciona, własną alternatywę dla Gita w swojej firmie, napiszecie za kilka tysięcy dolarów w tokenach.
Anthropic robi to zresztą podwójnie: z potrzeby i po to, żeby sprawdzić możliwości Claude’a. A praktycznie trudno byłoby zaoferować Sciona w formie użytecznej dla innych. Odcina się od Gita na tyle, że firma musiałaby zmigrować każdy etap cyklu developmentu, i wymaga własnej rewi kodu, wyszukiwania i CI — a te wewnętrzne komponenty są tak specyficzne, że trudno by było je przejąć. Anthropic obawia się zresztą, że publiczna wersja próbująca zadowolić wszystkich nie byłaby wcale użyteczna. Znam ten akapit: to argumenty z wewnętrznej dyskusji, czy to sprzedać. Budujący powiedzieli „nie, nie sprzedajemy, oto dlaczego”. Dział sprzedaży się poddał. A komunikacja stwierdziła: „ludzie będą o to pytać” — więc trzeba było spisać wewnętrzne racje, żeby teraz bronić decyzji o nieotwieraniu tego dla świata.
Jednocześnie Anthropic przewiduje, że ta klasa problemów w ciągu 6–12 miesięcy stanie się powszechna — a marnowaniem zasobów byłoby, gdyby każda firma na Gicie mierzyła się z nimi w pojedynkę. Dlatego najbardziej wpływowe, co mogą zrobić, to podzielić się sposobem myślenia, żeby inni deweloperzy mogli przenieść najskuteczniejsze elementy Sciona do Gita bez porzucania całego modelu. Serwer Gita nie musi działać tak, jak klient Gita. Istnieją nowe architektury serwerowe dające znaczące zyski w skalowaniu. Platformy oparte na Gicie mogą wystawiać bogate interfejsy po stronie serwera, tak jak Scion — może nawet w ustandaryzowanej formie wspólnej dla wszystkich forż, której klienci gita nauczą się używać. Protokół negocjacji też nie musi wyglądać jak dzisiejszy. Wreszcie różne tryby rzadkie i płytkie w Gicie da się dopracować tak, żeby dobrze się ze sobą łączyły. Na koniec przyznają, że społeczność Gita skalowała platformę dla milionów deweloperów przez niemal dwie dekady, a ich wkład jest znacznie skromniejszy: wczesny rzut oka na to, jak agentskie wytwarzanie oprogramowania zderza się z tymi systemami. Chcą współpracować z GitHubem, GitLabem i społecznością open source na rzecz zmieniających się potrzeb twórców oprogramowania. Jesteśmy w tym wszyscy razem, gdy cykl developmentu przecina się z eksponentą AI.
Zakończenie
Szalone jest to, że rok temu taki materiał brzmiałby jak żart, a dziś prawie wzrusza ramionami: no jasne, że tak. Idę teraz walczyć z pokusą zrobienia własnego klona Gita. Będzie ciężko, ale spróbuję. Mam nadzieję, że podobało wam się to zagłębienie w temat — mnie bardzo. Uwielbiam takie nerdowskie wywody, a ten był wyjątkowo udany: wejście głęboko w to, jak działa kontrola źródeł i jak dopasować ją do tempa, w jakim potrzebują jej agenty. Macie jeszcze ochotę na takie analizy, czy wolicie więcej vibe codingu? Dajcie znać w komentarzach. Do zobaczenia — naraz, nerdzi.