Ranking Niklaus Harness testuje Kimi Code, Hermes, Pi, Claude Code i Codex poza rankingami marek

Joël Niklaus porównał dziewięć harnessów agentów programistycznych w 28 849 próbach, podważając przekonanie, że wybór modelu rozstrzyga kwestię wydajności. Ranking harnessów Niklaus ocenia oprogramowanie kierujące pracą modelu przy kontrolowaniu bazowego modelu i ustawień rozumowania. Początkowe wyniki umieszczają kilka rozpoznawalnych narzędzi w podobnym zakresie trafności, a różnice w efektywności i powtarzalności komplikują wskazanie zwycięzcy.

Porównanie obejmuje Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code i OpenClaw. Harness to oprogramowanie zarządzające instrukcjami, narzędziami i pętlą wykonywania modelu AI. W tym przypadku właśnie to otaczające oprogramowanie staje się badaną zmienną.

Główne napięcie dotyczy reputacji produktu i zachowania konkretnej testowanej konfiguracji. Wyniki te nie dowodzą, że Claude Code lub Codex działa uniwersalnie lepiej ze swoim domyślnym modelem. Badają, co dzieje się, gdy różne harnessy uruchamiają wybrane otwarte modele w kontrolowanych warunkach — to węższe pytanie, ale mające praktyczne konsekwencje dla deweloperów.

Co faktycznie porównuje ranking Niklaus Harness

Eksperyment izoluje otaczające oprogramowanie agenta, zamiast traktować każdy produkt do programowania jako nierozłączny pakiet.

W opisie wydania Niklaus podaje, że porównanie utrzymuje stałe model, dostawcę i poziom wysiłku rozumowania, zmieniając jedynie harness. Każde zadanie otrzymuje trzy próby. Początkowa ocena obejmuje GLM-5.3-Flash, DeepSeek-V4.1-Flash i Flint, wykorzystując Terminal-Bench 2.1 oraz DeepSWE.

Ten projekt ma znaczenie, ponieważ zwykłe porównania produktów często zmieniają jednocześnie kilka zmiennych. Deweloper przechodzący na innego asystenta programistycznego może równocześnie zmienić model, instrukcje, dostępne narzędzia, uprawnienia i sposób wykonywania. Różnicę w wydajności trudno wtedy przypisać konkretnej przyczynie.

Opis wydania podaje, że mini-swe-agent osiągnął średni wskaźnik rozwiązania zadań na poziomie 51,4% dla trzech modeli, wobec 27,3% dla OpenClaw. Niklaus dodaje również, że cztery inne harnessy są statystycznie zrównane z najlepszym wynikiem. Dane te opisują początkowe wydanie, a nie trwały ranking.

Jego ustalenia dotyczące konkretnych modeli komplikują tę średnią ogólną. Według Niklausa mini-swe-agent prowadzi dla GLM-5.3-Flash, Hermes Agent dla DeepSeek-V4.1-Flash, a Kimi Code dla Flint. Kolejność zależy więc od tego, który model deweloper zamierza uruchomić.

Bezpośredni wniosek jest ograniczony, ale istotny. Harness dobrze działający z jednym modelem nie musi automatycznie uzyskiwać tej samej względnej wydajności z innym. Wynik ogólny może pomóc wskazać kandydatów, jednocześnie ukrywając zestawienie istotne dla rzeczywistego wdrożenia.

Terminal-Bench ocenia agentów wykonujących zadania w środowiskach terminalowych, gdzie oprogramowanie uruchamia polecenia i wchodzi w interakcje z plikami. DeepSWE dostarcza oddzielną ocenę inżynierii oprogramowania. Wykorzystanie obu rozszerza porównanie, choć łączenie wyników nie czyni zbiorów zadań reprezentatywnymi dla każdego procesu programistycznego.

