ChatGPT czy Claude do kodowania? Wynik zależy od rodzaju zadania

Przy wyborze narzędzia do naprawiania kodu Claude jest mocnym kandydatem. Jeśli jednak najczęściej zlecasz agentowi pracę w repozytorium, uruchamianie poleceń i przegląd zmian, porównaj go z Codexem dostępnym w ekosystemie ChatGPT. Publiczne wyniki nie wskazują jednego zwycięzcy dla wszystkich tych zadań.

Znaczenie ma również to, czy kupujesz subskrypcję produktu, czy płacisz za użycie modelu przez API. Model działający w agencie może osiągnąć inny wynik przy zmianie narzędzi, limitu czasu lub poziomu wysiłku. Porównanie samych nazw modeli nie mówi więc, ile pracy pozostanie programiście po otrzymaniu poprawki.

Poprawki w repozytorium: co naprawdę pokazuje wynik

W zestawieniu BenchLM Claude Opus 5.5 uzyskuje 89,9% w SWE-bench Pro, najwyższy pokazany tam wynik tego testu, podczas gdy GPT-6 Astra nie ma w nim odpowiadającego wiersza. W ogólnym rankingu tej witryny przedziały wyników obu modeli się nakładają. Rezultat Opus 5.5 uzasadnia umieszczenie go wśród kandydatów do naprawiania kodu, lecz brak wyniku Astry w tym samym teście nie pozwala ogłosić wygranej w bezpośrednim pojedynku.

Wersja testu zmienia podstawę porównania. SWE-bench Pro V2 firmy Scale obejmuje 642 zadania z 11 repozytoriów; organizator zmienił zbiór i protokół oceny. W pokazanej tam tabeli występują między innymi Opus 5 uruchomiony w Claude Code z ustawieniem xhigh oraz GPT-6 Astra w Codexie z ustawieniem high, ale nie Opus 5.5. Nie należy przenosić wyniku Opus 5.5 z innego zestawienia do tej tabeli ani przypisywać wyniku całego agenta wyłącznie modelowi.

SWE-bench Pro sprawdza, czy agent potrafi przygotować poprawkę do problemu w istniejącej bazie kodu. Dla zespołu podobne zadanie kończy się dopiero wtedy, gdy zmiana przechodzi testy i nadaje się do zaakceptowania po przeglądzie. Publiczny odsetek rozwiązanych zadań pomaga ocenić zdolność do naprawiania oprogramowania, ale sam nie pokazuje, jak szeroka będzie zmiana ani ile czasu zajmie jej przegląd.

Terminal wymaga oceny całego agenta

Przy wieloetapowej pracy w terminalu liczy się nie tylko poprawny kod. Agent musi wykonać polecenia w odpowiedniej kolejności, poradzić sobie ze środowiskiem i zareagować na nieudany test. Dlatego wynik Terminal-Bench odpowiada na inne pytanie niż wynik testu, w którym końcowym artefaktem jest poprawka w repozytorium.

Twórcy Terminal-Bench 4.0 zmienili zasoby dostępne agentowi, poprawili zadania i usunęli część z nich; wskazują, że taka zmiana wymaga ponownego uruchomienia prób. Wyniku starszej wersji nie można zatem odejmować od wyniku 4.0, by wyliczyć przewagę Claude lub Codexa. Nawet przy tej samej wersji trzeba sprawdzić użytego agenta i ustawienie wysiłku: rezultat dotyczy konkretnej konfiguracji, nie dowolnego sposobu korzystania z produktu.

Dla programisty zlecającego długie zadania ważny jest również przebieg pracy. Dwie konfiguracje mogą doprowadzić do poprawnego wyniku, lecz różnić się liczbą ponowień, zakresem wykonanych poleceń i kosztem. To szczególnie istotne, gdy zadanie obejmuje konfigurację środowiska lub diagnozę błędu, a nie tylko zmianę wskazanego pliku.

Przegląd kodu i krótkie iteracje to osobne zadania

