Better Harness od Qoder: audyt procesu pracy agentów programistycznych, nie tylko kodu

Nie ocenia tylko odpowiedzi modelu — sprawdza cały proces

Better Harness to projekt open source od Qoder, służący do przeglądu i poprawiania workflow wokół agenta programistycznego. Zamiast oceniać pojedynczą odpowiedź modelu albo jeden diff, analizuje instrukcje projektu, mechanizmy kontroli, ścieżki walidacji, konfigurację agenta oraz — tam, gdzie jest to obsługiwane — zapisy rzeczywistych sesji pracy. Celem jest wykrycie luk w procesie, zaproponowanie ograniczonej naprawy i umożliwienie jej sprawdzenia przy kolejnym uruchomieniu. 124

Według doniesień Qoder ogłosił udostępnienie projektu na GitHubie jako open source 28 lipca 2026 r. 5

W dokumentacji Qoder określa otoczenie, w którym działa agent, mianem harness. Może ono obejmować instrukcje w repozytorium, reguły, umiejętności (skills), hooki, wtyczki, konektory, skrypty, polecenia testowe, kontrole przed wydaniem oraz kroki wymagające przeglądu przez człowieka. 2

To istotne rozróżnienie. Nawet dobry model może pracować nierzetelnie, jeśli proces jest niejasny albo słabo obserwowalny. W repozytorium może istnieć zestaw testów, ale agent nie musi wiedzieć, kiedy go uruchomić. Plik z regułami może być obecny, lecz niewykorzystywany. Z kolei wnioski z nieudanego zadania mogą zniknąć wraz z zakończeniem sesji. Better Harness ma ujawniać właśnie takie słabości operacyjne — nie traktować samego istnienia pliku konfiguracyjnego jako dowodu, że proces działa. 145

Trzy warstwy Better Harness

Qoder przedstawia Better Harness jako trzywarstwowy framework łączący praktyki inżynierskie, model oceny i działającą implementację. 5

1. Praktyki Harness Engineering

Pierwsza warstwa obejmuje mechanizmy, które kształtują pracę agenta: wzorce sesji i CLI, obserwowalność, reguły, umiejętności, konfigurację MCP, pamięć, hooki oraz automatyzację. 5

W praktyce chodzi o podstawowe pytania:

• Czy agent otrzymuje jasny cel, ograniczenia i kontekst repozytorium?
• Czy jego uprawnienia i ścieżki wykonywania poleceń są odpowiednio kontrolowane?
• Czy testy, kontrole i przeglądy kodu są połączone z wykonywaną pracą?
• Czy przydatne wnioski z realizacji zadań trafiają do utrzymywanych zasobów projektu, zamiast zniknąć po sesji?

Analiza zaczyna się od mapy obecnego środowiska: celów, kontekstu, punktów wejścia do wykonywania zadań, pętli informacji zwrotnej, mechanizmów dostarczania zmian i sposobu utrwalania wiedzy. 1

2. Ocena Agent Work Loop

Druga warstwa przekłada te praktyki na ocenę pięciu powiązanych wymiarów dostarczania zmian: rozumienia zadania, kontrolowanego wykonywania, walidacji zmiany, niezawodnego dostarczenia oraz przechwytywania wiedzy z wykonanej pracy. 14

Zmienia to punkt ciężkości pytania. Zamiast: „czy agent wygenerował wiarygodnie wyglądający kod?”, Better Harness pyta: czy cały proces potrafi wielokrotnie prowadzić do zmian, które są zrozumiałe, kontrolowane, zweryfikowane, możliwe do dostarczenia i oparte na wcześniejszych doświadczeniach?

Model ma wskazywać miejsca zerwania tej pętli: brakujący mechanizm, niepołączoną integrację, krok, który w rzeczywistości nie został wykonany, albo zbyt słaby materiał dowodowy potwierdzający rezultat. 1

3. Uruchamialna implementacja

Trzecia warstwa ma sprawić, że praktyki i model oceny nie pozostaną wyłącznie dokumentacją. Better Harness działa przez agenta programistycznego, zbiera dane z projektu i — jeśli środowisko to wspiera — z sesji, a następnie tworzy priorytetową listę działań możliwych do zweryfikowania. 4

Aktualne materiały projektu mówią o obsłudze dziesięciu adapterów hostów. W doniesieniach z czasu premiery wymieniono m.in. Claude Code, Codex, Qoder i Cursor. 56

Zakres adapterów może się zmieniać, dlatego integrację z konkretnym środowiskiem należy każdorazowo sprawdzić w bieżącej dokumentacji projektu. Dostarczone źródła nie potwierdzają w szczególności obsługi OpenClaw.

Trzy rodzaje dowodów: projekt, konfiguracja i rzeczywista sesja

Istotnym elementem podejścia jest oddzielenie zbierania danych od końcowej oceny. Qoder podaje, że główny proces analizy gromadzi surowe dane, a następnie przekazuje je trzem niezależnym podagentom działającym w trybie tylko do odczytu. 1

Są to trzy perspektywy:

