Jakie lekcje dla biznesu niesie SCION od Anthropic?

Kiedy na łące pasą się krowy, po kilku latach przez trawę biegną wydeptane ścieżki. Krowy wybierają drogę wygodną dla krowy, czyli omijają kamień, obchodzą błoto i skręcają tam, gdzie akurat rosła smaczniejsza koniczyna. Potem obok łąki wyrasta miasteczko, a ktoś w urzędzie ma do wyboru dwie rzeczy. Może wylać asfalt na ścieżki, które już są, bo to tanie i szybkie, albo usiąść nad mapą i zapytać, dokąd właściwie mają prowadzić drogi. Większość urzędów wybiera asfalt. Większość firm też.

W październiku 2026 roku firma Anthropic, która tworzy Claude'a, opisała na swoim blogu inżynierskim, jak sama stanęła przed tym wyborem. Chodziło o system kontroli wersji, czyli coś, co dla przeciętnego menedżera brzmi równie pasjonująco jak instrukcja obsługi kserokopiarki. Tyle że ta historia wcale nie jest o programowaniu. Jest o tym, co dzieje się z procesem zaprojektowanym pod ludzi, gdy nagle zaczynają z niego korzystać maszyny, i dlaczego jedna decyzja siedmiu inżynierów mówi więcej o przyszłości Twojej firmy niż połowa konferencji o sztucznej inteligencji.

Kiedy pisanie kodu przestało być problemem

Anthropic trzyma prawie cały swój kod w jednym ogromnym repozytorium, które w żargonie nazywa się monorepo. Każda zmiana w tym kodzie musi zostać zapisana, opisana i scalona z resztą, a pilnuje tego system kontroli wersji. Od dwudziestu lat standardem jest tu Git, narzędzie napisane w 2005 roku przez Linusa Torvaldsa i używane dziś przez praktycznie każdy zespół programistów na świecie.

W maju 2026 roku do kodu Anthropic trafiało średnio około 2 500 zmian dziennie. We wrześniu rekordowego dnia scalono ich 30 401. Ten skok nie wziął się z zatrudnienia tysięcy programistów, tylko z tego, że kod w coraz większej części pisze Claude. Według danych samej firmy ponad 80% kodu scalonego w maju napisał model, a agenci pracują równolegle, w wielu kopiach, przez całą dobę.

Uczciwość wymaga jednej uwagi. W internecie krąży hasło „ponad 30 tysięcy zmian dziennie”, ale z wykresu Anthropic wynika, że to wynik jednego, rekordowego dnia. Średnia z tamtego tygodnia była bliżej 18 tysięcy. Co i tak oznacza siedmiokrotny wzrost w cztery miesiące, więc nie ma potrzeby niczego podkręcać.

Przy takim tempie Git zaczął się dławić. Skompresowana kopia robocza repozytorium Anthropic waży ponad 25 GB, a same automatyczne testy (CI) pobierają kod około 25 milionów razy na dobę. Gdyby każde z tych pobrań było pełną kopią, w Gita trzeba by wpychać ponad 600 petabajtów danych dziennie. Firma oczywiście tego nie robiła, bo inżynierowie sięgnęli po każdą sztuczkę, jaką Git oferuje: płytkie kopie, częściowe pobieranie, pamięci podręczne. W szczycie utrzymywali kilkaset wewnętrznych mirrorów, czyli kopii repozytorium rozstawionych po klastrach. Wpis Anthropic mówi wprost, że kontrola wersji stała się największym wąskim gardłem całego wytwarzania oprogramowania w firmie.

Wtedy ktoś zauważył rzecz, która z perspektywy czasu wydaje się oczywista. Git został zaprojektowany dla człowieka, który siedzi przy własnym komputerze i w każdej chwili może stracić połączenie z siecią. Dlatego każdy programista dostaje pełną kopię całego kodu wraz z całą historią i może pracować w pociągu, w samolocie albo w górach. Dla ludzi to genialne rozwiązanie. Tyle że w Anthropic po drugiej stronie prawie nigdy nie siedział już człowiek. Siedzieli agenci i automaty testowe, które są online zawsze, nie wsiadają do pociągów i nie potrzebują całej historii projektu, żeby poprawić jeden plik. Cecha, która czyniła Gita świetnym dla ludzi, zaczęła hamować maszyny.

