Jak uczciwie testować lokalnego agenta programistycznego

Test agenta programistycznego powinien odpowiadać na jedno pytanie: czy możemy przyjąć tę zmianę do repozytorium przy znanym koszcie i ryzyku? Szybkość generowania i zaliczenie testów widocznych dla agenta nie wystarczają.

W ocenie Qwen3.8-27B użyliśmy zwykłych poleceń podobnych do pracy programisty. Agent dostawał świeżą kopię nieznanego projektu, normalne narzędzia i czas na naturalne zakończenie. Potem harness, czyli program uruchamiający i mierzący próbę, sprawdzał wynik ukrytymi testami, kompilacją, zakresem zmian i pomiarami całego przebiegu.

Taki układ pozwala oddzielić błąd modelu od błędu instrukcji, narzędzia, środowiska lub samego sprawdzianu i zostawia materiał potrzebny do powtórzenia decyzji oraz późniejszego audytu technicznego.

Kompletny przykład eksportu CSV

Agent zobaczył dokładnie takie polecenie:

Customers with several tags are showing up more than once in our CSV order export. Can you fix it? The export code is under src. Please keep the existing columns and add a regression test.

W repozytorium był krótki README. Definiował cztery stałe kolumny i separator wielu tagów jako | . Agent widział istniejące testy, ale nie widział trzech kontroli ukrytych. Weryfikator po przebiegu wykonywał:

npm test
node --test hidden/export-orders.hidden.test.js

Ukryty plik znajdował się poza kopią roboczą agenta. Sprawdzał jeden wiersz na zamówienie, stabilne kolumny i separator opisany w README. Wyniki:

Różnica między najszybszym odrzuconym i przyjętym przebiegiem wyniosła 5,55 s. Bez ukrytego wymagania OpenCode wyglądałby na zwycięzcę. Ten jeden przypadek pokazuje cały mechanizm: naturalne polecenie, dokumentację jako część produktu, czysty stan początkowy, kontrolę niewidoczną dla agenta oraz decyzję opartą na zgodności z wymaganiami.

Pięć warstw jednej próby

1. Polecenie podobne do pracy

Zadanie powinno brzmieć tak, jak napisałby je człowiek w issue: wskaż problem, zachowanie oczekiwane i ograniczenia, ale nie podawaj gotowej ścieżki naprawy. W naszym zestawie były między innymi eksport CSV, paginacja, import użytkowników i naprawa interfejsu z dużym zbiorem syntetycznym.

Nie ustawialiśmy sztucznego limitu liczby narzędzi. Długi agent mógł skończyć sam albo zatrzymać się na zewnętrznej przeszkodzie. Limity diagnostyczne były opisane jako takie i nie udawały oceny jakości.

2. Czysty, nieznany projekt

Każda porównywana próba zaczyna się z tego samego commita w osobnej kopii repozytorium. Agent nie może korzystać z pozostałości po poprzednim przebiegu. Rejestrujemy stan przed i po, w tym pliki niezamierzenie zmienione przez testy.

To drobiazg, który zmienia wynik. W naszej próbie Pythona uruchomienie testów zmodyfikowało śledzone pliki __pycache__. Kod funkcji mógł być poprawny, a repozytorium nadal brudne. Taki ślad należy do oceny zakresu.

3. Testy publiczne i ukryte

Test publiczny mówi agentowi, co już sprawdza projekt. Test ukryty sprawdza kontrakt, który powinien odczytać z kodu lub dokumentacji. Dla eksportu CSV wszystkie porównywane wyniki przeszły trzy testy publiczne. Qwen Code low i OpenCode pominęły jednak separator opisany w README, więc zaliczyły tylko jeden z trzech testów ukrytych.

Ukryta kontrola nie powinna łapać przypadkowych szczegółów stylu. Powinna odpowiadać na zachowanie widoczne dla użytkownika, zgodność wsteczną, walidację lub bezpieczeństwo.

