A potem zadałem im pytanie, na które nie umiały odpowiedzieć: ile to kosztowało?

Że artefakt jest wystarczająco dobry — to wiedziały. Czy dojście do tego werdyktu zajęło czterdzieści minut czy cztery godziny, dwanaście dolarów czy dwieście — nie miały pojęcia. Czystej akceptacji za pierwszym podejściem nie odróżniały od przebiegu, który dowlókł się do mety przy dziesiątej próbie z tym samym nierozwiązanym problemem.

To nie są te same wyniki. Tylko jeden z nich to działający system.

Limit, który ogranicza nie to, co trzeba

Miałem limity iteracji — najwyżej dziesięć pętli na fazę. Wyglądało to na kontrolę. Nie jest. Limit iteracji ogranicza liczbę przebiegów pętli, a nie koszt jednej tury, a u mnie jedna runda recenzji rozchodzi się na ośmiu weryfikatorów pracujących równolegle. Ten jeden krok potrafi kosztować więcej niż wszystkie wcześniejsze fazy razem i żaden limit tego nie zauważa.

Dopisałem więc księgę wydatków. Budżet zadeklarowany przed startem. Sprawdzany przy przejściu między fazami i przy każdym cofnięciu, nigdy w środku pracy. Przekroczysz krawędź, będąc już nad limitem, i przebieg staje z jawnym werdyktem, zamiast po cichu dojechać do końca i wystawić ci rachunek.

Najbardziej niedoszacowałem analizy trasy. Liczy ona wydatek, który nie posunął przebiegu do przodu — wszystko, co poszło na próby zakończone cofnięciem — i wyłapuje powtarzające się powody. Ta ostatnia liczba jest nieprzyjemna. Przebieg, który zaliczył bramkę przy dziesiątym identycznym podejściu, to przebieg nieudany z przypiętą plakietką „zdane". W moich starych raportach nie było tego widać w ogóle.

Dlaczego to warte więcej, niż wygląda

Jest marcowe badanie, przez które przemyślałem od nowa, co w ogóle dokładam agentowi.

Badacze dali agentowi kodującemu jedną dodatkową rzecz: mapę tego, które testy pokrywają który kod, podaną jako zwykły plik tekstowy do przeczytania. Regresje — testy, które wcześniej przechodziły i przestały — spadły z 6,08% do 1,82%. Spadek o 70% z jednego pliku.

To samo badanie miało drugą gałąź. Zamiast mapy agent dostał instrukcje proceduralne: pracuj testami naprzód, trzymaj się tej dyscypliny. Regresje wzrosły do 9,94%. Czyli gorzej, niż gdyby nie robić nic.

Dlatego budżet siedzi w pliku ze stanem, a nie w promptcie proszącym agenta, żeby uważał na pieniądze. Nikt nie będzie uważał na liczbę, której nie widzi.

Poszedłem więc po liczby.

Na publicznych rankingach da się czasem trafić ten sam model puszczony pod dwoma różnymi harnessami. Różnica: od trzech do ośmiu punktów procentowych. A wystarczy zostawić harness w spokoju i podmienić model pod spodem, żeby wynik ruszył się o dwadzieścia pięć.

Przeczytaj tylko tyle, a wniosek napisze się sam: harness prawie nie ma znaczenia, kup lepszy model, idź do domu.

Tylko że nikt z nas nie boi się o to

Te benchmarki mierzą jedno zadanie w jednym kontenerze, które przechodzi albo nie przechodzi. Nikt na produkcji nie traci snu przez jedno zadanie w jednym kontenerze.

Sen odbiera co innego. System, który wywraca się co kilka dni. Wynik, którego we wtorek nie da się powtórzyć. Werdykt, którego potem nikt nie zaudytuje. Przebieg, który melduje sukces, a plik, w którym rzekomo coś poprawił, po prostu sobie wymyślił.

I właśnie na to — na stabilność, powtarzalność, audytowalność — nie ma żadnego publicznego benchmarku. Najbliższa próba, jaką znalazłem, ma trzy tygodnie, a jej własny prerejestrowany audyt wyszedł nierozstrzygnięty.

Tam, gdzie liczby jednak są, nie są małe. Jedno badanie ścięło regresje o 70%, podając agentowi jeden plik z kontekstem. Inne zmierzyło spadek nieudanych zadań o 9,5% po dodaniu krytyka, który sprawdza plan przed wykonaniem. Jedno i drugie to zmiana w harnessie. Ani jedna, ani druga nie pojawi się w rankingu.

Na razie ciężar spada więc na ciebie. Mierz to, na czym naprawdę ci zależy: jak często pada system, ile pracy wraca do poprawki, jak często werdykt broni się w przeglądzie. Nikt nie opublikuje tego za ciebie.

Moja własna strona przez trzy tygodnie serwowała wersję sprzed dwóch commitów, a ja nie miałem o tym pojęcia.

Przebieg wydarzeń. 6 sierpnia wypchnąłem dwie zmiany na podstronie. Ruszyły trzy wdrożenia. Wszystkie trzy padły. Każde zapisało czas builda równy zeru milisekund i komunikat „Page build failed." Bez szczegółów, bez powiadomienia, nic w skrzynce.

Zero milisekund znaczy, że build nawet nie wystartował, więc nie chodziło o mój kod. Położyło się coś wyżej.

A strona? Strona miała się świetnie. HTTP 200, ważny certyfikat, wszystko się ładuje. Bo dalej szedł ostatni udany build, dokładnie tak jak dzień wcześniej. Awaria nie miała żadnej widocznej powierzchni. Z zewnątrz, z mojej przeglądarki, z czyjejkolwiek innej — zdrowa strona.

Znalazłem to tylko dlatego, że dłubałem przy czymś zupełnie niezwiązanym i z ciekawości zajrzałem w status wdrożeń.

Nieprzyjemna analogia

To dokładnie ten sposób psucia się, przed którym całymi dniami stawiam bramki. Przyszedł tylko od strony, której nie broniłem.

Agent melduje sukces. Testy przechodzą. Diff wygląda czysto. Wszystko na powierzchni mówi, że robota zrobiona, a jedyny sposób, żeby się przekonać inaczej, to sprawdzić coś, nad czym meldujący nie ma władzy: uruchomić prawdziwą aplikację, odpytać prawdziwy stan, porównać z czymś, czego optymalizujący nie dosięgnie.

Wobec agentów miałem ten odruch. Wobec własnego pipeline'u wdrożeniowego już nie, a on przez dwadzieścia jeden dni po cichu serwował nieświeżą treść.

Naprawa, nawiasem mówiąc, polegała na usuwaniu, nie na dokładaniu. Strona to czysty HTML, a mimo to każde wdrożenie przepuszczało ją przez silnik szablonów, którego nigdy nie potrzebowała: 165 sekund na opublikowanie pół megabajta. Jeden pusty plik później wdrożenie jest zwykłym kopiowaniem plików i trwa 19 sekund. Dziewięć dziesiątych czasu szło na krok, którego jedynym realnym wkładem była zdolność do popsucia się.