Zła pętla wysyła zły kod szybciej: ewaluacje to prawdziwa dyscyplina

Oto zdanie, które powinno wisieć nad biurkiem każdego zespołu zajmującego się agentic coding: zła pętla wysyła zły kod szybciej. Napisaliśmy je mimochodem w Projektowaniu pętli agentów, które działają, gdy śpisz, i tylko stało się prawdziwsze. Cała branża optymalizuje pod autonomię — dłuższe przebiegi, więcej równoległych agentów, mniej nadzoru człowieka. Znacznie mniej ludzi optymalizuje to, co naprawdę decyduje, czy autonomia jest atutem czy obciążeniem: weryfikację.

Logika jest bezlitosna. Gdy agent potrafi generować kod tanio, równolegle, całą noc, generowanie przestaje być wąskim gardłem. Jak ujęliśmy to w Orkiestrze agentów kodu: „wąskim gardłem nie jest już generowanie, lecz weryfikacja”. A szybki generator podłączony do słabego weryfikatora nie jest maszyną do produktywności — jest maszyną do produkowania wiarygodnie wyglądających błędów w tempie, którego żaden człowiek nie zrecenzuje. Im szybsza pętla, tym ważniejsza bramka. Ten post jest o bramce.

Bramka weryfikacji i dlaczego musi być pierwsza

Każda pętla agentowa ma moment, w którym uznaje „ta praca jest gotowa”. Ta decyzja to bramka weryfikacji i można ją zbudować z wielu materiałów: testów, linterów, sprawdzania typów, skanów bezpieczeństwa, złotego zbioru danych albo niezależnego modelu-recenzenta. Jakość tej bramki jest, dosłownie, jakością wszystkiego, co pętla wysyła.

Najczęstszym — i najdroższym — błędem jest puszczenie pętli, zanim bramka stanie się godna zaufania. To wygląda jak postęp: agent jest zajęty, diffy lądują, backlog topnieje. Ale jeśli bramka nie potrafi rzetelnie odróżnić poprawnego od błędnego, cała ta prędkość jest wycelowana w losowym kierunku. Nie wysyłasz szybciej — gromadzisz błędną pracę szybciej i odkrywasz to później, gdy jej odkręcenie jest droższe. Zbuduj bramkę zanim otworzysz przepustnicę, nie po.

Łączy się to bezpośrednio z dwiema ideami, które argumentowaliśmy gdzie indziej. To ta sama granica maker/checker z tego, jak agenty naprawdę rozumują — oddziel model, który pisze, od tego, który sprawdza — przeskalowana, by rządzić całym potokiem. I to ukryte ryzyko samodoskonalącego się harness: agent optymalizujący się względem złej ewaluacji nie staje się lepszy, lecz pewniej błędny, szybciej. Ewaluacja jest tym, ku czemu steruje wszystko inne. Jeśli wskazuje zły kierunek, więcej mocy tylko szkodzi.

Ewaluacje to nowy zestaw testów

Przez dekady artefaktem, który kodował „czy to jest poprawne?”, był zestaw testów. W erze agentów tym artefaktem jest ewaluacja — a rok 2026 uczynił projektowanie ewaluacji odrębną dyscypliną. Kształt, który wyłania się w poważnych zespołach, wygląda tak:

• Złoty zbiór danych wyciągnięty z realnych awarii. Nie syntetyczne przypadki-zabawki — wyselekcjonowany zestaw zbudowany z faktycznych sposobów, w jakie twój system zawiódł na produkcji. Twoja historia incydentów to najcenniejszy materiał ewaluacyjny.
• Mieszanka skorerów deterministycznych i opartych na osądzie. Tanie, dokładne sprawdzenia (czy się kompiluje, czy testy przechodzą, czy wyjście jest poprawnie sformowane) wyłapują awarie mechaniczne; sędzia oparty na LLM wyłapuje te semantyczne, których żaden regex nie złapie.
• Sędzia skalibrowany względem ludzkich recenzentów. LLM-jako-sędzia jest godny zaufania tylko w takim stopniu, w jakim zgadza się z ludźmi, którym ufasz. Kalibracja nie jest opcjonalna — nieskalibrowany sędzia to po prostu kolejny pewny siebie zgadywacz.
• Bramka CI, która blokuje regresje. Ewaluacja uruchamia się przy każdej zmianie i zatrzymuje te, które pogarszają sprawy. To właśnie zamienia ewaluacje z dashboardu, na który zerkasz, w bramkę, która naprawdę trzyma.