Inżynierowie mogli dalej łatać Gita. Zamiast tego zadali pytanie, które warto zapamiętać, bo przyda się w każdej branży. Jak wyglądałaby kontrola wersji, gdyby od początku projektowano ją dla agentów, a nie dla ludzi? Odpowiedzią jest Scion. W nowym systemie ciężką pracę wykonuje serwer, który sam tworzy zapisy zmian, scala je i odpowiada na pytania o historię. Agent nie dostaje już kopii całego repozytorium, tylko pobiera dokładnie te pliki, których w danej chwili potrzebuje. Koszt jednej zmiany zależy od wielkości tej zmiany, a nie od wielkości całego kodu firmy.

Efekty są wymierne. Scion zużywa 200 razy mniej mocy obliczeniowej i pamięci niż wcześniejsza farma mirrorów, a ponad 99% zapytań kończy się w pamięci podręcznej. Przygotowanie nowego stanowiska pracy dla agenta skróciło się z 7,1 minuty do 5,1 sekundy. Łączny czas operacji na repozytorium przy jednej zmianie spadł z 34 do 3,7 minuty, co według Anthropic oszczędza około 11 tysięcy godzin pracy agentów dziennie, a krótsze pobieranie kodu w testach daje kolejne 195 tysięcy godzin maszynowych na dobę.

Najciekawszy jest jednak skład zespołu. Scion, nowe narzędzie do przeglądu i scalania zmian o nazwie Antique oraz pół tuzina innych systemów zbudowało siedem osób w pięć miesięcy, przenosząc w tym czasie całe repozytorium na nową platformę i nie zatrzymując firmy, która akurat rosła w szalonym tempie. Pomagał im Claude. Inżynierowie z tego zespołu przyznają, że model pisze kod lepiej niż oni, więc ich praca polega dziś głównie na rozumieniu, jak wszystkie elementy do siebie pasują, na podejmowaniu decyzji projektowych i, jak sami piszą, bardzo często na mówieniu Claude'owi „nie”. To brzmi jak opis pracy dobrego dyrektora, a nie programisty.

Zanim zaczniesz szukać, gdzie kupić Sciona, jedno zastrzeżenie, które Anthropic zrobił sam. Firma pisze, że dla większości organizacji Git nadal jest właściwym narzędziem, że Scion nie będzie udostępniony jako open source i że woli wnieść jego pomysły do Gita razem z GitHubem, GitLabem i społecznością. Lekcja nie brzmi więc „wymień Gita”. Lekcja brzmi „zobacz, co się stało, gdy jedna firma przestała asfaltować krowie ścieżki”.

Stara historia, którą już raz przerabialiśmy

Fraza o krowich ścieżkach nie pochodzi z Doliny Krzemowej. W 1990 roku Michael Hammer opublikował w Harvard Business Review artykuł o wymownym tytule „Reengineering Work: Don't Automate, Obliterate”, czyli mniej więcej „nie automatyzuj, zburz i zbuduj od nowa”. Pisał w nim, że czas przestać asfaltować krowie ścieżki i zamiast zamykać przestarzałe procesy w krzemie i oprogramowaniu, trzeba je zlikwidować i zacząć od zera.

Hammer opisał przypadek Forda. Dział rozliczeń z dostawcami zatrudniał w Ameryce Północnej ponad 500 osób, a zarząd liczył, że dzięki komputerom zmniejszy go o 20%. Wtedy menedżerowie Forda zajrzeli do Mazdy, w której Ford miał udziały, i zobaczyli, że tę samą pracę wykonuje tam pięć osób. Nawet po uwzględnieniu różnicy w skali było jasne, że komputer wstawiony w stary proces niczego tu nie zmieni. Ford przebudował więc sam proces, przestał porównywać stosy faktur z zamówieniami i zaczął płacić w chwili przyjęcia towaru. Zatrudnienie w dziale spadło o 75%. W tym samym tekście jest przykład ubezpieczyciela, u którego wniosek klienta krążył po firmie 22 dni, choć faktyczna praca nad nim trwała 17 minut. Resztę czasu wniosek spędzał w kolejkach, na biurkach i w wewnętrznej poczcie.

