Ślepy sędzia: ocena Claude Code kontra Codex w 36 pojedynkach

Thomas Ricouard (@Dimillian) ujął to lepiej niż jakikolwiek benchmark: „Claude Code to taki bardzo, bardzo przeciętny refactoring, o którym wiem, że potrafi go wykonać. Codex to architektura na najwyższym poziomie. Nie jestem jeszcze pewien, czy faktycznie da radę to zrobić bez psucia rzeczy.”¹

Przestałem się zastanawiać i zacząłem mierzyć. Zbudowałem system, który wyściguje Claude Code z Codex CLI na tym samym zadaniu, losowo oznacza wyniki jako Alpha i Beta, a następnie ocenia oba plany w ciemno w pięciu wymiarach, zanim ujawni, który agent napisał który plan. Po trzydziestu sześciu pojedynkach tablica wyników mówi, że Claude wygrał 8 z 12 rozstrzygniętych pojedynków. Ale tablica wyników nie jest istotą sprawy. Istotą jest to, co ślepy sędzia tworzy po ocenie: synteza łącząca najsilniejsze elementy obu planów w coś lepszego, niż którykolwiek z uczestników dostarczył samodzielnie.

TL;DR

Trzydzieści sześć pojedynków. Ślepa ocena w pięciu wymiarach (Poprawność, Kompletność, Prostota, Dekompozycja, Wykonalność). Claude Code wygrał 8, Codex CLI wygrał 3, jeden nierozstrzygnięty, w 13 pojedynkach ze strukturalnymi manifestami oceny (12 z ogłoszonym zwycięzcą). Prawdziwym wynikiem nie jest zwycięzca. Jest nim etap syntezy, który wybiera najlepsze elementy z obu planów i tworzy brief implementacyjny silniejszy niż którykolwiek agent samodzielnie. Towarzyszący post Thinking With Ten Brains omawia wspólną deliberację.¹² Ślepy sędzia obejmuje ocenę opartą na rywalizacji. Metodologia ma większe znaczenie niż tablica wyników.

Dlaczego porównywanie jest trudne

Wszyscy teraz porównują agentów kodujących AI. Nikt nie zgadza się co do wyników.

Problem jest strukturalny. Porównania modeli degradują wzdłuż trzech osi: wibracje (wypróbowałeś jedno zadanie na każdym i poszedłeś za intuicją), efekt świeżości (ostatni sukces nadpisuje wszystkie wcześniejsze porażki) oraz mocne strony specyficzne dla zadania (model, który wygrywa przy refaktoringu, przegrywa przy przeglądzie bezpieczeństwa). To nie są złe obserwacje. To złe eksperymenty.

Alex Finn (@AlexFinn) prowadzi przepływ podwójnej walidacji, w którym dwa modele sprawdzają nawzajem swoje wyniki.² Podejście z podwójnym sprawdzaniem wyłapuje błędy, które każdy z modeli osobno by pominął. Spostrzeżenie jest trafne: niezależna ocena ujawnia rozbieżności, a rozbieżności to miejsce, gdzie kryją się błędy.

@doodlestein uruchamia równocześnie ponad 10 agentów — Claude, Codex i Gemini — używając gotowych promptów, które nazywa „kreatorami pomysłów”, aby atakować ten sam problem z różnych stron.³ Planista, który doskonale radzi sobie z dekompozycją, może przeoczyć błąd poprawności, który bardziej szczegółowy agent wyłapuje natychmiast.

Oba przepływy pracy przewyższają ocenę jednomodelową. Żaden nie eliminuje największego zagrożenia: błędu potwierdzenia. Jeśli wiadomo, który model napisał który plan, wyżej ocenimy ten model, któremu bardziej ufamy. Za każdym razem. Nie dlatego, że jesteśmy niedbali, ale dlatego, że błąd poznawczy działa poniżej świadomości. Brakujący element to zaślepienie. Jeśli osoba oceniająca nie wie, który agent stworzył który wynik, błąd potwierdzenia nie ma się do czego przyczepić.

Protokół ślepej oceny

System /duel działa w pięciu fazach:

1. Równoległe wykonanie. Oba agenty otrzymują ten sam prompt zadania i kontekst projektu. Claude Code działa w jednym procesie, Codex CLI w drugim. Żaden nie widzi wyniku drugiego.
2. Losowe oznaczanie. Rzut monetą przypisuje jednego agenta do „Alpha”, a drugiego do „Beta”. System zapisuje mapowanie do agent-mapping.json i zamyka je. Ani sędzia, ani ja nie widzimy mapowania aż do zakończenia oceny.
3. Ślepa ocena. Agent-sędzia czyta oba plany i ocenia każdy w pięciu wymiarach, 0-4 punkty na wymiar, maksymalnie 20 punktów łącznie. Sędzia widzi jedynie „plan Alpha” i „plan Beta”.
4. Rekomendacja zwycięzcy. Sędzia ogłasza zwycięzcę (lub brak rozstrzygnięcia) z poziomem pewności i pisemnym uzasadnieniem.
5. Synteza. Sędzia łączy najsilniejsze elementy obu planów w dopracowany brief implementacyjny. Synteza jest właściwym wynikiem.