Do wniosków z eksperymentu należy również przypisać datę. Podczas sprawdzania na potrzeby tego artykułu aplikacja na żywo wyświetlała wersję v0.1.2. Jej obecny opis odnosi się do sprawdzania równoważnych dostawców, zamiast po prostu powtarzać sformułowanie z początkowego wydania o stałym dostawcy.

To rozróżnienie zasługuje na uwagę, ponieważ benchmark może ewoluować po pierwszym ogłoszeniu. Nowe wersje harnessów, dodatkowe próby lub zmienione mechanizmy kontroli mogą zmienić znaczenie zrzutu ekranu. Dane z premiery pozostają dowodem dotyczącym konfiguracji premierowej, nawet jeśli obecna tablica prezentuje inną kolejność.

Dla czytelników trafiających na pierwotną dyskusję na Reddicie kluczowa korekta dotyczy więc zakresu. Jest to porównanie wybranych kombinacji harnessów i modeli. Nie jest to kompleksowy test każdej funkcji, doświadczenia subskrypcyjnego ani domyślnej konfiguracji związanej z wymienionymi nazwami produktów.

Dostawcy agentów programistycznych odczuwają presję, by wyjaśniać całą konfigurację

Wyniki wywierają presję na twierdzenia przypisujące wydajność agenta wyłącznie jego bazowemu modelowi.

Dla twórców harnessów porównanie uwidacznia wybory implementacyjne. Instrukcje, interfejsy narzędzi, zachowanie przy ponawianiu prób i decyzje o zakończeniu działania wpływają na pracę wykonywaną przez model. Silny model nadal może napotkać trudności wynikające z oprogramowania odpowiedzialnego za jego kierowanie.

Dla dostawców modeli ten sam eksperyment wprowadza problem atrybucji. Rozczarowujący wynik wewnątrz konkretnego agenta nie wskazuje modelu jako jedynej przyczyny. Odwrotnie, silny wynik nie dowodzi, że każda aplikacja używająca tych wag go odtworzy.

Dla nabywców korporacyjnych zmienia to zakres informacji potrzebnych do przeprowadzenia sensownej oceny. Wskazanie modelu i asystenta nie wystarcza, gdy wybory konfiguracyjne wpływają na wyniki. Kupujący potrzebują wystarczającej ilości informacji, aby zrozumieć testowaną kombinację i odtworzyć zachowanie istotne dla ich pracy.

Hipotetyczne zadanie utrzymaniowe dobrze uwidacznia to rozróżnienie. Agent może potrzebować przeanalizować repozytorium, zidentyfikować nieudany test, zmodyfikować funkcję i zweryfikować zmianę. Każdy etap zależy od tego, jak harness udostępnia informacje i zarządza sekwencją działań.

Jeśli agent zakończy pracę po edycji bez uruchomienia właściwego testu, pozornie wiarygodna poprawka pozostaje niezweryfikowana. Jeśli będzie nadal wydawał bezproduktywne polecenia, ukończenie zadania stanie się wolniejsze i bardziej zasobochłonne. Są to różnice operacyjne, nawet gdy bazowy model pozostaje bez zmian.

Nie dowodzi to, która implementacja spowodowała konkretny wynik w rankingu. Wymaga to analizy zapisów wykonania i przetestowania interwencji. Wyjaśnia jednak, dlaczego kontrolowane porównanie zadaje użyteczne pytanie, na które sam ranking modeli nie potrafi odpowiedzieć.

Wyniki premierowe wyznaczają także granicę znanej debaty Claude Code vs Codex. Te nazwy produktów często oznaczają kompletne doświadczenia zbudowane wokół określonych rodzin modeli. Testowanie ich harnessów z wybranymi otwartymi modelami stawia inne pytanie niż porównywanie tych kompletnych doświadczeń.

Niska pozycja w tym eksperymencie nie dowodziłaby, że domyślna usługa produktu działa słabo. Wysoka pozycja nie dowodziłaby przewagi w przeglądzie kodu, współpracy interaktywnej ani procesach specyficznych dla organizacji. Takie twierdzenia wymagają ocen mierzących te działania bezpośrednio.