Zespoły, które to zbudują — realny program ewaluacji z taksonomią incydentów, złotymi zbiorami danych, mieszanką skorerów deterministycznych i sędziowskich oraz bramkami regresji w CI — zyskują strukturalną przewagę jakościową. Nie szybsze demo, lecz system, który pozostaje poprawny w miarę skalowania.

Od dashboardu do runtime: agent-jako-sędzia

Dwa zjawiska 2026 idą dalej i oba warto znać. Pierwsze to eval-driven development, gdzie ewaluacje przedprodukcyjne nie żyją tylko w CI — przekształcają się w guardrails czasu wykonania. Wyniki ewaluacji zaczynają kontrolować, co agentowi wolno robić: które narzędzia może wywołać, kiedy musi eskalować do człowieka, czy akcja w ogóle wychodzi. Ewaluacja przestaje być świadectwem szkolnym i staje się aktywną kontrolą w pętli decyzyjnej — warstwą guardrail zasilaną pomiarem na żywo.

Drugie to agent-jako-sędzia. Zamiast oceniać tylko końcowe wyjście, autonomiczny agent-sędzia obserwuje kroki pośrednie — czyta log akcji, używa narzędzi i rozumuje o trajektorii, podczas gdy agent-wykonawca działa. Potrafi wskazać, który wymóg został pominięty i który krok poszedł źle, a nie tylko że końcowy wynik zawiódł. Gdy agenty podejmują dłuższe, wielokrokowe zadania, ocenianie podróży, a nie tylko celu, to sposób, by złapać błąd na kroku 3 zamiast płacić za niego na kroku 30. Wzorzec łączy tanie, destylowane ewaluatory działające ciągle z cięższym agentem-sędzią wywoływanym selektywnie do głębokiej weryfikacji — szybko i dokładnie, bez płacenia za dokładność przy każdym wywołaniu.

Dlaczego to praca o najwyższej dźwigni w regionie

Łatwo odczytać „ewaluacje” jako nieefektowną hydraulikę. To dokładnie odwrotnie — to najbardziej bronna, najbardziej posiadalna inżynieria dostępna teraz, i jest ukształtowana pod silne strony Azji Południowo-Wschodniej.

Oto dlaczego. Ewaluacja koduje to, co poprawność oznacza dla twojego problemu — a to jest nieredukowalnie lokalne. Frontierowe laboratorium może wręczyć ci genialny model i generyczny harness testowy. Nie powie ci, czy faktura w języku khmerskim została poprawnie sparsowana, czy kambodżańska reguła zgodności została faktycznie spełniona, ani co „gotowe” oznacza dla zapisów spółdzielni rolniczej. Ten osąd żyje w złotym zbiorze twoich realnych awarii i w sędzim skalibrowanym względem twoich ekspertów domenowych. Jest zbudowany z lokalnej wiedzy i nie da się go zaimportować. To ta sama teza, co spec-driven development widziana z drugiej strony: spec mówi, co zbudować, ewaluacja dowodzi, że zbudowano to poprawnie, a oba to praca pisania-i-osądu, nie wydatek na GPU.

A dźwignia się kumuluje. Zespół, który posiada godną zaufania ewaluację, może bezpiecznie podkręcić autonomię — uruchomić więcej agentów, dłużej, z mniejszym nadzorem — bo bramka łapie to, co się prześlizgnie. Zespół bez niej nie może, choćby jego modele były najlepsze. Ewaluacja jest tym, co pozwala małemu, lekkiemu kapitałowo zespołowi w Phnom Penh czy Da Nang skalować wynik bez skalowania ryzyka. To przepustka do wszystkiego innego w stosie agentowym.

Co z tego wynieść

Zbuduj bramkę, zanim otworzysz przepustnicę. Zacznij złoty zbiór danych ze swoich realnych incydentów już dziś, choćby mały. Połącz tanie sprawdzenia deterministyczne z sędzią i skalibruj sędziego względem ludzi, którym ufasz. Wstaw ewaluację do CI jako bramkę blokującą regresje, a potem awansuj ją do guardrail czasu wykonania. I traktuj ewaluację jako pierwszorzędny, posiadany artefakt — bo koduje jedną rzecz, której frontierowe laboratorium nigdy ci nie dostarczy: co poprawność oznacza tutaj.

Wyścig, który wszyscy widzą, to wyścig o to, by agenty działały. Wyścig, który naprawdę wyłania zwycięzców, jest cichszy: o to, by działały poprawnie, dowodliwie, na skalę. Zła pętla wysyła zły kod szybciej. Dobra ewaluacja to sposób, by upewnić się, że pętla jest dobra.