Pięć wymiarów oceny:

Kluczowa decyzja projektowa: synteza nie jest mieszanką 50/50. Mocno faworyzuje główną strategię zwycięzcy, wybierając przy tym autentyczne spostrzeżenia przegranego. Wczesne próby syntezy z równą wagą dawały niespójne plany, które dziedziczyły najgorsze cechy obu. Synteza ważona tworzy plany, które są strukturalnie spójne (od zwycięzcy) i gruntownie wzmocnione (od prawidłowych przypadków brzegowych przegranego).

Studium przypadku: pojedynek nad remediowaniem bezpieczeństwa

W lutym 2026 roku trzyagentowy audyt bezpieczeństwa znalazł 7 ustaleń CRITICAL i 7 HIGH w ResumeGeni, aplikacji FastAPI z autoryzacją Supabase i płatnościami Stripe.⁴ Dwie trywialne poprawki były już wdrożone. Pozostało dziewięć. Uruchomiłem pojedynek, aby wygenerować plan remediacji.

Oba agenty otrzymały ten sam briefing: listę ustaleń ze ścieżkami plików i numerami linii, kontekst architektury, ograniczenie, że sprawdzony wzorzec poprawki już istnieje w jednym pliku, oraz wymóg stworzenia fazowego planu wdrożenia.

Plan Alpha: 11 historii dla 9 ustaleń, zorganizowanych w trzy fale wdrożeniowe. Historia z bazą testową (SEC-01) blokowała wszystkie kolejne prace. Bramki wdrożeniowe z konkretnymi metrykami: wskaźnik sukcesu autoryzacji, monitoring 5xx, liczniki odrzuconych webhooków. Gruntowna dyskusja nad odrzuconymi alternatywami. Historie używały struktury Co/Dlaczego/Sukces z zakresami linii.

Plan Beta: Bezpośrednie mapowanie 1:1 ustaleń na historie. Trzy fale wdrożeniowe: Critical jako jedna całość, High-priority jako niezależnie wdrażalne, Cleanup. Podejście „zbadaj-przed-naprawą” dla ustalenia dotyczącego middleware. Konkretne numery linii, nazwy funkcji, ścieżki importów i polecenia curl do weryfikacji dla każdej historii.

Różnica w poprawności opowiedziała całą historię. Beta wyłapała dwie rzeczy, które Alpha całkowicie pominął.

Po pierwsze: ustalenie dotyczące middleware (C3) oznaczyło get_user(jwt=...) jako wektor kontaminacji sesji. Beta prawidłowo zidentyfikowała, że get_user() jest bezstanowym wywołaniem weryfikacyjnym. gotrue-py wywołuje _save_session() jedynie w verify_otp i exchange_code_for_session, a nie w get_user. Alpha potraktował to jako bezwzględnie wymagające tej samej poprawki co dwa pozostałe routery, co dodałoby niepotrzebny narzut na każde żądanie uwierzytelnione. Beta powiedziała: najpierw zbadaj, napraw tylko po potwierdzeniu.

Po drugie: routery magic link i passkeys używają zarówno admin.generate_link() (wymagającego singletonu SERVICE_KEY), jak i verify_otp() (potrzebującego świeżego klienta per-request). Plan Alpha zastosował wzorzec świeżego klienta jednolicie. Implementator podążający za tym planem zepsułby operacje administracyjne. Beta jawnie wskazała podział: świeży klient dla verify_otp, współdzielony singleton dla admin.generate_link().

Wyniki:

Alpha to był Codex. Beta to był Claude. Wysoka pewność.⁴

Synteza połączyła techniczną precyzję Beta z operacyjną rygoryzmem Alpha. Oto jedna historia z wyniku syntezy, pokazująca, jak oba plany zostały scalone:

Historia 1.1 (C1 — Współdzielony singleton Magic Link): W magic_link.py dodać _create_auth_client(). Użyć świeżego klienta anon WYŁĄCZNIE dla verify_otp (linia 224). Zachować współdzielony singleton dla admin.generate_link() (linia 213), który wymaga SERVICE_KEY.