Wynik benchmarku Kimi Code podlega temu samemu ograniczeniu. Zgłoszone prowadzenie z Flint uzasadnia dalsze badanie tej pary w testowanych warunkach. Nie dowodzi ogólnego prowadzenia dla niezwiązanych modeli ani repozytoriów.

Dla dostawców konstruktywną odpowiedzią jest publikowanie konfiguracji i wyjaśnianie zmian wpływających na wyniki. Kupujący mogą wtedy odróżnić aktualizację modelu od ulepszenia harnessu. Ułatwia to ocenę twierdzeń o wydajności i badanie niepowodzeń.

Presja jest szczególnie istotna dla zespołów uruchamiających otwarte modele za pomocą wymiennego oprogramowania agentowego. Ich decyzja zakupowa obejmuje warstwę wykonawczą. Potrzebują dowodów na wkład tej warstwy, zamiast opierać się wyłącznie na rozpoznawalnej nazwie produktu.

Podobna trafność może ukrywać odmienne zachowanie operacyjne

Zbliżony wynik trafności pozostawia miejsce na istotne różnice w zużyciu zasobów, opóźnieniach i spójności.

Obecna tablica rozdziela kilka pomiarów, zamiast przedstawiać trafność jako kompletną odpowiedź. Jej metoda oceny opisuje zewnętrzny pomiar wykorzystania modelu i rozróżnia czas przetwarzania modelu od czasu poświęcanego na uruchamianie agenta. Te rozróżnienia pomagają wyjaśnić, dlaczego podobne wskaźniki rozwiązania mogą prowadzić do odmiennych doświadczeń operacyjnych.

Tablica przedstawia także trafność względem kosztu i wskazuje granicę Pareto — zbiór opcji, których żaden konkurent nie przewyższa jednocześnie w obu prezentowanych miarach. Daje to czytelnikom sposób na analizę konkurujących zalet bez zakładania, że najwyższa trafność zawsze musi być preferowana.

To ujęcie ma znaczenie, gdy organizacja ma stałe obciążenie pracą i ograniczone zasoby. Niewielka przewaga w trafności może być cenna w trudnym zadaniu wymagającym minimalnego nadzoru. Ta sama przewaga może być mniej atrakcyjna, jeśli wymaga znacznie więcej czasu wykonania w rutynowych pracach utrzymaniowych.

Wynik dotyczący efektywności również wymaga interpretacji. Niższe wydatki nie muszą oznaczać, że agent rozumuje skuteczniej. Mogą wynikać z mniejszej liczby prób, wcześniejszego zakończenia, krótszych wyników lub innego wzorca użycia narzędzi. Zapis wykonania pomaga odróżnić produktywną powściągliwość od przedwczesnej porażki.

Podobnie dłuższe wykonanie nie dowodzi marnotrawstwa. Agent może poświęcać dodatkowy wysiłek na sprawdzenie poprawki lub odzyskanie kontroli po nieudanym podejściu. Istotne pytanie brzmi, czy dodatkowa praca poprawia wynik, który zespół rzeczywiście ceni.

Dlatego raportowanie zużycia zasobów na próbę i na udany wynik odpowiada na różne pytania. Tania nieudana próba nadal pozostaje porażką. Bardziej wymagająca udana próba może wciąż być lepszym wyborem, gdy ręczne odzyskiwanie kontroli w przeciwnym razie zdominowałoby proces pracy.

Są to kwestie oceny, a nie wyjaśnienia ustalone dla każdego harnessu na tablicy. Wykres może ujawnić wzorzec wart zbadania. Sam w sobie nie potrafi wskazać instrukcji ani zachowania narzędzia odpowiedzialnego za ten wzorzec.

