Agenci kodujący nie tylko zawodzą — oni gniją: odkrycie SlopCodeBench

Oto liczba, która powinna zresetować sposób, w jaki myślisz o agentach kodujących działających długo: w gronie 11 modeli i 93 punktów kontrolnych żaden agent nie rozwiązał ani jednego problemu od początku do końca, a najlepszy współczynnik rozwiązań na punkt kontrolny wyniósł 17,2%. A oto liczba, która wyjaśnia dlaczego: kod pisany przez agentów jest 2,2x bardziej rozwlekły niż kod open source, który ludzie naprawdę wypuszczają. To zestawienie — agenci, którzy nie potrafią skończyć, produkujący kod, który puchnie po drodze — stanowi serce SlopCodeBench (Orlanski i in., arXiv 2603.24755, marzec 2026) i podkłada twarde dane pod tezę, którą jakościowo stawiamy już od jakiegoś czasu.

Pisaliśmy już o tym, jak agenci stają się gorsi, im dłużej działają. Tamten wpis opisywał zachowanie. SlopCodeBench daje nam mechanizm — zmierzony, powtarzalny i niewygodnie precyzyjny. Agenci kodujący nie tylko zawodzą. Oni zgniwają kod pod sobą, tura po turze, a większość tego gnicia jest niewidoczna, dopóki nie przeczytasz diffa.

Eksperyment: zmuś agenta, by żył z własnym kodem

Większość benchmarków kodujących jest jednorazowa. Wpada problem, agent emituje rozwiązanie, oceniasz je i przechodzisz dalej. Taki projekt nie potrafi dostrzec gnicia, bo gnicie jest funkcją czasu — agenta dziedziczącego i rozszerzającego własne wcześniejsze decyzje.

SlopCodeBench jest zbudowany, by obnażyć dokładnie to. Bierze 20 problemów i zamienia każdy w łańcuch ewoluujących specyfikacji: agent pisze kod, potem specyfikacja się zmienia, a agent musi rozszerzyć własne wcześniejsze rozwiązanie, zamiast zaczynać od zera. W gronie tych problemów benchmark definiuje 93 punkty kontrolne i przepuszcza przez całą próbę 11 modeli. Co kluczowe, wewnętrzna struktura kodu pozostaje całkowicie w gestii agenta — nic w harnessie nie wymusza czystej architektury, więc benchmark może obserwować, jak wczesne skróty agenta kumulują się w późniejszy bałagan.

To, co znalazł, jest dwuczęściowym aktem oskarżenia:

Agenci tak naprawdę nie potrafią skończyć. Żaden model nie rozwiązał żadnego problemu w całości przez całą jego ewoluującą specyfikację. Najlepszy pojedynczy współczynnik rozwiązań na punkt kontrolny w gronie wszystkich 11 modeli wyniósł 17,2%. To nie są problemy z gatunku przypadków brzegowych; to ciągłe, iteracyjne zadania dokładnie tego rodzaju, z jakiego zbudowana jest prawdziwa praca nad oprogramowaniem.
Kod degraduje się po drodze. SlopCodeBench śledzi dwa odrębne sygnały rozpadu — erozję strukturalną (złożoność piętrząca się w niewłaściwych miejscach) i rozwlekłość (nadmiarowy, rozdęty kod). Erozja strukturalna rosła na przestrzeni przebiegu w 80% trajektorii. Rozwlekłość rosła w 89,8%. W porównaniu z prawdziwymi repozytoriami open source kod agentów okazał się 2,2x bardziej rozwlekły.

Tym, co czyni to obciążającym, jest grupa kontrolna. Gdy autorzy przyjrzeli się temu, jak ewoluuje kod ludzki na przestrzeni własnej historii wersji, pozostał on zasadniczo płaski — ludzie refaktoryzują, przycinają i utrzymują złożoność mniej więcej na stałym poziomie w miarę, jak projekt rośnie. Kod agenta robi coś przeciwnego. Każda tura dokłada więcej, niż powinna, na fundamencie, który każda poprzednia tura już zerodowała. Agent przechodzi punkt kontrolny i degraduje bazę kodu w tym samym ruchu.

To jest właśnie definicja gnicia: nie pojedyncza katastrofalna porażka, lecz monotoniczny spadek, który każdy pojedynczy krok potrafi sobie zracjonalizować.