Ta historia dziedziczy precyzyjne numery linii Beta i kluczowy podział klient admin/anon, opakowane w strukturę pasującą do trzyfazowej sekwencji wdrożeniowej Alpha. Pełna synteza zachowała podejście Beta „najpierw zbadaj” dla C3, konkretne polecenia curl Beta do weryfikacji, bramki wdrożeniowe Alpha (monitoring wskaźnika sukcesu autoryzacji, śledzenie 5xx) oraz strategię testów regresyjnych Alpha (zestaw E2E Playwright auth po Fali 1, testowy webhook Stripe po Fali 2). Rezultat: trzyfazowy plan z 12 historiami, wykonalny w ciągu jednego dnia, z operacyjnymi zabezpieczeniami, których żaden plan sam nie zapewniał.

Tablica wyników (i dlaczego wprowadza w błąd)

W 36 pojedynkach 13 wygenerowało strukturalne manifesty oceny. Jeden manifest uznano za nierozstrzygnięty, pozostawiając 12 z jasnym zwycięzcą:

Claude: 8. Codex: 3. Nierozstrzygnięty: 1.¹¹

Nie należy traktować tablicy wyników jako benchmarku modeli. Nim nie jest.

Wygrane Claude koncentrują się na zadaniach przeglądowych, weryfikacyjnych i bezpieczeństwa: 7 z 8 wygranych to wysoka pewność przy zadaniach obejmujących przegląd kodu, analizę bezpieczeństwa lub ocenę techniczną. Jedyna wygrana Codex z wysoką pewnością dotyczyła przeglądu kodu, gdzie jego proceduralność i jawne łańcuchy zależności przewyższyły mniej ustrukturyzowane podejście Claude. Dwie pozostałe wygrane miały niską pewność. Wzorzec: Claude tworzy bardziej wykonalne, technicznie precyzyjne plany. Codex tworzy silniejszy proces operacyjny i szersze pokrycie teoretyczne.

Ricouard miał rację. Jakość planowania kontra niezawodność wykonania to rzeczywista oś.¹ Ale tablica wyników odzwierciedla mój mix zadań (zdominowany przez bezpieczeństwo i przeglądy architektury), a nie jakiś obiektywny ranking modeli. Ktoś prowadzący pojedynki nad rozwojem greenfield lub automatyzacją infrastruktury prawdopodobnie zobaczyłby inne wyniki. Analiza Nathana Lamberta dotycząca ery post-benchmarkowej stawia tę samą tezę: tradycyjne benchmarki nie przekazują już znaczącego sygnału, gdy drobne różnice między Opus 4.6 a Codex 5.3 zależą od kształtu zadania i metodologii oceny.¹⁰

Tablica wyników mówi o moim przepływie pracy. Nie mówi, który model jest „lepszy”.

Synteza jest produktem

Zwycięski plan nie jest istotą sprawy. Synteza jest.

Każdy pojedynek tworzy trzy artefakty: Plan Alpha, Plan Beta i Syntezę. Synteza podąża za spójną strukturą: przyjmij główną strategię zwycięzcy, włącz prawidłowe przypadki brzegowe przegranego, usuń zbędny zakres z obu. Nie jest dyplomatyczna. Nie idzie na kompromis. Dokonuje jawnych wyborów, które elementy zachować, a które odrzucić, z pisemnym uzasadnieniem dla każdego.

W pojedynku o rozszerzenie korpusu ofert pracy plan Claude najpierw aktywował istniejącą infrastrukturę (skrypty seed dla 8780 znanych tablic, których system jeszcze nie odpytywał), potem rozszerzał na nowe platformy ATS, a następnie budował systemy odkrywania.⁶ Plan Codex zaczynał od audytu bazy kodu i specyfikacji instrumentacji, zanim pobrano choćby jedną ofertę. Claude wygrał na prostotę i wykonalność. Ale Codex zidentyfikował coś, co Claude pominął: potrzebę automatu stanów cyklu życia tablicy (active/failing/quarantined). Codex również wskazał audyt regresji deduplikacji, aby rozszerzanie wolumenu nie maskowało eksplozji duplikatów. Synteza zachowała sekwencjonowanie Claude „najpierw aktywuj” i włączyła monitorowalność oraz śledzenie cyklu życia Codex jako Fazę 1.5, po tym jak początkowe seedowanie dostarczyło mierzalne rezultaty. Ten sam wzorzec pojawił się w pojedynku o system pobierania ofert, gdzie plan Claude wykorzystywał istniejący APScheduler i tabele rejestru, podczas gdy Codex zaproponował bardziej gruntowny dwutabelowy schemat provenance. Synteza przyjęła pragmatyczną architekturę Claude i wybrała ulepszenie hasha deduplikacji Codex.⁷

W pojedynku o przegląd ATS Claude znalazł awarie P0 w runtime (niedopasowania sygnatur metod w schedulerze, które po cichu łamałyby śledzenie ofert), których Codex całkowicie nie wyłapał.⁵ Codex znalazł zapobieganie nakładaniu się schedulera i wektory nadużyć endpointów administracyjnych, których Claude nie oznaczył. Synteza zaczęła od poprawek P0 Claude i uzupełniła je operacyjnym wzmocnieniem Codex.