W przeglądzie kodu wartość uwagi zależy od tego, czy wskazuje konkretny problem i pozwala szybko sprawdzić jego skutek. Sama liczba komentarzy może mylić: fałszywy alarm zabiera czas, choć wygląda na aktywność agenta. Wyniku benchmarku naprawiania repozytoriów nie da się bezpośrednio przełożyć na jakość recenzji zmian.

Praca interaktywna również ma inną miarę niż autonomiczne wykonanie zadania. Programista może zawęzić zakres poprawki, doprecyzować wymaganie i zatrzymać błędny kierunek po pierwszej próbie. W takim trybie znaczenie mają czytelność proponowanych zmian oraz to, czy narzędzie zachowuje wcześniejsze ograniczenia w kolejnych odpowiedziach. Narzędzie skuteczne w długim samodzielnym przebiegu nie musi być najwygodniejsze do serii małych poprawek.

Długi kontekst i cena modelu

Duże okno kontekstowe pomaga, gdy istotne zależności są rozrzucone po wielu plikach. Nie gwarantuje jednak, że agent wybierze właściwe pliki ani zachowa wszystkie ograniczenia zadania. Przy dużym projekcie liczy się więc zarówno dostępna pojemność, jak i trafność zmian uzyskanych z podanego kontekstu.

Dokumentacja Claude Opus 5.5 podaje okno kontekstowe o wielkości 1 mln tokenów oraz podstawowe ceny API: 4 USD za milion tokenów wejściowych i 20 USD za milion wyjściowych. Są to parametry modelu i rozliczenia API, a nie cena subskrypcji Claude. Długie wejście zwiększa potencjalny rachunek, dlatego przy pracy na dużym repozytorium opłaca się oceniać koszt poprawki, którą można przyjąć, a nie tylko koszt pojedynczego wywołania.

Co obejmuje płatny produkt

ChatGPT, Codex i dostęp przez API nie są tym samym sposobem zakupu. Opis OpenAI wskazuje, że Codex służy do pracy z repozytoriami, uruchamiania testów i poleceń oraz przeglądu zmian; logowanie kontem ChatGPT wykorzystuje limity planu, a własny klucz API oznacza rozliczenie według cen API. Dostęp do poszczególnych modeli zależy ponadto od planu i ustawień przestrzeni roboczej.

Przy subskrypcji pytanie brzmi, czy dostępny limit wystarczy na typową liczbę i długość zadań. Przy API dochodzą tokeny wejściowe i wyjściowe oraz koszt ponowień. Tańszy model może okazać się droższy w użyciu, jeżeli częściej wymaga powtórzenia zadania lub ręcznej naprawy wyniku. To ocena całego procesu pracy, a nie twierdzenie o stałej przewadze cenowej któregoś produktu.

Macierz wyboru według zadania

• Naprawa istniejącego kodu: Claude Opus 5.5 jest uzasadnionym kandydatem, lecz zestawiaj go z dostępną konfiguracją Codexa na tych samych problemach. Zapisz wersję testu, agenta i poziom wysiłku przed porównaniem wyniku.
• Długa praca w terminalu: oceniaj wykonanie całej sekwencji poleceń, odzyskiwanie pracy po błędzie i koszt ukończenia. Wyniki różnych wersji Terminal-Bench traktuj jako odrębne pomiary.
• Przegląd zmian: wybieraj według trafnych uwag i czasu potrzebnego na odrzucenie fałszywych alarmów, a nie według miejsca w rankingu naprawiania błędów.
• Duży projekt: sprawdzaj, czy agent odnajduje potrzebne zależności i utrzymuje ograniczenia zadania. Rozmiar okna kontekstowego jest tylko jednym z warunków takiej pracy.
• Krótkie iteracje: zwracaj uwagę na kontrolę zakresu zmian i łatwość korygowania kierunku. Przy wyborze płatnego dostępu uwzględnij limit planu albo pełny koszt użycia API.