Dlaczego gnicie się kumuluje, zamiast się uśredniać

Gdyby porażki były niezależne, mógłbyś rozumować o nich za pomocą prostego rachunku prawdopodobieństwa — uruchom więcej, ponów te złe, oczekuj, że prawo wielkich liczb cię uratuje. Towarzyszące badania mówią, że ta intuicja jest błędna.

Niezawodność jako własność dwuwymiarowa (Khanal i in., arXiv 2603.29231, marzec 2026) zmierzyła 10 modeli w czterech koszykach czasu trwania zadania i wykazała, że agregowany pass@1 spada z 76,3% przy zadaniach o krótkim horyzoncie do 52,1% przy bardzo długich — spadek o 24,3 punktu. Najważniejszy jest kształt tego spadku: jest on superliniowy w porównaniu z bazową linią i.i.d. Bernoulliego, którą uzyskałbyś, gdyby każdy krok zawodził niezależnie. Mówiąc wprost, porażki korelują. Jedna zła decyzja podnosi szanse na następną. Agent rozumujący nad bazą kodu, którą jego wcześniejsze tury uczyniły trudniejszą do rozumowania, jest bardziej skłonny pogorszyć następną turę, a nie tak samo skłonny.

Dlatego naiwny rachunek ponawiania zaniża ryzyko, i to jest ilościowy szkielet tego, co nazwaliśmy luką niezawodności: metryki na poziomie kroku, mierzone na krótkich zadaniach, systematycznie kłamią na temat zachowania o długim horyzoncie, bo zakładają niezależność, której dane odmawiają udzielić. Gnicie to nie szum, który można uśrednić. To trend, a trend wskazuje w dół.

Znalezienie miejsca, w którym pętla wykoleiła się

Wiedza, że długie przebiegi gniją, to jedno; zlokalizowanie tury, w której gnicie się zaczęło, to coś innego — a nie naprawisz tego, czego nie potrafisz przypisać. To wkład HORIZON (Wang i in., arXiv 2604.11978, kwiecień 2026), międzydomenowego benchmarku diagnostycznego sprzężonego z pipeline’em LLM-as-a-Judge ugruntowanym w trajektorii, służącym do przypisywania porażek, a nie zwykłego oceniania pass/fail.

Zbudowany na ponad 3 100 trajektoriach w czterech domenach agentowych, sędzia HORIZON jest zwalidowany przez ludzi, osiągając κ = 0,84 zgodności z ludzkimi anotatorami (przy κ między anotatorami wynoszącym 0,61 — sędzia maszynowy zgadza się z ludźmi bardziej, niż ludzie zgadzają się między sobą). Potwierdza on znany już kształt — agenci dobrze radzą sobie z zadaniami o krótkim i średnim horyzoncie, a potem załamują się przy zadaniach o długim horyzoncie — ale jego prawdziwa wartość polega na zamianie tego załamania w coś diagnozowalnego. Zamiast „przebieg zawiódł” dostajesz „przebieg wykoleił się w tym kroku, w taki sposób”.

To przeformułowuje ewaluację z oceny w przyrząd. Argumentowaliśmy we wpisie kto sądzi sędziego, że ewaluator LLM jest sam w sobie komponentem pętli, który trzeba zwalidować, a nie neutralną wyrocznią. HORIZON to ta sama idea wycelowana w trajektorie: zwalidowany sędzia, który lokalizuje gnicie wewnątrz przebiegu, jest różnicą między wiedzą, że twój agent degraduje, a wiedzą, która tura zapoczątkowała degradację — a to jedyna wiedza, na podstawie której naprawdę możesz działać.

Dlaczego dotyka to Azję Południowo-Wschodnią inaczej

W dużej, dobrze obsadzonej organizacji inżynierskiej gnicie kodu ma bufor zrobiony z ludzi: starsi recenzenci, dedykowany QA, luz na rzucenie kilku inżynierów do refaktoru, gdy moduł robi się brzydki. Gnicie i tak cię kosztuje, ale głęboka ławka je amortyzuje.