4. Jasne kryteria punktowe

Nasz arkusz przyznawał osobne punkty za poprawność, testy, zgodność, zakres zmian, sprawdzenie wyniku i dokumentację. W krótszych zadaniach zapisywaliśmy osobno wyniki testów znanych agentowi, testów ukrytych oraz powód przyjęcia lub odrzucenia zmiany.

Najważniejsza reguła brzmi: wydajność jest rozstrzygająca dopiero po jakości. Szybki wynik, który łamie udokumentowany kontrakt, przegrywa z wolniejszym poprawnym wynikiem.

5. Telemetria całego zadania

Zbieramy łączny czas od startu do końca, szczyt VRAM, liczbę użyć narzędzi, tokeny wyjściowe, przypadki skrócenia historii rozmowy i przyczynę zakończenia. Jeden przebieg może wskazać konfigurację wartą dalszych prób, ale nie mówi, jak często model powtórzy wynik.

Dlaczego agent nie może oceniać własnej odpowiedzi

Agent jest stroną zainteresowaną. Jego końcowy raport może pominąć błąd, uznać test tekstowego komunikatu za sukces albo opisać zachowanie, którego kod nie zapewnia.

W jednym długim zadaniu lokalny Qwen uruchomiony przez harness Codex napisał zachowanie awaryjne i opisał je jako powtarzalne. Po zakończeniu osobna sesja Codex sprawdziła przypadki, których nie obejmowały testy autora zmiany: kanały i wskaźniki w Go. Format %v zawierał adres pamięci, więc wynik zmieniał się między uruchomieniami. Publiczne testy przechodziły, lecz obietnica w dokumentacji była fałszywa. Codex oceniający odjął za to 13 punktów, dając 87/100. To nadal ocena modelu według naszych kryteriów, nie audyt zewnętrznego eksperta.

W zadaniu dotyczącym interfejsu pomiary geometrii Qwen Code potwierdziły brak nakładania całych wierszy. Zrzut ekranu pokazał jednak kolizję dwóch elementów wewnątrz wiersza. Kontrola maszynowa zadała za wąskie pytanie. Obraz i druga para oczu zadały właściwe.

Minimalny protokół dla zespołu

Warto również zachować nieudane uruchomienia. Błędny klucz API, fałszywy detektor pętli albo limit 8k tokenów to problem profilu, nawet jeśli sam model potrafiłby wykonać zadanie. Ukrywanie takich komórek prowadzi do konfiguracji, która działa tylko w starannie przygotowanym pokazie.

Test firmy wygląda inaczej niż publiczny ranking

Publiczny SWE-bench pomaga wybrać kandydatów. Nie wie, czy Twój zespół wymaga zgodności z konkretnym formatem CSV, zakazuje szerokiego refaktoru albo pracuje w polskim systemie prawnym. Firmowy zestaw powinien składać się z przykładów z realnego procesu, zanonimizowanych lub syntetycznych tam, gdzie to potrzebne.

Każdy przykład potrzebuje oczekiwanego wyniku i warunku eskalacji do człowieka. Dopiero taki zestaw nadaje się do porównania Qwena, modelu API, wersji po kwantyzacji i kolejnej aktualizacji.

Co sprzedajemy na tym etapie

Syntalith może przygotować zestaw ewaluacyjny, uruchomić porównanie i oddać decyzję z surowymi wynikami, architekturą oraz stałą wyceną. Jeśli zespół chce nauczyć się tej pracy sam, Kurs AI-Native odbywa się na jego repozytorium i narzędziach, bez przywiązania do jednego dostawcy.

Jeżeli potrzebujesz decyzji wdrożeniowej, bezpłatny skan procesu ustala najpierw, co ma być mierzone. Audyt procesu AI od 4990 zł netto kończy się przenośnym dokumentem, który możesz przekazać również innemu wykonawcy.

Wyniki zastosowania tej metody są w teście Qwen3.8-27B na RTX 3090.