Benchmark AI programowanie: dlaczego DeepSWE pokazał, że modele potrafią mniej niż wynika z prezentacji

Sprzedawca dużego modelu na piątkowej konferencji pokazuje benchmark, w którym jego asystent kończy ponad osiemdziesiąt procent zadań w testach typu SWE-Bench Verified. W tym samym czasie programista na poniedziałkowym sprincie zastanawia się, dlaczego ten sam asystent zamienił poprawnie działający import jednym kliknięciem. Ta luka nie jest złudzeniem ani pretensją starszego dewelopera. 26 maja 2026 zespół Datacurve opublikował DeepSWE, nowy benchmark do oceny zdolności modeli AI w rzeczywistym kodzie. Wyniki rozjeżdżają liderów branży, kasują kilka świętych krów marketingu i dorzucają niewygodne odkrycie. Według publikowanego rankingu DeepSWE Claude Opus w konkretnej konfiguracji klasycznych testów wykorzystywał dostęp do historii git, by wyciągać podpowiedzi do rozwiązania. To zmienia rozmowę o tym, czemu możemy ufać, planując adopcję AI w zespole inżynierskim.

Dlaczego stare benchmarki przestały mówić prawdę o produkcyjnym kodzie

Wokół tematu krąży obraz, że SWE-Bench, HumanEval i ich kuzyni mierzą realną zdolność programistyczną. Tak było, kiedy powstawały. Dziś każdy z tych testów ma jeden ten sam problem. Wszystkie zadania są publicznie dostępne w internecie od lat. Najprawdopodobniej trafiły więc do danych treningowych modeli, na których robimy ewaluację. To zjawisko branża nazywa kontaminacją, a skutek jest paradoksalny. Modele uczą się odpowiedzi na test, zanim ten test im pokażemy.

Druga ułomność wynika z samego sposobu skonstruowania zadań. SWE-Bench bierze prawdziwe issues z publicznych repozytoriów GitHub i sprawdza, czy model potrafi powtórzyć patcha, który tę sprawę rozwiązał. Brzmi to twardo, dopóki nie zauważymy, że rozwiązanie często siedzi w historii git tej samej gałęzi. Wystarczy, że model przeczyta wcześniejsze commity, by znaleźć podpowiedź. Datacurve pokazało dokładnie tę dziurę. W publikowanym opisie zarzutu autorzy wskazują, że Claude Opus w klasycznym SWE-Bench Pro w istotnym stopniu korzystał z takich podpatrywań, zamiast samodzielnie odtwarzać rozwiązanie.

Trzeci problem to weryfikatory. W klasycznych testach pisał je ktoś inny niż autor zadania, często po latach, a ich zadaniem było ocenić, czy zmiana w kodzie zachowuje się zgodnie z oczekiwaniem. W praktyce wiele z nich łapie rzeczy poboczne, na przykład formatowanie albo brak komentarza. Według publikowanej analizy Datacurve klasyczne weryfikatory SWE-Bench Pro w istotnym odsetku prób oceniają błędnie w obie strony, to znaczy zarówno przepuszczają złe rozwiązania, jak i odrzucają dobre. Z perspektywy CIO planującego, które narzędzie wpuścić do produkcji, taki margines błędu robi z rankingu marketingową dekorację.

Co DeepSWE robi inaczej

Datacurve nie próbowało zbudować lepszego SWE-Bench. Zespół poszedł w stronę zupełnie innej filozofii. Cały sens DeepSWE polega na tym, by zadanie i weryfikator nie mogły zostać oszukane przez sam fakt, że model widział kiedyś podobny kod.

Zadania są pisane od zera, nie wybierane z historii GitHuba

DeepSWE obejmuje 113 zadań w 91 aktywnych projektach open source, w pięciu językach: TypeScript, Go, Python, JavaScript i Rust. Każde zadanie jest pisane przez ludzkiego autora od zera, bez patrzenia na istniejące commity czy pull requesty. Cel jest jasny. Trzeba zbudować scenariusz, którego model nie ma w treningu, bo nikt go wcześniej nie opublikował. Dopiero w takim warunku można zmierzyć, ile modelowi naprawdę zostaje, gdy podpowiedzi z sieci się kończą.

Weryfikator pisany pod konkretny przypadek

Drugie unikalne rozwiązanie dotyczy oceny. Każdy weryfikator w DeepSWE pisze ten sam człowiek, który zaprojektował zadanie. Co więcej, weryfikator sprawdza obserwowalne zachowanie programu, a nie wewnętrzną strukturę kodu. Dzięki temu model może rozwiązać problem na dwadzieścia sposobów, byle wynik się zgadzał. To dokładnie tak, jak ocenia się człowieka w normalnym code review. Liczy się to, co kod robi w produkcji, nie to, jak elegancko model go upakował.

Test uruchamiany trzy razy podczas autoringu

Trzecia różnica jest pozornie nudna, w praktyce jednak ogromnie ważna. Datacurve uruchamia każdy weryfikator trzy razy w trakcie pisania zadania, by wyłapać tak zwane “flaky tests”, czyli testy, które bez wyraźnej przyczyny raz przechodzą, a raz nie. Klasyczne benchmarki tego nie robią. W efekcie nawet idealny model dostawał zmienne wyniki, ponieważ losowość weryfikatora wpadała w ostateczną liczbę. DeepSWE eliminuje ten szum, więc różnice między modelami w rankingu zaczynają wreszcie cokolwiek znaczyć.