Mechanizm jest w zasadzie prosty. Agent otrzymuje informacje, wybiera działanie, obserwuje rezultat i decyduje, co zrobić dalej. Harness kontroluje istotne części tej pętli, w tym dostępne narzędzia oraz sposób, w jaki ich odpowiedzi docierają do modelu.

Rozważmy hipotetyczne repozytorium z nieudanym buildem spowodowanym problemem środowiskowym. Agent, który wielokrotnie edytuje kod aplikacji, może zużywać zasoby bez usunięcia przyczyny. Inna konfiguracja może rozpoznać problem środowiskowy i przekierować swoje dochodzenie.

Różnica dotyczyłaby wykonania zadania, a nie surowej wiedzy modelu. Ustalenie tego wyjaśnienia wymagałoby powiązania zaobserwowanego zachowania z wynikiem. Bez takiej analizy stwierdzenie, że konkretny harness jest „inteligentniejszy”, wykracza poza dowody.

Ranking harnessów Niklaus wspiera zatem bardziej szczegółowe porównanie, niż sugeruje etykieta jednego zwycięzcy. Deweloperzy mogą pytać, które kombinacje osiągają akceptowalną trafność, wykorzystując jednocześnie zasoby w sposób, który może obsłużyć ich obciążenie pracą. Odpowiedź może różnić się między interaktywnym programowaniem a działaniem bez nadzoru.

Zmienia to również sposób odczytywania nagłówka o benchmarku Kimi Code. Prowadzenie dla konkretnego modelu jest użytecznym sygnałem do dalszej oceny. Pozostaje niepełne bez informacji o nieudanych próbach, czasie wykonania i zachowaniu, które wytworzyło wynik.

Z tego samego powodu porównania Claude Code vs Codex powinny zachowywać testowany kontekst. Nazwy zapewniają orientację, ale to konfiguracja określa, co wynik faktycznie opisuje.

Powtarzalny sukces to inny wynik niż sporadyczny sukces

Agent, który rozwiązuje zadanie tylko sporadycznie, stanowi inną propozycję wdrożeniową niż taki, który rozwiązuje je konsekwentnie.

Niklaus zwrócił następnie uwagę na niezawodność w powtarzanych próbach. Według jego analizy niezawodności mini-swe-agent rozwiązywał średnio 51,4% zadań w pojedynczej próbie. Co najmniej raz w trzech próbach rozwiązał 68,6% zadań, ale we wszystkich próbach — 33,0%.

Te pomiary opisują różne pytania operacyjne. Średnia odzwierciedla wyniki we wszystkich próbach. Sukces co najmniej raz pokazuje, czy powtarzane okazje ostatecznie prowadzą do rozwiązania. Sukces za każdym razem mierzy konsekwencję w ramach badanych prób.

To rozróżnienie staje się istotne, gdy ktoś obserwuje pracę agenta. Programista może przeanalizować nieudaną próbę, zmienić instrukcję albo zdecydować, że warto uruchomić kolejną. Nadzór człowieka może uczynić sporadyczny sukces użytecznym, choć czas poświęcony na nadzór nadal pozostaje częścią procesu.

Nienadzorowany proces podlega innemu ograniczeniu. Nie może zakładać, że istnieje udana alternatywna próba, chyba że otaczający go system rzeczywiście uruchamia alternatywy i potrafi ocenić ich jakość. Powtarzane próby wymagają metody wyboru, budżetu wykonania oraz sposobu obsługi nierozwiązanych niepowodzeń.

To sprawia, że wynik okazjonalnych sukcesów jest słabym substytutem miary konsekwencji. Może pokazać, że dana konfiguracja ma dostęp do rozwiązania w pewnych warunkach. Nie dowodzi jednak, że konfiguracja dostarczy to rozwiązanie niezawodnie na żądanie.

