Dlaczego agenci kodujące wciąż mają trudności z kodem prywatnych firm
Real-SWE testuje osiem agentów kodujących na licencjonowanych, prywatnych bazach kodu. Najlepszy z nich rozwiązuje 38,8 procent zadań, a pięć klas niepowodzeń pokazuje, gdzie agenty popełniają błędy.
Źródła: Coding Agents Still Struggle With Private Company Code
Publiczne testy wydajności kodowania sprawdzają przydatne umiejętności, ale niewiele mówią o tym, co dzieje się w prywatnym kodzie produkcyjnym firmy. Test o nazwie Real-SWE próbuje zrealizować drugi rodzaj takich badań. Jego twórcy, mała firma z wsparciem Y Combinator o nazwie Specific Labs, uzyskali licencję na korzystanie z prywatnego kodu rzeczywistych firm, wybrali dziesięć zadań już ukończonych przez tamtejszych inżynierów i przekazali je ośmiu asystentom programistom. Najlepszy z nich osiągnął wynik 38,8 procenta.
Jedno z zadań rozpoczyna się od nagłej sytuacji z fakturami: faktury wydawane przez usługę zawierają zerowe podatki, a rozliczenia mają się wznowić w poniedziałek. Wśród wszystkich asystentów było sześćdziesiąt cztery próby rozwiązania tego problemu, z których dwie się udały. To zadanie nazywa się „Jurysdykcja podatkowa” i jest jednym z dziesięciu.
Dlaczego ten kod pozostaje ukryty
Założyciele opublikowali niedawno ten benchmark, który trafił na pierwszą stronę Hacker News z kilkuset punktami i ponad setką komentarzy. Real-SWE ocenia osiem kombinacji modeli i narzędzi w dziesięciu zadaniami, przy czym na każde zadanie przeprowadzanych jest osiem prób. Daje to 640 ocenionych prób, a końcowy wynik to odsetek prób, które zakończyły się sukcesem.
Projekty leżące u ich podstaw przypominają zwykłe oprogramowanie komercyjne: aplikację do zarządzania wydarzeniami z ponad 200 000 użytkownikami i miejscem w czołowej setce App Store, produkt fintechowy, który przetworzył już ponad 100 000 wyciągów bankowych, oraz platformę sprzedażową dla przedsiębiorstw. Agenaty korzystają z Dockera i Kubernetes, trzech baz danych (Postgres, MySQL, MongoDB), Redis, GitHuba oraz emulowanego chmury Amazon, choć każde zadanie udostępnia tylko te usługi, których potrzebuje jego własny proces pracy.
Część środowisk dodaje Slack, Intercom, Google Drive, ClickUp oraz serwer Linear MCP, który umożliwia agentowi czytanie zleceń bezpośrednio z Linear. Gdy jakiś szczegół nie trafił do zlecenia, agent musi go znaleźć w dyskusji lub dokumencie, tak jak zrobiłby to inżynier z tej samej drużyny.
Sama praca z podatkami odbywa się poprzez usługę NestJS napisaną w TypeScript, dwie instancje tej samej zewnętrznej instytucji podatkowej (system testowy oraz rzeczywisty system służący do składania deklaracji) oraz rejestr InfluxDB, w którym zapisywane są zakończone transakcje sprzedaży.
Zadania są zapisywane w formacie Harbor, a weryfikacja pozostaje ukryta aż do chwili oceny. Ma to na celu zmniejszenie szans na to, że agent dostosuje się do widocznego testu, a nie do rzeczywistych wymagań. Osoby sprawdzające pochodzą z zestawów testowych, które te firmy już prowadzą, w niektórych przypadkach dosłownie takich samych.
Autorzy wyjaśniają swój motyw niezwykłym twierdzeniem: że 99 procent tokenów w rzeczywistych przedsiębiorstwach jest ukrytych przed modelami Frontier. Ponieważ zadania te pochodzą z prywatnego oprogramowania, a nie z publicznych projektów na GitHubie, modele nie mogły zobaczyć kodu ani jego tajemnic podczas szkolenia.
Samych danych z benchmarku wynika, że średnia długość instrukcji wynosi 1 742 znaki, co jest mniej niż w przypadku FrontierCode (2 056) czy DeepSWE (1 975). Jednak w średnim przypadku rozwiązanie problemu wymaga modyfikacji 11 plików, podczas gdy w przypadku tych dwóch modeli wystarcza 6 plików.
Wyniki znacznie się różnią w zależności od zadania
Jedna ogólna ocena maskuje dwa zupełnie różne grupy zadań: te, które agenci rozwiązują raz po raz, oraz te, w których za każdym razem ponoszą porażkę. Rozwiązanie problemów typu multi-region sweep skutkowało sukcesem w 67,2 procent przypadków, API keys i środowiska – w 65,6 procent, linie z nadmiarem uprawnień – w 50 procentach, a migracja tożsamości klienta – w 40,6 procentach.
Sytuacja na końcu listy jest ponura. Stosunek podatkowy wynosi 3,1 procent, a czas skanowania liniowego – 4,7 procent; nieco wyżej są wyniki pomiarów z chmury S3 (10,9 procent), liczenia tokenów API (12,5 procent) oraz migracji harmonogramu fakturowania (14,1 procent). W przypadku narzędzia do redukcji strumieni analitycznych nikt nie osiągnął żadnego rezultatu: zero udanych prób przy sześćdziesięciu czterech testach.
Jeśli chodzi o stosunek podatkowy, dwa jedynie sukcesy odnotowano przy użyciu dwóch różnych modeli, a każdy z tych modeli ponosił porażkę przy realizacji tego samego zadania w pozostałych siedmiu próbach. W przypadku skanowania wieloregionalnego, który był najłatwiejszy, trzy modele odniosły sukces we wszystkich ośmiu próbach, podczas gdy dwa inne udało się tylko dwukrotnie. Średnia 67,2 procenta ukrywa grupę modeli, które nigdy nie poniosły porażki, oraz inną grupę, która prawie nigdy nie odnosiła sukcesu.
Jeden z autorów napisał na Hacker News, że niskie wskaźniki odzwierciedlają zadania „nad którymi prawdziwi inżynierowie pracowali tygodniami”.
Pełna lista rankingowa:
| Miejsce | Model i narzędzie |
|---|
Punktacja nie wyjaśnia porażki
Każda nieudana implementacja otrzymuje jedną z pięciu etykiet, zapożyczonych z taksonomii DeepSWE:
- Niepotwierdzone założenie. Zamiast sprawdzić środowisko pracy, agent zgaduje, jak będzie się zachowywał system.
Każdy procent opiera się na własnych nieudanych próbach modelu jako mianowniku.
Grok 4.6 miał 61 niepowodzeń, z których dwie trzecie (67,2 procenta) wynikały z niespełnienia wymagań. Gemini 3.8 Flash miał 55 takich przypadków, a 49,1 procent z nich to błędy integracyjne. Największą grupą problemów u GPT-5.6 Sol są niezweryfikowane założenia – 43,3 procent z 67 niepowodzeń – natomiast u Fable 5.1, który miał 49 niepowodzeń, problemy są rozłożone równomierniej: około 37 procent to niespełnione wymagania, a około 35 procent to błędy integracyjne.
Dwa modele, Grok 4.6 i Muse Spark 1.3, ukończyły poziom z wynikiem 23,8 procenta, ale miały różne problemy. U Groka dominują niespełnione wymagania, natomiast u Muse Spark – błędy integracyjne, które stanowią 41 procent przypadków. Regresje nigdy nie przekraczają 10,9 procenta i wynoszą zero w trzech z ośmiu konfiguracji. Kategoria błędów związanych z niewłaściwymi plikami występuje tylko dwa razy: u GLM 5.3 (7 procent) i Kimi K3 (3,1).
Należy zachować ostrożność. Etykiety zostały opublikowane, ale proces stojący za nimi nie jest wystarczająco szczegółowo opisany, by procenty te można było traktować jako ostateczne dowody. Opis publiczny nie jasno wskazuje, czy klasyfikację przeprowadzili ludzie-inżynierowie, model automatyczny czy połączenie obu tych metod.
Dłuższe testy nie były bardziej wiarygodne
Testy zostały również podzielone według czasu upływu. W ciągu dziesięciu minut 70 z 98 testów zakończyło się niepowodzeniem, co stanowi 71,4 procenta. Przy dziesięciu minutach lub więcej czasu 398 z 542 testów zakończyło się niepowodzeniem, co stanowi 73,4 procenta.
Użycie tokenów również przekazuje istotne informacje. Grok 4.6 osiąga średnio od 3 000 do 20 000 tokenów wyjściowych przy ośmiu z dziesięciu zadań, natomiast przy zadaniach o najniższych wynikach – skanowaniu liniowalnym i reduktorze strumienia analitycznego – generuje odpowiednio 261 000 i 315 000 tokenów. Wysokie użycie tokenów może być sygnałem ostrzegawczym, szczególnie gdy znacznie przewyższa normalną wartość bazową danego repozytorium. Gdy wynik wykonania jest kilka razy wyższy od oczekiwanego, należy przeanalizować przebieg procesu lub interweniować, zamiast pozwalać na marnowanie zasobów w zablokowanym procesie.
Najdroższy agent nie zawsze był najlepszy
Szacunkowy koszt jednej realizacji waha się od 2,50 dolarów (Gemini 3.8 Flash) do 6,96 dolarów (Fable 5.1), a kolejność cen prawie nie odpowiada rankingu liderów. GPT-5.6 Sol kosztuje 2,65 dolarów i plasuje się na ostatnim miejscu, podczas gdy najtańsza opcja, Gemini 3.8 Flash, zajmuje trzecie miejsce. Wszystkie te wartości to jedynie szacunki bazowe, a nie uniwersalny ranking cen, ponieważ rzeczywisty koszt zależy od cenników, ustawień, długości zadania, liczby prób i używanych narzędzi.
Fable 5.1 kosztuje 2,78 raza więcej niż Gemini 3.8 Flash i rozwiązuje problemy o 7,6 punktu procentowego skuteczniej. To, czy jest to opłacalne, zależy od kosztu nieudanego zadania. W tym kontekście niepowodzeniem może być błąd w fakturacji, obciążenie klienta, który powinien być zwolniony z opłat, lub dokumentacja, która nie zgadza się na końcu kwartału. W przypadku drobnych modyfikacji interfejsu kwoty wyglądają zupełnie inaczej.
Znaczna część tej różnicy wynika z ilości tokenów. GLM 5.3 osiąga średnio 117 000 tokenów wyjściowych na każdą sesję, natomiast GPT-6 Astra – 24 000, co stanowi prawie pięciokrotną różnicę przy tych samych dziesięciu zadaniach. Do tych dwóch wartości autorzy benchmarku dodają ostrzeżenia: Grok 4.6 w cenie 3,44 dolara oraz Kimi K3 w cenie 3,90 dolara nie zawierają pełnych danych dotyczących użycia, więc rzeczywisty koszt może być wyższy. Należy je traktować jako minimalne wartości.
To samo narzędzie, siedemnaście punktów różnicy
Każdy model jest sparowany z narzędziami dostarczanymi przez jego producenta, dlatego benchmark opisuje oceniane kombinacje jako „kombinacje modelu i narzędzi, a nie modele w izolacji”. Dwa narzędzia pojawiają się jednak dwukrotnie, co umożliwia przybliżone porównanie. Z użyciem Codex CLI GPT-6 Astra osiąga wynik 33,8 %, podczas gdy GPT-5.6 Sol – 16,2 %, co daje różnicę 17,6 punktu. Z użyciem Claude Code Fable 5.1 osiąga wynik 38,8 %, a GLM 5.3 – 28,8 %, czyli różnicę dziesięciu punktów.
Mimo to te dziesięć zadań i osiem konfiguracji dają małą tablicę ocen, a każda ocena ma podany przedział ufności. Każdy model został przetestowany 80 razy, więc 38,8 procent u Fable 5.1 odpowiada 31 próbom, a 16,2 procent u GPT-5.6 Sol – 13 próbom. Jeśli dla jednego modelu wynik jednego zadań się zmieni, jego ocena zmienia się o kilka punktów. Nikt nie powinien wybierać dostawcy na podstawie tak małej tablicy ocen, a autorzy też o to nie proszą. To badanie pokazuje, że publiczne oceny mogą być niepełnym przewodnikiem dotyczącym wydajności w prywatnym kodzie, i do tego rozróżnienia przypisuje pięć praktycznych kategorii niepowodzeń.
Zastosuj pięć tagów we własnym kodzie
Taksonomia to element, który można przenieść. Możesz ją zastosować we własnym repozytorium w dowolnym momencie.
Weź ostatnie dwadzieścia prośb o integrację, które otworzył agent, i przypisz każdej z tych, które zawiodły lub zostały mocno zmodyfikowane, jedną z pięciu klas. Zlicz je. To rozkład jest wynikiem badania i nie będzie odpowiadał żadnemu modelowi, o którym czytałeś w tym tygodniu, ponieważ zależy on zarówno od twojej bazy kodu i nawyków pisania zgłoszeń, jak i od modelu. Klasa, która okaże się najliczniejsza, podlega blokadzie.
Jeśli dominują niezweryfikowane założenia, konieczny jest dziennik przeglądania. Poproś agenta o zapisanie, jakie pliki otworzył przed wprowadzeniem jakichkolwiek zmian, i odrzuć tę zmianę, jeśli lista nie zawiera pliku, w którym znajduje się dane zachowanie. Zaniedbane wymagania zazwyczaj wynikają z odpowiedniego ticketu. Przekształć instrukcję w listę kryteriów przyjęcia i sprawdzaj je pojedynczo, ponieważ instrukcja zawierająca pięć wymagań ukrytych w długim akapicie jest przyczyną 67,2 procent przypadków błędów u Groka. Błędy integracyjne oznaczają, że testy przechodzą na poziomie jednostkowym, ale zawalają się w łańcuchu wywołań, dlatego testuj ścieżkę, którą podąża aplikacja w trybie rzeczywistym, zaczynając od jej punktu wejścia. Błędy wynikające z niewłaściwego pliku występują tak rzadko, że każdy taki przypadek wymaga dalszego sprawdzenia: upewnij się, że do każdego zmodyfikowanego pliku można dotrzeć z kodu, który aplikacja faktycznie wywołuje.
Od tego momentu należy śledzić jeden wskaźnik: udział prośb o zmianę (pull request) wysłanych przez agenta, które przechodzą weryfikację od razu przy pierwszej próbie, podzielony według kategorii niepowodzeń. Zmienia się on, gdy zasady weryfikacji stają się bardziej restrykcyjne, a także wtedy, gdy zmienia się model leżący u ich podstaw.