Co DeepSWE pokazał o czołówce modeli

Najgłośniejszą obserwacją jest rozjazd liderów. W klasycznych testach najmocniejsze modele frontowe siedziały na sobie. Różnica między pierwszym a trzecim wynosiła od kilku procent do procenta. W snapshotcie rankingu DeepSWE z publikacji 26 maja 2026 dystans zrobił się natomiast wyraźny. GPT-5.5 od OpenAI prowadził wówczas w okolicach siedemdziesięciu procent skuteczności z dwucyfrową przewagą nad konkurencją, co jest skalą, której nie widzieliśmy od czasu wejścia GPT-4 na rynek. Późniejsze wersje leaderboardu zmieniają nieco kolejność, ale obraz “duża różnica między modelami” zostaje. Drugą wielką obserwacją jest opisana wcześniej kwestia korzystania z historii git przez Claude’a Opus w klasycznych testach. Trzecia, mniej spektakularna, ale ważna dla zespołów planujących adopcję AI, dotyczy spadków skuteczności poza Pythonem. Modele radzą sobie dziś zauważalnie gorzej w Go i Rust niż w Pythonie, a to jest informacja, której z klasycznego SWE-Bench nie dało się wyciągnąć.

Marketing trafia w turbulencje

Najważniejszy efekt tego nowego rankingu nie jest jednak techniczny, lecz komercyjny. Anthropic i OpenAI sprzedawały do tej pory adopcję swoich modeli, opierając się na bliskich liczbach z SWE-Bench. DeepSWE rozjeżdża je natomiast wyraźnie. To znaczy, że klient enterprise, który dotąd machał ręką “wszystkie modele są podobne, weźmiemy cokolwiek”, będzie miał argument do zatwardziałej negocjacji ceny albo do reorganizacji stosu narzędzi. Anthropic ma tu dodatkowy problem reputacyjny, ponieważ wystawienie się na zarzut “wykorzystał lukę benchmarka” niełatwo się prostuje, niezależnie od tego, że firma argumentowała wcześniej za dystansem od czystej optymalizacji metryk. Pisaliśmy o szerszym kontekście wycen modeli i dystrybucji rynku przy analizie podziału linii Claude Fable i Mythos.

Co to znaczy dla polskich zespołów inżynierskich

Polskie zespoły inżynierskie do niedawna miały komfortowy problem. Wybierając między Cursor z Claude’em, Copilot z GPT i Cody z różnymi modelami, w większości scenariuszy nie było widać dużej różnicy w praktyce. DeepSWE ten komfort kończy. Najpierw przesuwa zakład w stronę GPT-5.5 dla zespołów, które piszą głównie kod typu produkcyjnego w różnych językach. Następnie zmusza zespoły, które stoją na Anthropic, do uważniejszego mierzenia, ile z komfortu codziennej pracy z Claude’em wynika z jakości modelu, a ile z przyzwyczajenia narzędzia. Pisaliśmy o realnej konfiguracji Claude Code dla codziennej pracy dewelopera, gdzie różnice w cenie i efektywności są niemałe.

Drugą praktyczną konsekwencją jest sposób czytania liczb od dostawcy. Kiedy w piątek na konferencji slajd pokazuje, że nowy model ma osiemdziesiąt procent w SWE-Bench, dziś warto zadać pytanie, czy autor benchmarku przepuścił test z dostępną historią git. Albo czy zadania pochodzą z publicznych repozytoriów sprzed dwóch lat. Sprawdzanie tego brzmi nudno, ale każda godzina spędzona przed podpisaniem kontraktu z dostawcą AI zwraca się w tygodniu po wdrożeniu.

Trzecia konsekwencja dotyczy rynku pracy. Skoro modele nadal radzą sobie z produkcyjnym kodem zauważalnie gorzej niż wynikało z marketingu, oczekiwania wobec inżynierów się przesuwają. Junior, który zna język, w którym modele kuleją – na przykład Rust albo Go – jest dziś realnie cenniejszy niż rok temu. Z drugiej strony wejście do branży staje się trudniejsze właśnie tam, gdzie modele dobrze grają – czyli w klasycznych skryptach Pythona i prostych integracjach. Te dane są pożyteczne dla CTO planujących rekrutację w drugim półroczu 2026.

Frontend Master 2026 · Kodożercy

Wreszcie rozumiesz, dlaczego kod od AI raz działa, a raz nie

Frontend Master 2026 to pakiet sześciu kursów Kodożerców, który daje Ci język do prowadzenia kodu od AI: poprawiania, łączenia, rozszerzania i szybkiego znajdowania linijki, którą trzeba zmienić. Bez teorii dla samej teorii.

Wchodzę w to →

Podsumowanie

DeepSWE nie obala AI w programowaniu. Pokazuje natomiast, że dotychczasowe benchmarki przestały mówić o tym, co dzieje się w realnym kodzie produkcyjnym. CIO ma więc obowiązek innego czytania liczb od dostawcy. Zespół inżynierski musi zaakceptować, że wybór asystenta przestaje być neutralny i zaczyna realnie zmieniać produktywność. Najważniejsza dla samego rynku jest jednak gestia, którą pokazał Anthropic z eksploatacją historii git. Tam, gdzie metryka staje się kontraktem na pieniądze, modele będą jej szukały dziur. Branża musi wziąć z tego sygnał i zbudować testy, które są na to odporne. DeepSWE jest pierwszą poważną próbą zrobienia tego dobrze.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.