Jak uczciwie testować lokalnego agenta programistycznego

Test porównawczy to powtarzalny sprawdzian, w którym agent dostaje zadanie, a zespół porównuje wynik z ustalonymi kryteriami i kosztem. Test agenta programistycznego powinien odpowiadać na jedno pytanie: czy możemy przyjąć tę zmianę do repozytorium przy znanym koszcie i ryzyku? Szybkość generowania oraz zaliczenie testów widocznych dla agenta nie wystarczają.

W ocenie Qwen3.8-27B użyliśmy poleceń napisanych jak zwykłe zgłoszenia programistyczne. Agent dostawał świeżą kopię nieznanego projektu, zwykłe narzędzia i czas na dokończenie pracy albo zgłoszenie rzeczywistej przeszkody. Harness, czyli program uruchamiający próbę i zbierający jej pomiary, sprawdzał potem ukryte zachowania, kompilację, zakres zmian oraz cały przebieg.

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. low i medium oznaczają poziom wysiłku ustawiony w Qwen Code; nie są ocenami jakości. Ułamek pokazuje liczbę zaliczonych kontroli spośród wszystkich kontroli, a czas oznacza łączny czas od uruchomienia do końca przebiegu. Wyniki:

Różnica między najszybszym odrzuconym a przyjętym przebiegiem wyniosła 5,55 s. Bez ukrytego wymagania OpenCode wyglądałby na zwycięzcę. Ten przypadek pokazuje cały mechanizm: polecenie napisane jak zwykłe zgłoszenie, 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 napisane jak zgłoszenie

Polecenie powinno brzmieć tak, jak zgłoszenie napisane przez człowieka: opisywać problem, oczekiwane zachowanie i ograniczenia bez podawania 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 przebieg mógł zakończyć się wykonaniem pracy albo zatrzymaniem na zewnętrznej przeszkodzie. Ograniczenia używane wyłącznie do diagnozy opisywaliśmy wprost i nie wliczaliśmy ich do 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. Pojedynczy przebieg może wskazać konfigurację wartą dalszych prób; o częstotliwości powtarzania wyniku mówią dopiero kolejne uruchomienia.

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 ocenił zapisany wynik według kryteriów Syntalith na 87/100, ponieważ za ten błąd odjęto 13 punktów. Skala obejmuje poprawność (40 pkt), testy regresji (20), zgodność (15), zakres zmian (10), weryfikację (10) i dokumentację (5). Ocena pochodzi od Codex, bez udziału zewnętrznego audytora.

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 konfiguracji, nawet jeśli sam model potrafiłby wykonać zadanie. Pomijanie takich nieudanych prób prowadzi do konfiguracji działającej wyłącznie 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 szerokiej przebudowy kodu 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 Syntalith dostarcza na tym etapie

Syntalith przygotowuje listę zadań z kryteriami akceptacji, uruchamia porównanie na czystych kopiach repozytorium i przekazuje tabelę wyników: czasy, testy publiczne i ukryte, zmienione pliki, logi narzędzi oraz przyczyny odrzuceń. Dołączamy rekomendację konfiguracji i stałą wycenę wdrożenia. 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, które zadania i ryzyka trzeba zmierzyć. Audyt procesu AI od 4990 zł netto kończy się dokumentem z zadaniami, wynikami, konfiguracją i zaleceniami, który możesz przekazać również innemu wykonawcy.

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