• Project Harness — inżynierskie podstawy repozytorium, takie jak instrukcje, skrypty, kontrole i mechanizmy dostarczania zmian;
• Agent Customization — reguły, umiejętności, hooki i pozostała konfiguracja właściwa dla agenta;
• Session Evidence — zapis tego, co agent faktycznie zrobił podczas pracy nad zadaniem, jeśli taki materiał jest dostępny.

Taka konstrukcja pozwala odróżnić proces zamierzony od procesu zaobserwowanego. Dowody z projektu i konfiguracji mogą wskazywać, że dana możliwość istnieje. Dane z sesji mogą natomiast pokazać, czy została użyta właściwie w rzeczywistym zadaniu. 14

Test istnieje? To jeszcze nie znaczy, że zadziałał

Najważniejsza zasada frameworku brzmi: istnienie artefaktu nie jest dowodem jego skuteczności.

Przykład: repozytorium może zawierać automatyczny zestaw testów. Jego obecność oznacza potencjalną możliwość walidacji, ale nie potwierdza, że agent uruchomił właściwe testy po zmianie kodu, poprawnie zinterpretował wynik albo wykorzystał go, by zapobiec błędnemu wdrożeniu. To samo dotyczy reguł, hooków, umiejętności i bramek akceptacyjnych. 15

Raport Better Harness ma więc utrzymywać widoczny łańcuch dowodowy. Potwierdzone luki są zamieniane w uporządkowane według priorytetu ustalenia (findings), zawierające wpływ problemu, oczekiwany rezultat, zakres naprawy i kryteria akceptacji. Brakujące dane nie powinny zostać po cichu zamienione w pewną ocenę. 46

Dla zespołu oznacza to możliwość sprawdzenia czterech rzeczy:

1. Co zaobserwowano w projekcie, konfiguracji lub zapisie sesji.
2. Dlaczego ma to znaczenie dla procesu dostarczania zmiany.
3. Jaką konkretną, wąsko określoną naprawę proponuje narzędzie — np. regułę, umiejętność, hook, skrypt, automatyzację albo etap zatwierdzany przez człowieka.
4. Jak zweryfikować efekt po wdrożeniu poprawki.

Cykl poprawy: sprawdź, napraw, zmierz ponownie

Better Harness nie jest przedstawiany jako jednorazowy audyt. Jego proces jest iteracyjny:

1. Zmapowanie aktualnego środowiska pracy agenta.
2. Wskazanie przerw w workflow i luk dowodowych.
3. Utworzenie ograniczonego zadania naprawczego dla potwierdzonego problemu.
4. Walidacja poprawki według zdefiniowanych kryteriów akceptacji.
5. Ponowne uruchomienie przeglądu i ocena nowych dowodów. 14

To podstawa deklaracji o ciągłym doskonaleniu. Narzędzie może pokazać, że workflow się zmienił i czy nowe dane uzasadniają lepszą ocenę. Nie dowodzi jednak samo w sobie, że dana poprawka spowodowała lepszą wydajność agenta w każdym projekcie lub środowisku. Materiały Qoder akcentują obserwowane dowody i jawne ograniczenia, zamiast przedstawiać zmianę wyniku jako dowód związku przyczynowego. 46

Jak rozumieć analizę 30 projektów GitHub

Według informacji z okresu premiery framework wykorzystano w początkowym ćwiczeniu obejmującym 30 rzeczywistych projektów na GitHubie. 5 Należy traktować to jako eksploracyjne zastosowanie metody, a nie kontrolowany dowód, że Better Harness poprawia wyniki każdego agenta programistycznego i każdego repozytorium.

Dostępna dokumentacja źródłowa opisuje model dowodowy, strukturę ustaleń oraz iteracyjny proces napraw. Nie zawiera jednak wystarczających szczegółów, by niezależnie ocenić dobór próby 30 projektów, protokół oceniania lub zbiorcze wyniki. To ważne zastrzeżenie przy porównywaniu Better Harness z formalnymi benchmarkami albo przy formułowaniu szerokich twierdzeń o wzroście jakości. 14

Próba uczynienia pracy agentów bardziej mierzalną

Szersza teza Qoder jest taka, że Harness Engineering może stać się infrastrukturą jakości dla wspomaganego przez AI tworzenia oprogramowania: wspólnym językiem opisu kontroli workflow, obserwowalnych dowodów, porównywalnych wymiarów dostarczania zmian i powtarzalnych cykli usprawniania. 12

Better Harness proponuje praktyczne wcielenie tej idei. Ma pomagać zespołom analizować warunki pracy agentów w obsługiwanych środowiskach, rozmawiać o dowodach zamiast o samych wrażeniach oraz sprawdzać, czy proponowana korekta procesu utrzymuje się przy kolejnych uruchomieniach. Jego wartością nie jest gwarancja, że każda naprawa poprawi wynik, lecz bardziej rygorystyczny sposób na uczynienie workflow agentów sprawdzalnym, poddawalnym przeglądowi i możliwym do obalenia na podstawie danych. 46