Jeszcze wcześniej, w 1987 roku, ekonomista Robert Solow, laureat Nagrody Nobla, napisał zdanie, które przeszło do historii jako paradoks Solowa. Erę komputerów widać wszędzie, tylko nie w statystykach produktywności. Firmy kupiły komputery, ale pracowały dokładnie tak samo jak przedtem.

Najlepsze wyjaśnienie tego paradoksu przyniósł w 1990 roku historyk gospodarki Paul David, który przyjrzał się elektryfikacji fabryk. Pierwsze elektrownie ruszyły w latach 1881-1882, ale wyraźny wzrost produktywności w amerykańskim przemyśle pojawił się dopiero na początku lat 20., czyli około czterdziestu lat później. Powód był banalny. Właściciele fabryk najpierw wymieniali jedną wielką maszynę parową na jeden wielki silnik elektryczny i zostawiali wszystko inne bez zmian, łącznie z wałami pod sufitem i pasami transmisyjnymi, które rozprowadzały napęd po hali. Zysk był prawie żaden. Prawdziwa zmiana przyszła dopiero wtedy, gdy każda maszyna dostała własny mały silnik, a hale zaczęto projektować od nowa, jednopoziomowo, zgodnie z przepływem pracy, a nie z przebiegiem wału.

Erik Brynjolfsson, Daniel Rock i Chad Syverson opisali ten mechanizm jako krzywą J produktywności. Gdy firma wdraża technologię ogólnego przeznaczenia, musi najpierw zainwestować w rzeczy, których nie widać w bilansie, czyli w nowe procesy, umiejętności i organizację pracy. Przez pewien czas produktywność stoi w miejscu albo nawet spada, bo płacisz za przebudowę, a efekty jeszcze nie przyszły. Potem krzywa wystrzeliwuje w górę i wygląda jak litera J. Kto jednak wstawi nową technologię w stary proces, ten ominie dołek, ale ominie też wzrost. Zostanie mu płaska linia i poczucie, że ta cała rewolucja to przesada.

Agentowa sztuczna inteligencja jest dziś dokładnie w tym miejscu. Można dać każdemu pracownikowi agenta, który pisze, liczy i odpowiada pięć razy szybciej, ale jeśli wszystko, co agent wyprodukuje, nadal przechodzi przez procesy zbudowane pod ludzkie tempo, większość zysku zniknie po drodze. To jest elektryczny silnik podpięty do starego wału.

Wąskie gardło nie znika, tylko się przeprowadza

W latach 80. Eliyahu Goldratt spopularyzował teorię ograniczeń, której sedno da się streścić w jednym zdaniu. Wydajność całego procesu wyznacza jego najwęższe miejsce, a przyspieszanie każdego innego etapu jest stratą czasu. Gdy przez lata najwolniejszym etapem pracy programisty było pisanie kodu, wszystkie narzędzia i nawyki dopasowano właśnie do tego. Teraz agent pisze kod w minutach, więc wąskie gardło przeprowadza się piętro wyżej, do ludzi, którzy ten kod czytają, oceniają i zatwierdzają.

Dane pokazują to coraz wyraźniej. Faros AI przeanalizował w 2025 roku pracę ponad 10 tysięcy programistów i wyszło, że zespoły intensywnie korzystające z AI scalają o 98% więcej zmian, ale czas przeglądu kodu wydłużył się o 91%, a wskaźniki całej firmy praktycznie stoją w miejscu. Kolejne badanie tej firmy z 2026 roku, obejmujące 22 tysiące programistów, pokazało pięciokrotnie dłuższy medianowy czas przeglądu i o 11,7% mniej wdrożeń tygodniowo. Pisze się więcej, a do klientów trafia mniej. Bain policzył, że samo pisanie i testowanie kodu to zaledwie 25-35% całego cyklu wytwarzania oprogramowania, dlatego asystenci AI dają zwykle 10-15% produktywności, a firmy, które przebudowały cały proces od pomysłu do wdrożenia, raportują 25-30%. Raport DORA od Google, oparty na odpowiedziach prawie 5 tysięcy specjalistów, ujmuje to jednym zdaniem. AI nie naprawia zespołu, tylko wzmacnia to, co już w nim jest, łącznie z bałaganem.