Niklaus podaje, że pięć harnessów rozwiązało w cytowanym porównaniu od 32,0% do 33,3% zadań w każdej próbie. Opisuje te wyniki jako zbyt zbliżone, by rozstrzygnąć. To przemawia za powściągliwością wobec precyzyjnych twierdzeń o zwycięzcy w czołowej grupie.

Do danych o niezawodności należy także dołączyć ich ograniczenia. Trzy próby dostarczają dowodów na powtarzalność w ramach tego eksperymentu. Nie ustalają wskaźnika awarii produkcyjnych w zmiennych repozytoriach, zależnościach, uprawnieniach i instrukcjach użytkowników.

Również porażka w benchmarku nie przekłada się automatycznie na szkodliwe działanie produkcyjne. Ewaluator mierzy, czy zadanie spełnia kryteria sukcesu. Konsekwencje operacyjne zależą od tego, do czego agent ma dostęp oraz jakie zatwierdzanie lub weryfikacja otacza jego pracę.

Dla menedżerów inżynierii wniosek jest taki, by oddzielać zdolność od niezawodnego dostarczania rezultatów. Konfiguracja może czasem być wystarczająco zdolna, aby stworzyć poprawny patch, a jednocześnie pozostawać nieodpowiednia dla nienadzorowanego procesu. Ta luka wymaga dodatkowej weryfikacji, a nie silniejszej etykiety marketingowej.

Hipotetyczna aktualizacja zależności dobrze obrazuje tę różnicę. Agent może w jednym uruchomieniu pomyślnie zaktualizować pakiet i przejść testy, a w kolejnym pominąć powiązaną zmianę konfiguracji. Sporadyczny sukces mówi o gotowości do pracy bez nadzoru mniej, niż mogłaby sugerować wartość procentowa w nagłówku.

Zespół oceniający taki proces zwracałby uwagę na odtwarzalne ukończenie zadania i jasną obsługę błędów. Istotne byłoby także, czy wynikowa zmiana jest zrozumiała dla recenzenta. Te wymiary pozostają odrębne od tego, czy weryfikator benchmarku zaakceptuje stan końcowy.

Perspektywa powtarzanych prób na leaderboardzie uwidacznia to rozróżnienie w publicznym porównaniu. Zachęca czytelników, by pytali, co dzieje się, gdy agent musi pracować ponownie, zamiast traktować jedną udaną trajektorię jako pełny opis produktu.

Wersje benchmarków i publiczne zapisy ograniczają twierdzenia o zwycięzcy

Opublikowane wyniki są możliwym do sprawdzenia materiałem dowodowym, ale pozostają ograniczone przez wersje benchmarków, konfiguracje i kompletność weryfikacji.

Sam Terminal-Bench dostarcza jasnego przykładu, dlaczego oznaczenia wersji mają znaczenie. Jego wersja 2.1 naprawiła problemy w 28 z 89 zadań poprzedniej edycji. Opiekunowie projektu zgłosili zmiany w reprezentatywnych wynikach agentów i modeli po tych poprawkach.

Ta historia sprawia, że wersja benchmarku jest częścią twierdzenia. Wyniku z Terminal-Bench 2.0 nie można po prostu traktować jako wymiennego z wynikiem z wersji 2.1. Zadania i warunki ewaluacji się zmieniły, nawet jeśli prezentowana metryka zachowuje tę samą nazwę.

Ta sama zasada dotyczy harnessu. Wynik należy do testowanej wersji oprogramowania i jej ustawień. Jeśli aktualizacja zmienia instrukcje, wykonywanie narzędzi lub zachowanie przy zakończeniu działania, wcześniejszy wynik opisuje wcześniejszą implementację.

Tworzy to wyzwanie dla szybko zmieniających się publicznych dyskusji. Wykres może krążyć po zmianie tablicy wyników, podczas gdy komentarze nadal traktują go jako aktualny. Czytelnicy potrzebują pierwotnej konfiguracji i daty pomiaru, aby ustalić, co obraz nadal potwierdza.

