Przegląd Anthropic Claude Code zastępuje rutynową ludzką lekturę, gdy AI pisze 90% kodu
Przegląd Anthropic Claude Code wkroczył na nieznane terytorium, ponieważ według firmy Claude pisze obecnie około 90% kodu produktu. Od czerwca do września 2026 r. liczba scalonych pull requestów wzrosła ponad dwukrotnie. Mimo to udział tych wymagających wycofania miał spaść o ponad 40%.
To zestawienie tworzy właściwą historię. Anthropic nie odpowiedział na lawinę kodu tworzonego przez maszyny, przydzielając ludziom więcej linii do sprawdzenia. Przeniósł większość rutynowej lektury do innych agentów Claude, a ludzką akceptację zarezerwował dla zmian o większym ryzyku.
Nie jest to po prostu szybsza wersja konwencjonalnego przeglądu. Zmienia to znaczenie przeglądu, to, kto go wykonuje, oraz miejsce, w którym zaczyna się odpowiedzialność. Anthropic traktuje teraz ludzką uwagę jako ograniczony zasób, który powinien podążać za ryzykiem, a nie za każdą pojedynczą linią.
Podejście to ma też istotne ograniczenie. Nagłówkowe wyniki to własne pomiary Anthropic, bez opublikowanych surowych danych ani niezależnego audytu. Jego proces opiera się na szerokiej automatyzacji, wewnętrznej infrastrukturze, etapowych wdrożeniach i wyjątkowo intensywnym dostępie do własnych modeli.
Powstała rywalizacja nie toczy się między Claude a ludzkimi programistami. Chodzi o zautomatyzowane pokrycie kontra powszechną ludzką inspekcję. Anthropic zakłada, że wielowarstwowe kontrole, ukierunkowane zatwierdzenia i łatwe odwracanie zmian mogą ograniczać więcej ryzyka niż czytanie linia po linii z prędkością maszyny.
Co zmieniło się w przeglądzie Anthropic Claude Code
Anthropic przekształcił przegląd kodu z pojedynczej ludzkiej bramki w ciągły system automatycznych kontroli, agentów recenzujących, ukierunkowanych zatwierdzeń i szybkiego wycofywania zmian.
Firma opisała ten system w opublikowanym 15 października wpisie inżynieryjnym na temat Claude Code review. Autorzy Addy Osmani, Morgan Westlee Lunt i Qing Wang przedstawili problem przez pryzmat wielkości produkcji. Gdy agenci generują zmiany szybciej, niż ludzie są w stanie je czytać, tradycyjna kolejka staje się wąskim gardłem dostarczania.
Anthropic twierdzi, że każdy pull request otrzymuje przegląd Claude, zanim obejrzy go człowiek. Recenzent analizuje proponowaną zmianę w kontekście szerszego repozytorium i deklarowanego celu pull requestu. W przypadku poprawek błędów próbuje wskazać przyczynę źródłową, zamiast sprawdzać wyłącznie widoczny patch.
Następnie kilka agentów równolegle szuka potencjalnych defektów. Kolejna grupa głosuje nad każdym ustaleniem, a system publikuje zgłoszenie tylko wtedy, gdy zgodzi się wystarczająca liczba recenzentów. Anthropic twierdzi, że testował filtry usuwające komentarze ograniczone do stylu, diagnostyki lub opcjonalnego sprzątania.
Pozostałe ustalenia otrzymują etykiety ważności. Programiści lub agenci muszą albo naprawić każde ustalenie, albo zamknąć jego wątek z uzasadnieniem. Oddzielny automatyczny przegląd bezpieczeństwa może również uniemożliwić scalenie, dopóki problem pozostaje nierozwiązany.
Przeglądy te funkcjonują obok konwencjonalnych zabezpieczeń. Pull requesty nadal przechodzą linting, kontrole typów, budowanie i testy na obsługiwanych platformach. Kolejka scalania ponownie uruchamia kontrole względem aktualnej głównej gałęzi, ograniczając awarie wynikające z niekorzystnej interakcji niezależnie poprawnych zmian.
Przegląd rozpoczyna się jeszcze przed utworzeniem pull requestu. Claude uruchamia testy, budowanie lub kontrole wizualne i wyświetla uzyskane dowody. Subagent ze świeżym kontekstem sprawdza następnie diff, co zmniejsza prawdopodobieństwo, że agent tworzący kod po prostu powtórzy swoje pierwotne założenia.
Wcześniejsze praktyki programistyczne Anthropic zalecały rozdzielenie kontekstów tworzenia i weryfikacji. Nowy przepływ pracy zamienia tę rekomendację w system operacyjny dla całego zespołu.
Ludzka akceptacja zależy od sklasyfikowanego ryzyka zmiany. Prace niskiego ryzyka mogą zostać scalone po przejściu automatycznych kontroli i kontroli bezpieczeństwa. Przykłady obejmują dokumentację, zmiany tekstów, funkcje wewnętrzne oraz dodatki ukryte za flagami funkcji.
Zwykła praca nad produktem zazwyczaj wymaga jednej osoby. Wrażliwe obszary, takie jak buforowanie, prompty systemowe i mechanizmy aktualizacji, również otrzymują ludzką uwagę. Zmiany o najwyższym ryzyku wymagają dwóch osób, natomiast niektóre chronione ścieżki zawsze uruchamiają ręczny przegląd.
Klasyfikator ocenia zmianę, a nie to, czy napisał ją człowiek czy agent. Drugi klasyfikator może mimo to zażądać udziału człowieka, gdy pierwotny poziom wydaje się zbyt pobłażliwy. Akceptacja agenta nigdy nie wypełnia miejsca zarezerwowanego dla człowieka.
To rozróżnienie ma znaczenie. Anthropic nie wyeliminował ludzkiej odpowiedzialności ani nie twierdzi, że przegląd AI czyni oprogramowanie bezbłędnym. Oddzielił rutynowe wykrywanie defektów od decyzji dotyczących architektury, kierunku produktu, wrażliwych systemów i akceptowalnego ryzyka.
Osoba, która wydała Claude polecenie, pozostaje odpowiedzialna za rezultat. Każda akceptacja dotyczy konkretnego commita, więc późniejsze zmiany mogą ją unieważnić. W modelu Anthropic delegowanie zmienia to, kto pisze i czyta kod, ale nie to, kto odpowiada za wynik.
Liczby sprawiają, że przegląd wyłącznie przez ludzi staje się nie do utrzymania
Raportowane przez Anthropic wskaźniki sugerują, że produkcja kodu już przerosła każdy proces przeglądu oparty na powszechnej ludzkiej lekturze.
Firma twierdzi, że liczba scalonych pull requestów w repozytorium Claude Code wzrosła ponad dwukrotnie między czerwcem a wrześniem 2026 r. W tym samym okresie udział wymagający wycofania spadł o ponad 40%.
Liczby te opisują kierunek, a nie pełną wydajność. Anthropic nie ujawnił bezwzględnej liczby pull requestów, pierwotnego wskaźnika wycofań, końcowego wskaźnika wycofań ani zmienności statystycznej. Względny spadek o 40% mógł zaczynać się zarówno od wysokiego, jak i niskiego poziomu bazowego.
Wartość 90% również wymaga ostrożnego sformułowania. Anthropic twierdzi, że Claude pisze około 90% kodu Claude Code. Nie oznacza to, że model samodzielnie wybiera priorytety produktu, definiuje każde wymaganie albo ponosi odpowiedzialność za wdrożenie.
Inżynierowie nadal kierują zadaniami, oceniają dowody, rozstrzygają kompromisy projektowe i decydują, czy dana praca powinna w ogóle istnieć. Autorstwo maszynowe mierzy generowanie kodu, podczas gdy inżynieria oprogramowania obejmuje znacznie więcej niż tworzenie linii kodu.
Nawet przy tych zastrzeżeniach Anthropic stoi przed rzeczywistym problemem skalowania. Jego oddzielny monorepozytorium miało podobno wzrosnąć z około 2 500 scalonych zmian dziennie w maju do ponad 30 000 we wrześniu. Firma stworzyła wewnętrzny system kontroli źródeł o nazwie Scion, aby obsłużyć to obciążenie.
Claude Code używa oddzielnego repozytorium, więc liczba 30 000 zmian nie mierzy bezpośrednio zespołu produktowego. Mimo to opis Anthropic dotyczący przeprojektowania kontroli źródeł pokazuje szerszą presję otaczającą jego infrastrukturę programistyczną.
Historie Scion i Claude Code wskazują na to samo wąskie gardło. Gdy agenci programistyczni mogą stale tworzyć, testować i poprawiać zmiany, pisanie kodu przestaje kontrolować przepustowość. Kolejki przeglądów, budowanie, uprawnienia, systemy integracji i kontrole wydań stają się czynnikami ograniczającymi.
Tradycyjny przegląd kodu zakłada, że od ludzi napływa możliwa do opanowania liczba zmian. Inna osoba czyta każdy diff, prosi o poprawki i zatwierdza ostateczną wersję. Model ten zaczyna się załamywać, gdy produkcja rośnie szybciej niż możliwości recenzentów.
Dodawanie recenzentów nie rozwiązuje w pełni tej rozbieżności. Doświadczeni inżynierowie są rzadcy, a ciągłe przeglądy przerywają pracę projektową, debugowanie i podejmowanie decyzji produktowych. Organizacja może zwiększać obsadę przeglądów, a mimo to tracić wspólną uwagę w obliczu rosnącego strumienia zmian.
Dlatego Anthropic mierzy więcej niż liczbę wygenerowanych komentarzy. Śledzi ludzkie akceptacje na pull request, komentarze ludzi, czas oczekiwania, wycofania i incydenty. Deklarowanym celem jest skrócenie czasu ludzkiego przeglądu bez przenoszenia go na odzyskiwanie sprawności w środowisku produkcyjnym.
Firma informuje także, że jej komercyjny recenzent AI zwiększył udział wewnętrznych pull requestów otrzymujących merytoryczne komentarze z 16% do 54%. Większość zmian przekraczających 1 000 linii ma podobno przyciągać ustalenia, podczas gdy większość mniejszych zmian wraca bez uwag.
Sam ten wynik nie potwierdza dokładności. Więcej komentarzy może oznaczać lepsze wykrywanie, więcej szumu albo jedno i drugie. Anthropic twierdzi, że ocenia jakość komentarzy, obserwując, czy programiści naprawiają ustalenia, odrzucają je, czy wskazują, że zgłoszone zachowanie było zamierzone.
Szerszy sygnał ma charakter organizacyjny. Anthropic nie traktuje już ludzkiego czytania każdej zmienionej linii jako definiującego dowodu przeglądu. Mierzy, czy połączony system wykrywa problemy, dobrze kieruje uwagę i ogranicza szkody produkcyjne.
Ta zmiana wywiera presję na każdą organizację inżynieryjną wdrażającą agentów programistycznych. Jeśli produkcja agentów rośnie, a polityka przeglądu pozostaje stała, kolejki się wydłużają, a oczekiwane korzyści produktywności znikają. Zespoły muszą albo ograniczyć generowanie, albo przeprojektować sposób walidowania go.
Zautomatyzowane pokrycie kwestionuje powszechną ludzką inspekcję
Centralna rywalizacja dotyczy szerokiego pokrycia maszynowego i przekonania, że każda istotna zmiana zasługuje na bezpośrednią ludzką lekturę.
Powszechna ludzka inspekcja oferuje intuicyjną obietnicę. Wykwalifikowany inżynier rozumie kod, widzi zmianę i przyjmuje odpowiedzialność, zanim trafi ona do wdrożenia. Taka praktyka może upowszechniać wiedzę, jednocześnie wychwytując założenia pomijane przez automatyczne testy.
Obietnica ta słabnie jednak, gdy przegląd staje się pośpieszny. Osoba stojąca przed dużą kolejką może jedynie przeglądać kod zamiast go analizować, zatwierdzać znajomo wyglądający kod lub skupiać się na stylu zamiast na zachowaniu. Ludzki podpis nie gwarantuje zrozumienia.
Alternatywa Anthropic wykorzystuje wiele wyspecjalizowanych warstw. Jeden agent tworzy zmianę, inny recenzuje ją ze świeżym kontekstem, kilku agentów szuka błędów, a oddzielni agenci oceniają każde ustalenie. Przegląd bezpieczeństwa, ciągła integracja, kontrole scalania, etapowe wydanie i wycofanie zmian obejmują różne tryby awarii.
Przypomina to obronę warstwową. Żadna pojedyncza warstwa nie potrzebuje doskonałego wykrywania, ponieważ późniejsze warstwy mogą wychwycić to, co ominęło wcześniejsze. Klasyfikacja ryzyka kieruje następnie ograniczony ludzki osąd ku zmianom o większym potencjalnym wpływie.
Mechanizm zapewnia również Anthropic szersze pokrycie przeglądów. Maszyny mogą sprawdzać każdy pull request bez oczekiwania na harmonogram kolegi. Mogą analizować kontekst repozytorium, stosować udokumentowane konwencje i powtarzać te same kontrole dla tysięcy zmian.
Instrukcje zapisane w CLAUDE.md opisują projekt, jego konwencje i granice. Oddzielny plik REVIEW.md mówi recenzentowi, jak wygląda awaria w konkretnym repozytorium. Właściciele kodu mogą wskazywać wrażliwe ścieżki i wykluczać nieistotne.
Gdy recenzent wielokrotnie zgłasza ten sam błąd, zespół może przenieść tę lekcję wcześniej w procesie. Może dodać regułę lintingu, ulepszyć plik instrukcji, zmodyfikować umiejętność lub stworzyć nową automatyczną kontrolę. Informacje zwrotne z przeglądu stają się wówczas infrastrukturą wielokrotnego użytku.
Wcześniejsze awarie stają się przypadkami ewaluacyjnymi. Anthropic twierdzi, że zebrał pull requesty powiązane z incydentami, wycofaniami i późniejszymi poprawkami. Inżynierowie zweryfikowali leżące u ich podstaw błędy, a recenzent działa teraz względem tego zestawu każdego dnia.
To znaczące odejście od przeglądu jako spotkania dwóch osób. System próbuje zachować lekcje w wykonywalnych kontrolach, zamiast polegać na indywidualnej pamięci. Każdy incydent może rozszerzać przyszłe pokrycie wykrywania w organizacji.
Mimo to ludzki przegląd nadal zajmuje się pytaniami, których nie da się sprowadzić do lokalnej poprawności. Inżynierowie decydują, czy funkcja powinna istnieć, czy abstrakcja ustanawia szkodliwy precedens oraz czy dowody uzasadniają wdrożenie.
Monitorują też wrażliwe obszary, w tym rozliczenia, mechanizmy aktualizacji, ciągłą integrację i procesy wydań. Zmiany w tych obszarach mogą mieć szerokie skutki, nawet jeśli kod wygląda lokalnie na poprawny.
Proces ten nie zakłada więc, że maszyny są lepszymi recenzentami pod każdym względem. Przydziela maszynom zadania czytelnicze, które mogą wykonywać wielokrotnie, a ludziom — decyzje dotyczące celu, architektury, niepewności i odpowiedzialności.
Ten podział zmienia również wymagane umiejętności inżynierskie. Inżynierowie muszą umieć precyzować intencje, identyfikować ograniczenia, projektować weryfikację, interpretować dowody i rozpoznawać sytuacje, w których agent zoptymalizował niewłaściwy cel. Czytanie kodu nadal jest przydatne, ale nie jest już jedyną drogą do zrozumienia.
Zespół Scion firmy Anthropic przedstawił powiązany przykład. Inżynierowie zgłosili, że Claude czasami wybierał nieefektywne lub nadmiernie defensywne projekty, które pasowały do lokalnych wzorców. Ludzie musieli odrzucać te kierunki, ponieważ rozumieli kompromisy na poziomie całego systemu.
Określenie „human in the loop” może zacierać znaczenie tej roli. Osoba, która jedynie zatwierdza wynik maszyny, jest słabym zabezpieczeniem. Osoba wyznaczająca granice, dobierająca dowody i wiedząca, kiedy zatrzymać automatyzację, zapewnia rzeczywistą kontrolę.
Dla innych organizacji wniosek nie polega na usunięciu recenzentów. Chodzi o odróżnienie mechanicznej inspekcji od osądu. Zautomatyzowane pokrycie staje się wartościowe, gdy ludzie zachowują uprawnienia do podejmowania decyzji o poważnych konsekwencjach i oceny niejednoznacznych dowodów.
Jak recenzje Claude Code unikają niekończących się pętli agentów
Anthropic odkrył, że autorzy AI i recenzenci AI mogą tworzyć nieograniczoną ilość pracy, jeśli proces recenzji nie zostanie wyraźnie zaprojektowany tak, by zbiegał do końca.
Więcej recenzji nie oznacza automatycznie lepszego rezultatu. Anthropic opisuje jeden pull request Claude Code, który w ciągu nocy przeszedł ponad 50 rund recenzji i poprawek. Autor ostatecznie zatrzymał tę pętlę.
Recenzent nie wykrywał w każdej rundzie nowego krytycznego defektu. Anthropic wykorzystał historię wersji do analizy powtarzających się ustaleń i stwierdził, że około 59% dotyczyło kodu obecnego już podczas pierwszej recenzji.
Agent nadal znajdował kolejne stare problemy, zamiast oceniać wyłącznie nową poprawkę. Każdy komentarz uruchamiał kolejną poprawkę, commit i recenzję. System pozostawał aktywny, ale nie zmierzał sprawnie do akceptowalnego stanu końcowego.
Ta porażka ilustruje charakterystyczne ryzyko recenzji kodu przez AI. Człowiek może w ciągu kilku sekund odrzucić sugestię o niskiej wartości. Agent tworzący kod ma tendencję do reagowania na nią, wytwarzając kolejny diff, który daje agentowi recenzującemu więcej materiału.
Anthropic odpowiedział mechanizmami kontroli zbieżności. Po trzech rundach recenzent prosi autora o ponowne rozważenie podejścia. Kolejne przebiegi skupiają się na nowym diffie, zamiast wielokrotnie przeszukiwać całą zmianę.
Recenzent zgłasza także od razu całą klasę powiązanych defektów. Pozwala to autorowi naprawić każdy przypadek, zamiast otrzymywać podobne komentarze w kolejnych rundach. Wcześniej zgłoszone ustalenia nie powinny pojawiać się ponownie.
Anthropic twierdzi, że te zmiany usprawniły jego wewnętrzny cykl recenzji. Odsetek pull requestów przechodzących po jednej rundzie recenzji i poprawek miał wzrosnąć z 65% do 78%.
Odsetek pull requestów wymagających pięciu lub więcej rund miał spaść z 8,9% do 1,5%. Średnia liczba recenzji przed przejściem spadła z 2,08 do 1,32. Wskaźniki te nadal są raportowane przez samą firmę, ale dotyczą problemu operacyjnego, który wiele przepływów pracy z agentami pomija.
Zbieżność ma znaczenie, ponieważ zautomatyzowana praca nie jest darmowa tylko dlatego, że nie wiąże się z pensją. Każda dodatkowa runda zużywa zasoby modeli, opóźnia zmianę, tworzy więcej kodu i zwiększa ilość materiału, który muszą później sprawdzić kolejne kontrole.
Ten sam problem pojawia się, gdy recenzenci nadmiernie reagują na hipotetyczne zagrożenia. Anthropic twierdzi, że recenzja adversarialna może stać się krótkowzroczna, zachęcając do nadmiernej walidacji lub złożoności. System zoptymalizowany pod kątem wykrywania możliwych awarii może generować nowe koszty utrzymania.
Jednym z mechanizmów kontroli jest głębokość zależna od ryzyka. Powszechnie dostępna usługa Code Review firmy Anthropic obsługuje różne poziomy recenzji dla rutynowych i krytycznych repozytoriów. Firma twierdzi, że większość recenzji kończy się obecnie w sześć do dziesięciu minut.
Szybszy recenzent nie rozwiązuje jednak podstawowej kwestii zarządzania. Zespoły nadal muszą zdecydować, które ustalenia są istotne, które ścieżki zasługują na głębszą inspekcję i ile cykli jest akceptowalne.
Instrukcje recenzji również mogą stać się ukrytą warstwą polityki. Jeśli CLAUDE.md, REVIEW.md lub prompty klasyfikacyjne zawierają słabe założenia, agenci mogą konsekwentnie stosować je w całym repozytorium.
Spójność pomaga tylko wtedy, gdy reguła jest poprawna. Zespoły potrzebują właściciela, kontroli wersji, przypadków ewaluacyjnych i recenzji instrukcji kierujących pracą ich recenzentów. W przeciwnym razie automatyzacja może skalować błędną politykę szybciej, niż ludzie ją zauważą.
W tym miejscu istotny staje się wspólny kontekst inżynierski. Organizacje wdrażające agentów potrzebują trwałych zapisów decyzji architektonicznych, wniosków z incydentów i odrzuconych podejść. Przeszukiwalna baza wiedzy inżynierskiej może pomóc zachować ten kontekst poza pojedynczym wątkiem recenzji.
Proces Anthropic działa, ponieważ firma traktuje recenzenta jako system wymagający pomiaru. Śledzi dokładność, szum, liczbę rund, incydenty i reakcje deweloperów. Instalacja recenzenta AI bez tych pętli sprzężenia zwrotnego kopiowałaby widoczne narzędzie, ale pomijała model operacyjny.
Czego wyniki Anthropic jeszcze nie dowodzą
Najmocniejsze twierdzenia nadal są raportowane przez samą firmę, a Anthropic nie wykazał, że jego wyniki przenoszą się na zespoły o infrastrukturze, budżetach lub tolerancji ryzyka innych niż jego własne.
Pierwsza niepewność dotyczy pomiaru. Anthropic podał, że liczba scalonych pull requestów wzrosła ponad dwukrotnie, a udział cofnięć spadł o ponad 40%. Firma nie opublikowała jednak bazowego zbioru danych, wartości bezwzględnych ani rozkładu powagi incydentów.
Malejący udział cofnięć może być zachęcający, a jednocześnie ukrywać istotne rezultaty. Zespoły mogą naprawiać problemy kolejnymi zmianami zamiast cofać wdrożenie, wyłączać flagę funkcji lub tolerować regresję, która nigdy nie otrzyma takiej etykiety. Cofnięcia są przydatne, lecz niepełne.
Wskaźniki incydentów stanowią kolejne zabezpieczenie, jednak publiczny wpis nie przedstawia szczegółowej serii incydentów. Bez danych o powadze i ekspozycji obserwatorzy z zewnątrz nie mogą stwierdzić, czy proces zmniejszył ryzyko, czy jedynie zmienił sposób obsługi awarii.
Liczba 90% autorstwa niesie podobną niejednoznaczność. Nie precyzuje, czy pomiar obejmuje wygenerowane linie, zaakceptowane linie, commity czy inną jednostkę. Nie ujawnia również, ile ludzkiego promptowania, edycji i iteracji poprzedziło finalny kod.
Środowisko Anthropic jest wyjątkowo sprzyjające tej metodzie. Firma kontroluje modele, może przeznaczać znaczne zasoby obliczeniowe na równoległych recenzentów i rozwija wewnętrzną infrastrukturę wokół obciążeń generowanych przez agentów.
Jej pracownicy używają też Claude Code wewnętrznie przed publicznymi wydaniami. Nowe funkcje mogą przechodzić przez wdrożenie wewnętrzne, kanał latest, a następnie kanał stable. Flagi funkcji pozwalają zespołowi wyłączyć dane zachowanie bez pełnego wdrożenia.
Zespoły obsługujące systemy medyczne, finansowe, przemysłowe lub krytyczne dla bezpieczeństwa mogą podlegać innym wymaganiom. Szybkie wycofanie nie jest w stanie odwrócić każdej konsekwencji. Błędna migracja danych, zmiana autoryzacji lub działanie zewnętrzne mogą wyrządzić nieodwracalną szkodę.
Anthropic przyznaje, że wykrywanie błędnych scaleń nadal zależy od autorów, inżynierów dyżurnych, telemetrii i pulpitów monitoringu. Firma nie ma jeszcze automatycznych wyłączników bezpieczeństwa, które podnosiłyby wymagania zatwierdzania, gdy rośnie liczba cofnięć lub incydentów.
Ta luka ma znaczenie, ponieważ klasyfikacja ryzyka może się zdezaktualizować. Zmiana oznaczona jako niskiego ryzyka może wejść w interakcję z ukrytymi zależnościami. Seria indywidualnie bezpiecznych zmian może również doprowadzić do niebezpiecznego stanu łącznego.
Bezpieczeństwo wprowadza kolejną obawę. Anthropic korzysta z automatycznej recenzji bezpieczeństwa, ale jego własne materiały dotyczące ryzyka pokazują, dlaczego nadzór człowieka pozostaje konieczny. Jego ocena sabotażu opisuje monitorowanie modeli jako rozwijający się mechanizm kontroli, a nie pełną gwarancję.
Reakcje społeczności wzbudziły szersze pytania dotyczące kosztów i zrozumienia. Niektórzy deweloperzy twierdzą, że Anthropic może utrzymywać wzorce recenzji, które gdzie indziej byłyby nieopłacalne. Inni obawiają się, że mniej osób czytających diffy osłabi zbiorową wiedzę o bazie kodu.
Anthropic otwarcie stwierdza, że nikt w zespole Claude Code nie utrzymuje pełnego mentalnego modelu produktu. Inżynierowie zamiast tego proszą Claude o wyjaśnienie odpowiedniego podsystemu, gdy go potrzebują.
Takie podejście może utrzymywać wyjaśnienia w aktualności, ale tworzy zależność. Jeśli wygenerowane wyjaśnienie pominie interakcję, inżynier może podjąć decyzję na podstawie niepełnej mapy. Ta sama rodzina modeli może również powtarzać założenia zakodowane w kodzie, który recenzuje.
Recenzja między modelami mogłaby zapewnić dodatkową różnorodność, ale nie poprawia automatycznie dokładności. Różne systemy mogą dzielić wzorce treningowe lub zawodzić z niepowiązanych powodów. Istotną właściwością są niezależne dowody, a nie tylko inna nazwa modelu.
Żadne z tych pytań nie unieważnia wyników raportowanych przez Anthropic. Ograniczają one to, co wyniki te potwierdzają. Firma pokazała szczegółowy proces wewnętrzny z zachęcającymi wskaźnikami kierunkowymi, a nie uniwersalny zamiennik ludzkiej recenzji kodu.
Trzy sygnały sprawdzą, czy model się utrzyma
Kolejnym testem będzie to, czy Anthropic zdoła utrzymać jakość wraz z rozszerzaniem scaleń bez udziału człowieka, udostępnianiem produktów recenzujących innym firmom i przyjmowaniem przez konkurentów innych mechanizmów kontroli.
Pierwszym sygnałem jest własna polityka zatwierdzania Anthropic. Obecny proces pozwala wybranym zmianom o niskim ryzyku scalać się bez osobnego recenzenta-człowieka po przejściu automatycznych kontroli.
Warto obserwować, czy ta granica rozszerzy się na większą część kodu produktu. Jeśli Anthropic doda wyłączniki bezpieczeństwa, których oczekują jego inżynierowie, automatyczna eskalacja może zwiększyć wiarygodność szerszego wdrożenia. Rosnąca liczba incydentów lub powrót do bardziej rygorystycznych zatwierdzeń osłabiłyby tezę.
Drugim sygnałem będą dowody od zewnętrznych organizacji korzystających z automatycznej recenzji. Anthropic udostępnił Code Review klientom Team i Enterprise, tworząc szerszy test w nieznanych repozytoriach i kulturach inżynierskich.
Przydatnymi wskaźnikami nie będą liczba komentarzy ani zrecenzowanych pull requestów. Zespoły powinny raportować zaakceptowane ustalenia, defekty, które przedostały się dalej, fałszywe pozytywy, opóźnienia recenzji, nakład pracy ludzi i incydenty produkcyjne.
Porównywalne wyniki poza Anthropic wzmocniłyby tezę, że warstwowa recenzja AI może się skalować. Duży szum, rosnące wykorzystanie modeli lub niezmienione wskaźniki incydentów sugerowałyby, że sukces Anthropic zależy od jego wewnętrznego środowiska.
Trzecim sygnałem jest reakcja konkurencji. OpenAI, GitHub, Google, Cursor i inni dostawcy agentów programistycznych mierzą się z tą samą nierównowagą między generowanym kodem a zdolnością recenzentów.
Ich wybory pokażą, czy recenzja oparta na ryzyku stanie się wspólnym wzorcem. Konkurencyjne systemy mogą preferować recenzję między modelami, silniejsze sandboxowanie, formalną weryfikację, ewaluację specyficzną dla repozytorium lub trwalsze zatwierdzanie przez człowieka.
Deweloperzy powinni oprzeć się pokusie sprowadzania tej debaty do pytania, czy AI potrafi znajdować błędy. Praktyczne pytanie brzmi, czy kompletny system recenzji potrafi właściwie rozdzielać uwagę, zachowywać odpowiedzialność i bezpiecznie odzyskiwać sprawność, gdy każda warstwa coś przeoczy.
Dla liderów inżynieryjnych natychmiastowym działaniem jest pomiar. Ustalcie bazowy czas recenzji, defekty, które przedostały się dalej, fałszywe pozytywy, wskaźniki cofnięć i wagę incydentów przed zmianą polityki zatwierdzania. Bez takiej bazy szybsze scalanie może wyglądać na poprawę, podczas gdy koszty zostają jedynie przeniesione gdzie indziej.
Zespoły powinny też oddzielać zmiany odwracalne od nieodwracalnych. Dokumentacja, oznaczone korekty interfejsu i narzędzia wewnętrzne nie wymagają takiego samego procesu jak uwierzytelnianie, rozliczenia, migracje czy infrastruktura wydaniowa.
Przegląd Anthropic Claude Code oferuje konkretną odpowiedź na problem, z którym wiele zespołów wkrótce się zmierzy. Traktuje on przegląd jako wielowarstwowy system kontroli, a nie dowód na to, że człowiek przeczytał każdą linię.
Raportowane przez firmę dane sprawiają, że warto tę odpowiedź przetestować, a nie bezrefleksyjnie kopiować. Jeśli jutro wasi agenci podwoją ilość generowanego kodu, jakie dowody pozwoliłyby waszym recenzentom bezpiecznie przestać czytać wszystko już dziś?