Jest też efekt, który powinien dać do myślenia każdemu, kto ocenia wdrożenia na podstawie ankiet. W badaniu METR z 2025 roku doświadczeni programiści open source spodziewali się, że AI przyspieszy ich pracę o 24%. W rzeczywistości z AI pracowali o 19% wolniej, a po zakończeniu badania nadal byli przekonani, że byli szybsi o 20%. Wrażenie przyspieszenia to jeszcze nie przyspieszenie.

Anthropic zderzył się z tym samym problemem we własnym zespole. Firmowe badanie z grudnia 2025 roku pokazało, że inżynierowie scalali o 67% więcej zmian dziennie niż wcześniej, a jeden z nich opisał swoją pracę jako w ponad 70% przeglądanie i poprawianie kodu. Dlatego zespół Sciona nie poprzestał na nowej kontroli wersji. Zmienił też sam sposób przeglądu. Recenzent nie czyta już każdej linijki, tylko sprawdza intencję zmiany, czyli to, czy zmiana robi to, co miała robić, i czy w ogóle powinna powstać. Zrezygnowano też z globalnej blokady kolejki scalania, która kazała zmianom czekać jedna za drugą, bo przy tej skali po prostu nie dało się jej utrzymać. Zmiany scalają się równolegle, a większa część testów odbywa się po scaleniu, ale przed wdrożeniem. Czasem dwie zmiany się zderzą, ale Claude zwykle naprawia taki konflikt szybciej, niż człowiek zdążyłby go zauważyć.

To nie jest problem wyłącznie programistów. Microsoft w raporcie Work Trend Index z 2025 roku policzył, że praca pracownika biurowego jest przerywana co kilka minut, nawet kilkaset razy dziennie, przez spotkania, maile i wiadomości. Asana szacowała wcześniej, że około 60% czasu pracy pochłania administracja będąca „pracą nad pracą”, czyli te wszystkie maile, komunikaty i wiadomości na Slacku. Akceptacja faktury, która czeka tydzień w skrzynce kierownika, umowa leżąca na biurku prawnika, cotygodniowe spotkanie zwołane tylko po to, żeby przekazać informacje, które dałoby się wysłać w trzech zdaniach. Każdy z tych procesów zaprojektowano wokół ograniczeń człowieka, czyli tego, jak szybko czytamy i ile godzin dziennie możemy pracować. Gdy agent przygotuje sto umów zamiast pięciu, prawnik nie stanie się sto razy szybszy. Stanie się wąskim gardłem.

Pięć lekcji dla Twojej firmy

Pierwsza lekcja dotyczy sposobu, w jaki inżynierowie Anthropic szukali problemu. Nie pytali, jak przyspieszyć Gita, tylko jakie założenie o użytkowniku jest w niego wbudowane i czy nadal jest prawdziwe. Git zakładał człowieka, który w każdej chwili może stracić internet, a po drugiej stronie pracowały już agenty, które są online zawsze. W procesach Twojej firmy siedzą podobne założenia, tylko nikt ich nigdy nie zapisał. Akceptacja każdej faktury przez kierownika zakłada, że nikt poza nim nie sprawdzi jej zgodności z zamówieniem. Cotygodniowe zebranie zakłada, że informacja dotrze do zespołu tylko wtedy, gdy ktoś ją wypowie na głos. Najprościej wyłowić takie założenia tak, jak zrobił to Hammer u ubezpieczyciela, czyli zmierzyć, ile czasu sprawa jest w pracy, a ile czeka w kolejce. Jeśli z dwudziestu dwóch dni pracy jest siedemnaście minut, to nie potrzebujesz szybszego wykonawcy, tylko krótszej drogi, a agent wstawiony w tę samą kolejkę przyspieszy wyłącznie te siedemnaście minut.