Projektowe publiczne zapisy uruchomień oferują drogę do sprawdzenia tych szczegółów. Dostępność zapisów jest korzyścią dla przejrzystości. Ich publikacja nie oznacza, że każdy wynik przeszedł już niezależną reprodukcję lub pełny ręczny przegląd.

Niezależna reprodukcja wymagałaby uruchomienia określonych konfiguracji i sprawdzenia, czy odpowiednie wzorce się utrzymują. Analiza zapisów może wspierać audyt zgłoszonych obliczeń lub pojedynczych zachowań. Te działania dostarczają różnych rodzajów dowodów.

Pytanie przyczynowe pozostaje szczególnie wymagające. Różnica w wyniku może wskazywać związek między konfiguracją a rezultatem w kontrolowanych warunkach. Wyjaśnienie tej różnicy wymaga zbadania niepowodzeń oraz przetestowania, czy proponowana zmiana je modyfikuje.

Na przykład podejrzenie problemu z limitem czasu powinno zostać sprawdzone przez zmianę limitu przy zachowaniu innych istotnych warunków. Podejrzenie utraty informacji wymaga przeanalizowania, jakie informacje zniknęły i czy ich zachowanie poprawia wyniki. Żadne z tych wyjaśnień nie wynika automatycznie z niskiej pozycji.

Znajomość benchmarku wprowadza kolejną kwestię wartą zbadania bez zakładania niewłaściwego postępowania. System zoptymalizowany względem publicznych zadań może poprawić wyniki w tym rozkładzie zadań, nie poprawiając się równie mocno gdzie indziej. Dowody z nieznanych zadań pomogłyby ustalić, jak szeroko przenosi się ta korzyść.

Zakres zadań stanowi osobne ograniczenie. Utrzymanie repozytorium obejmuje konwencje organizacyjne, niejednoznaczne prośby i oczekiwania dotyczące przeglądu przez ludzi, których ustalony benchmark nie jest w stanie w pełni uchwycić. Benchmark nadal może być użyteczny, pozostawiając te pytania wdrożeniowe bez odpowiedzi.

Praktyczną odpowiedzią jest zachowanie proporcji między dowodami a decyzją. Publiczny wynik może uzasadniać krótką listę kandydatów lub ukierunkowaną próbę. Zastąpienie procesu tworzenia oprogramowania w zespole wymaga dodatkowych dowodów z pracy przypominającej rzeczywiste obowiązki tego zespołu.

Przechowywanie konfiguracji, przykładów niepowodzeń i decyzji recenzyjnych razem ułatwia ponowne analizowanie takich porównań. Przeszukiwalna baza wiedzy może pomóc zachować historię tej ewaluacji obok dokumentów technicznych wykorzystywanych podczas testów.

Luka w weryfikacji nie odbiera eksperymentowi wartości. Określa, co obecnie potwierdzają wyniki i jakie dodatkowe działania mogłyby je wzmocnić. To użyteczniejsze odczytanie niż dosłowne przyjmowanie każdej pozycji albo całkowite odrzucanie porównania.

Kolejne testy powinny śledzić aktualizacje, reprodukcję i pracę bez nadzoru

Najmocniejsze dalsze dowody połączą zmiany wersji z odtwarzalnymi ulepszeniami w pracy wykraczającej poza początkowe porównanie.

Pierwszym sygnałem, który warto obserwować, jest zaktualizowana wydajność harnessu z jasną historią wersji. Gdy deweloper zmienia oprogramowanie wykonawcze, porównywalne ponowne uruchomienie może pokazać, czy zmienia się dokładność, efektywność lub konsekwencja. Zachowanie wcześniejszej konfiguracji nadaje temu porównaniu sens.

Poprawa w powtarzanych pomiarach wzmocniłaby argument, że inżynieria harnessu istotnie wpływa na wyniki. Rezultat, który znika w porównywalnych ponownych uruchomieniach, osłabiłby zaufanie do deklarowanej korzyści. Każdy z tych rezultatów dostarcza więcej informacji niż zaktualizowana odznaka zwycięzcy.