Dwu- albo pięcioosobowy zespół w Phnom Penh czy Da Nang takiej ławki nie ma. Nie ma recenzenta czekającego niżej w przepływie, by wyłapać slop z dwudziestej tury agenta, zanim trafi do produkcji. Dla zespołu lekkiego kapitałowo gnicie agenta trafia bezpośrednio do produktu, a inżynier, który musi z nim żyć, to ten sam, który je wypuścił. Brzmi to jak wada — i byłoby nią, gdyby jedyną naprawą było więcej etatów.

Ale naprawą nie są etaty. To projekt pętli, a projekt pętli działa na laptopie. Zespół, który przyswoi wynik SlopCodeBench, przestaje wskazywać agentowi frontierowemu wielkie zadanie i pozwalać mu działać godzinami — to dokładnie ten reżim, w którym gnicie jest najgorsze, a rachunek za tokeny najwyższy. Zamiast tego inżynieruje pętlę tak, by gnicie nigdy nie zyskało przyczółka. To nie ruch z większym budżetem; to ruch z lepszym osądem, a osąd jest tym jedynym wkładem, w którym mały zespół naprawdę potrafi wygrać konkurencję.

Parametry pętli, które zatrzymują gnicie

SlopCodeBench przetestował oczywistą naprawę werbalną — powiedzenie agentowi, by pisał czysty kod — i stwierdził, że poprawia ona punkt startowy bez zmiany tempa rozpadu. Prompt czyni turę pierwszą schludniejszą; nic nie robi z nachyleniem. Działające przeciwśrodki są strukturalne i czysto mapują się na punkty kontrolne z naszego modelu dojrzałości inżynierii pętli:

Budżety tokenów z twardymi kryteriami przerwania. Ustaw pułap na jednostkę pracy i limit maksymalnej liczby iteracji, i egzekwuj to. Ponieważ porażki korelują superliniowo, marginalna tura głęboko w długim przebiegu jest najbardziej skłonna do gnicia — więc przebieg, który już się męczy, to dokładnie ten, który należy zatrzymać, a nie wydłużać. Kryterium przerwania („przekaż dalej po N zaciętych iteracjach”) to bezpiecznik chroniący przed gniciem.
Okresowe resety / punkty kontrolne refaktoru. Krzywa rozpadu jest funkcją tego, ile tur jedzie na tym samym erodującym fundamencie. Wstaw jawne tury refaktoru, których jedynym zadaniem jest redukcja erozji strukturalnej i rozwlekłości, oraz resetuj okno kontekstu między obramowanymi jednostkami, tak by trwały stan żył w zatwierdzonych artefaktach, a nie w wciąż rosnącym transkrypcie. Świeże okno odmawia gniciu miejsca do kumulowania się.
Skaluj na małe, weryfikuj twardo, zatwierdzaj czysto. Rozłóż pracę tak, by każda jednostka startowała z czystej linii bazowej, zamiast dziedziczyć dwadzieścia tur slopu, weryfikuj każdą jednostkę end-to-end i zatwierdzaj działający stan, by zgniłą gałąź można było porzucić, a nie rozszerzać. To ta sama dyscyplina jednej funkcji naraz, do której wciąż wracamy — a SlopCodeBench to dane, które wyjaśniają, dlaczego ona działa.
Instrumentuj pod przypisywanie, a nie tylko pass/fail. Pożycz postawę HORIZON: śledź, gdzie trajektorie się wykolejają, by twoje kryteria przerwania i punkty kontrolne refaktoru lądowały tam, gdzie gnicie naprawdę się zaczyna, zamiast tam, gdzie zgadłeś, że może.

Punkt spinający to ten, który cały ten korpus badań wciąż potwierdza: degradacja jest właściwością kształtu pętli, a nie IQ modelu. Model frontierowy w niechlujnym długim przebiegu zgnije własną pracę. Skromny model w pętli, która ciasno obramowuje, twardo budżetuje, często resetuje i przypisuje swoje porażki, utrzyma jakość znacznie dłużej — za mniej tokenów. Laboratoria będą dalej wypuszczać agentów, którzy potrafią działać dłużej. Dyscyplina, by uruchamiać ich dobrze, to część, której żadne wydanie modelu nie czyni przestarzałą, i jest dostępna dla każdego, kto zechce zaprojektować pętlę, zamiast ufać przebiegowi.