Druga lekcja dotyczy pomiaru. McKinsey w badaniu stanu AI z 2025 roku wskazał przebudowę przepływów pracy jako czynnik, który spośród 25 badanych najmocniej wpływa na wynik finansowy z wdrożeń AI, a jednocześnie zrobiło to tylko około 21% firm. BCG szacuje, że realną wartość z AI na dużą skalę osiąga zaledwie 5% przedsiębiorstw. Różnica między tymi pięcioma procentami a resztą rzadko leży w modelu. Najczęściej leży w tym, że reszta mierzy szybkość pojedynczego etapu, a nie przepływ całego procesu. Jeśli agent przygotowuje oferty w minutę, a oferta i tak czeka trzy dni na podpis dyrektora, Twój czas realizacji wynosi trzy dni i minutę.

Trzecia lekcja to zmiana kontroli, a nie jej likwidacja. Anthropic nie zrezygnował z przeglądu kodu, tylko przeniósł go z poziomu linijek na poziom intencji, a resztę oddał testom automatycznym i agentom, którzy pilnują poszczególnych części systemu. W Twojej firmie odpowiednikiem może być akceptacja reguły zamiast akceptacji każdej faktury, wzór umowy zatwierdzony raz zamiast czytania każdej umowy od nowa albo próbka kontrolna zamiast kontroli wszystkiego. Człowiek dalej odpowiada za wynik, tylko patrzy na to, co naprawdę wymaga ludzkiego osądu.

Czwarta lekcja dotyczy ludzi. Siedem osób zbudowało w pięć miesięcy infrastrukturę, która obsługuje wielokrotnie więcej pracy niż wcześniej, a inżynierowie Anthropic mówią wprost, że nie stali się przez to mniej wartościowi, tylko ich praca wygląda inaczej, bo zamiast pisać kod, projektują, decydują i sprawdzają pracę agentów. Wniosek jest odwrotny do tego, który wiele zarządów wyciąga z AI. Kompetencje zespołu to kapitał, którego żaden model nie odtworzy, bo osoby prowadzące dziś Twoje zakupy, księgowość czy obsługę klienta znają wyjątki, dostawców, klientów i całą wiedzę, której nikt nigdy nie spisał, więc zwolnienie ich w imię kwartalnych oszczędności to najszybszy sposób, żeby tę wiedzę stracić, zanim agent zdąży się jej nauczyć. Przebudowa procesu tworzy za to zadania, których wcześniej nie było, czyli szkolenie agentów, nadzór nad ich pracą, poprawianie instrukcji po każdym błędzie i ciągłe usprawnianie przepływów, a przecież nikt nie zoptymalizuje procesu zakupów w firmie lepiej niż ludzie, którzy od lat za te zakupy odpowiadają. Dziś jest to po raz pierwszy realne, bo z agentem każdy pracownik dostaje supermoce i staje się trochę programistą i specjalistą od automatyzacji, który opisuje agentowi, co ma zbudować, zamiast czekać miesiącami na dział IT. Warunek jest jeden, czyli zmiana procesu i sposobu myślenia o pracy, a nie wrzucenie AI w stare tryby.

Piąta lekcja dotyczy cierpliwości i budżetu. Krzywa J ma dołek i każdy, kto przebudowuje cały paradygmat myślenia wraz z procesem, w niego wpada. Zespół Anthropic przeprowadził migrację w pięć miesięcy, ale miał najlepszy model na świecie i kilka lat doświadczenia z agentami. Twoja firma będzie potrzebować więcej czasu, więc lepiej to zaplanować, niż po trzech miesiącach ogłosić, że AI się nie sprawdza. Anthropic przewiduje, że problemy podobne do tych, które go spotkały, zaczną być powszechniejsze w ciągu 6-12 miesięcy. Nie trzeba prowadzić laboratorium AI, żeby trafić na ten sam mur. Wystarczy mieć dwudziestu pracowników z agentami i jednego kierownika, który wszystko podpisuje.

Na koniec warto oddać sprawiedliwość krowom. One nie zrobiły nic złego, po prostu szły najkrótszą drogą do koniczyny. Kłopot zaczyna się wtedy, gdy na ich ścieżce kładziemy asfalt, a potem dziwimy się, że ciężarówka nie mieści się w zakręcie. Następny dziesięciokrotny wzrost wydajności nie przyjdzie z szybszego modelu, tylko z odpowiedzi na pytanie, jak wyglądałby Twój proces, gdyby od początku projektowano go dla maszyn.