Daje to również dostawcom konstruktywny sposób reakcji. Mogą wskazać wzorzec niepowodzeń, wyjaśnić istotną zmianę implementacyjną i opublikować dowody dotyczące rezultatu. Czytelnicy mogą wtedy ocenić konkretną tezę inżynieryjną, zamiast wnioskować o jakości na podstawie reputacji produktu.

Drugim sygnałem jest niezależna reprodukcja przy zgodnych kontrolach. Osobny ewaluator powinien udokumentować model, warunki dostawcy, ustawienia rozumowania, wersję zadań i wersję harnessu. Różnice muszą pozostać widoczne, zamiast zostać włączone do pozornie identycznego wyniku.

Jeśli niezależne wyniki zachowują ogólną kolejność lub wzorce specyficzne dla modeli, zaufanie do porównania rośnie. Jeśli wyniki się rozchodzą, wskazuje to na warunki wymagające bliższego zbadania. Zachowanie dostawcy, ustawienia wykonania i szczegóły pomiaru stają się pytaniami badawczymi, a nie wygodnymi wyjaśnieniami.

Reprodukcja nie wymaga idealnej zgodności każdej liczby. Istotne jest to, czy wniosek przetrwa rozsądne powtarzane pomiary. Bliskie wyniki powinny pozostać bliskie, chyba że dodatkowe dowody uzasadniają ich rozróżnienie.

Trzecim sygnałem jest wydajność przy nieznanej pracy z wyraźnymi kryteriami sukcesu bez nadzoru. Oznacza to sprawdzenie, czy agent kończy zlecone zadanie, weryfikuje rezultat i odpowiednio obsługuje niepowodzenie. Interwencję człowieka należy rejestrować, ponieważ zmienia ona znaczenie „autonomicznego ukończenia”.

Konsekwentne ulepszenia w takiej pracy wzmocniłyby praktyczne znaczenie ustaleń leaderboardu. Zyski ograniczone do znanych zadań benchmarkowych zawęziłyby ich znaczenie. To rozróżnienie ma większe znaczenie dla wdrożenia niż kolejny niewielki ruch w ogólnej średniej.

Dla zespołów wybierających obecnie oprogramowanie dowody przemawiają za porównywaniem na poziomie rzeczywistego zestawienia. Kimi Code, Hermes Agent, Pi, Claude Code, Codex i mini-swe-agent zasługują na ocenę w konfiguracjach, których zespół zamierza używać. Same ich nazwy nie mogą przesądzić wyniku.

Leaderboard harnessów Niklausa daje tej ocenie publiczny punkt wyjścia, z wynikami z uruchomienia, powtarzanymi próbami i dostępnymi zapisami. Jego trwały wkład będzie zależeć od tego, czy te pomiary pomogą wyjaśniać i ulepszać zachowanie agentów.

Przed zmianą procesu programowania porównaj wybrane zestawienie z konfiguracją, której już ufasz, wykorzystując reprezentatywne prace utrzymaniowe. Zapisz dokładną konfigurację, dowody ukończenia, wysiłek recenzenta oraz niepowodzenia wymagające interwencji. Uwzględnij zadania, w których wiarygodny patch nie wystarcza bez pomyślnego etapu weryfikacji. Wróć do porównania po istotnej aktualizacji harnessu, zachowując wcześniejsze wyniki, aby zmiany pozostawały zrozumiałe. Traktuj publiczną tablicę jako dowód wspierający tę decyzję, jednocześnie pozostawiając własnemu procesowi decydujący głos. Pytanie, na które warto odpowiedzieć, jest konkretne: które przetestowane połączenie dostarcza pracę, którą zespół może zweryfikować, powtórzyć i zaakceptować przy nadzorze, jaki faktycznie jest w stanie zapewnić?