Agenci AI nie widzą lasu przez drzewa w debugowaniu

Wyobraź sobie lekarza, który trafia do właściwego szpitala, ale nie potrafi znaleźć sali operacyjnej. Podobnie działają współczesne agenty AI wspomagające programistów – doskonale lokalizują plik z błędem, ale rzadko wskazują konkretne linie kodu, które wymagają zmiany. Nowe badanie międzynarodowego zespołu naukowców rzuca światło na tę ukrytą słabość i podważa dotychczasowe sposoby oceny sztucznej inteligencji w programowaniu.

Dlaczego wskaźnik napraw nie mówi całej prawdy

Do tej pory skuteczność agentów AI w debugowaniu mierzono głównie jednym parametrem: czy udało im się naprawić zgłoszony błąd, czy nie. Problem w tym, że wynik „tak” lub „nie” maskuje całą masę szczegółów. Agent mógł nigdy nie przeczytać odpowiedniego kodu, mógł trafić we właściwy plik, a mimo to napisać błędną łatkę – w obu przypadkach rezultat wygląda identycznie.

Zespół badawczy z Shanghai Jiao Tong University oraz innych instytucji postanowił zmierzyć się z tą ślepą plamą. Stworzyli benchmark o nazwie SWE-Explore, który ocenia tylko pierwszą fazę procesu: wyszukiwanie odpowiedniego fragmentu kodu. Agent dostaje opis błędu oraz cały projekt programistyczny, a następnie zwraca uszeregowaną listę sekcji kodu, które jego zdaniem są istotne. Dopiero drugi krok – faktyczna naprawa – podlega oddzielnej ocenie.

Jak naukowcy wyznaczyli „złote” linie kodu

Ręczne określenie, które fragmenty kodu są krytyczne dla naprawy błędu, jest praktycznie niemożliwe przy setkach przykładowych zadań. Dlatego badacze zastosowali sprytną metodę. Dla każdego z 848 problemów w zbiorze danych mieli co najmniej dwie udane próby naprawy wykonane przez potężne modele, takie jak GPT-5.4, Gemini 3 Pro, Claude Sonnet 4.6 czy Kimi K2.6. Następnie prześledzili, które pliki i linie te modele faktycznie analizowały przed naprawą. Fragmenty, do których zbiegały się niezależne ścieżki rozwiązań, uznano za sygnał użytecznego kontekstu. Całość zweryfikowano ręcznie.

Kluczowe wyniki: dobra lokalizacja pliku, słaba precyzja linii

Testy objęły 203 projekty open source w dziesięciu językach programowania. Python dominował (547 zadań na 848), a reszta to między innymi Go, JavaScript i Rust. Badacze porównali tradycyjne metody wyszukiwania (np. wyszukiwanie słów kluczowych) z pięcioma ogólnymi agentami kodującymi (Claude Code, Codex, OpenHands) oraz czterema systemami badawczymi stworzonymi specjalnie do lokalizacji kodu.

Wnioski są zaskakujące. Wyszukiwanie słów kluczowych ledwo przewyższało losowy wybór. Agenci AI radzili sobie znacznie lepiej, ponieważ przeszukują projekt krok po kroku, zamiast sortować wszystkie trafienia naraz. Jednak przy przejściu z poziomu plików na poziom pojedynczych linii kodu wyniki dramatycznie spadają.

Pokrycie linii kodu na poziomie 14–19%

Ogólne agenty kodujące trafiały zaledwie na 14 do 19 procent linii, które faktycznie miały znaczenie dla naprawy. Innymi słowy: agent znajduje właściwy plik, umieszcza go wysoko w rankingu, ale gdy pytamy o konkretne linie, jego trafność jest mizerna. Co gorsza, zastąpienie słabszego modelu silniejszym nie rozwiązuje problemu. Ten sam agent uruchomiony na sześciu różnych modelach od OpenAI, Anthropic, Google, Moonshot i Zhipu dawał podobne wyniki – wskaźnik trafień plików pozostawał wysoki, ale pokrycie linii było stale niskie.

Co ciekawe, różne architektury agentów radziły sobie bardzo podobnie. Claude Code, Codex, OpenHands, Mini-SWE-Agent i AweAgent osiągnęły niemal identyczne wyniki. Wyjątkiem był system CoSIL, który skanuje kod jako sieć połączonych bloków i uzyskał znacznie wyższe pokrycie linii. Wśród wyspecjalizowanych systemów lokalizacji AutoCodeRover działał precyzyjnie, ale zachowawczo, a OrcaLoca generował mało szumu, ale pomijał wiele istotnych miejsc.

Próg efektywności: połowa kontekstu to minimum

Naukowcy przeprowadzili też kontrolowany eksperyment, w którym sztucznie zmieniali ilość kontekstu widzianego przez model naprawiający. Pokazywali mu 0, 25, 50, 75 lub 100 procent krytycznych regionów, czasem dokładając nieistotny kod. Efekt był wyraźny: dla łatwiejszych zadań, dopóki model widział mniej niż połowę kluczowych fragmentów, naprawy przeważnie kończyły się niepowodzeniem. Sukces gwałtownie rósł dopiero między 50 a 75 procentami pokrycia. Dla trudniejszych zadań efekt był słabszy – jeśli problem przekraczał możliwości modelu, nawet lepszy kontekst nie pomagał.

Brak kontekstu szkodził bardziej niż dodanie nieistotnego kodu. Gdy krytyczne fragmenty były dostępne, dodatkowy „śmieciowy” kod prawie nie przeszkadzał. Wniosek dla przyszłych rozwiązań jest prosty: filtruj mniej, czytaj więcej.

Kod i dane benchmarku SWE-Explore są dostępne na GitHub i Hugging Face. To kolejny głos w dyskusji o realnej skuteczności agentów AI. Przypomnijmy, że około dwa lata temu powstał SWE-bench – benchmark testujący agentów na prawdziwych zgłoszeniach błędów z GitHub. Od tego czasu pojawiły się jego liczne warianty. Jednak ostatnio badanie organizacji METR wykazało, że menedżerowie projektów odrzuciliby około połowy rozwiązań, które automatyczny recenzent zaakceptował – głównie z powodu podstawowych błędów funkcjonalnych.

SWE-Explore pokazuje, że sam wynik naprawy to za mało. Liczy się też to, jak agent do niego doszedł – a to właśnie wyszukiwanie jest najsłabszym ogniwem. Jeśli agenty AI mają realnie wspomóc programistów, muszą nauczyć się widzieć nie tylko las, ale i każde drzewo z osobna.