Wzorzec w 36 pojedynkach: model-sędzia konsekwentnie tworzy syntezy silniejsze niż plan któregokolwiek z uczestników. Sędzia nie jest mądrzejszy. Struktura adversarialna wymusza pełne pokrycie.⁹ Każdy agent niezależnie identyfikuje ryzyka i przypadki brzegowe. Sędzia widzi je wszystkie. Synteza dziedziczy sumę spostrzeżeń obu agentów minus ich indywidualne martwe pola.

Wzorzec ten łączy się z szerszym wnioskiem z deliberacji wieloagentowej: niezależność jest mechanizmem. Dziesięciu agentów deliberujących, oceniających decyzję z różnych perspektyw, wyłapuje błędy poznawcze, które każdy pojedynczy agent pomija. Dwóch rywalizujących agentów atakujących to samo zadanie z różnych architektur wyłapuje luki implementacyjne, które którykolwiek agent osobno by wdrożył. Krok syntezy jest taki sam w obu systemach: połączenie niezależnych ocen w pojedynczy artefakt korzystający ze wszystkich perspektyw.

Dokumentuję warstwę orkiestracji, która wspiera oba systemy, osobno. Istotne jest tutaj to, że pojedynkowanie i deliberacja pełnią komplementarne funkcje. Deliberacja odpowiada na pytanie „czy powinniśmy to budować?” Pojedynkowanie odpowiada na pytanie „jaki jest najsilniejszy sposób budowy?”

Kiedy pojedynkować, a kiedy deliberować

Oba systemy wykorzystują niezależną ocenę i syntezę. Służą różnym typom decyzji.

Mój wzorzec: deliberuj nad projektem, pojedynkuj nad planem implementacji, wykonaj syntezę.

Decyzja o remediacji bezpieczeństwa przechodzi najpierw przez deliberację („Czy to właściwe priorytety? Czy pomijamy problemy systemowe?”), następnie przez pojedynkowanie („Jaki jest najsilniejszy fazowy plan wykonania tych poprawek?”), a potem realizacja z syntezy sędziego. System deliberacji i system pojedynkowania współdzielą infrastrukturę, ale pełnią odrębne funkcje w procesie decyzyjnym.

Co zrobiłem źle

Wczesne pojedynki nie miały ślepego oznaczania. Czytałem oba plany wiedząc, który model napisał który. Błąd potwierdzenia był realny i mierzalny: konsekwentnie oceniałem Claude wyżej na Wykonalności przed zaślepieniem, a potem widziałem, jak różnica się zmniejsza (choć nie znika) po wprowadzeniu losowego przypisania Alpha/Beta. Protokół zaślepienia nie jest opcjonalny.

Zacząłem od trzech wymiarów oceny (Poprawność, Kompletność, Wykonalność). Po dwóch pojedynkach zdałem sobie sprawę, że łączę strukturę planu z treścią planu. Dodanie Prostoty (czy to nadmiernie rozbudowane?) i Dekompozycji (czy kroki są dobrze uporządkowane?) rozdzieliło te kwestie i dało bardziej użyteczne oceny.

Pierwsze próby syntezy mieszały oba plany równomiernie. Wyniki były niespójne: strategia testowa Alpha przeszczepiona na sekwencję wdrożeniową Beta, przy czym żadne z założeń obu planów się nie utrzymywało. Synteza ważona, w której sędzia jawnie przyjmuje ramy zwycięzcy i selektywnie włącza spostrzeżenia przegranego, była przełomem.

N=36 na moim mixie zadań to nie benchmark modeli. To ocena narzędzia przepływu pracy. System pojedynkowania mówi mi, który agent stworzył silniejszy plan dla mojego konkretnego zadania w mojej konkretnej bazie kodu. Ekstrapolacja do „Claude jest lepszy od Codex” byłoby tym samym rozumowaniem opartym na wibracjach, które system ma eliminować.

Używam Claude do oceniania pojedynków między Claude a Codex. Uznaję ten konflikt interesów.⁸ Mitygacja jest strukturalna: ślepe oznaczanie, ustrukturyzowane wymiary oraz fakt, że Codex wygrał 3 pojedynki i był blisko w kilku innych. Silniejszym testem byłoby przepuszczenie tych samych pojedynków przez sędziego spoza rodziny Claude (Gemini lub GPT) i porównanie rozkładów ocen. Jeszcze tego nie zrobiłem. Dopóki tego nie zrobię, podział 8-3 powinien mieć gwiazdkę: sędzia i jeden z uczestników należą do tej samej rodziny modeli.

Przypisy