JetBrains opublikował pierwszy benchmark paired-delta porównujący narzędzia wyszukiwania IDE-native z narzędziami shell (grep, find) dla agentów kodujących AI. Podejście jest metodycznie poprawne: te same zadania, te same modele, narzędziownia włączona vs wyłączona, porównanie zadanie po zadaniu z istotnością p<0.05. Wyniki są prawdziwe. Konflikt interesów też.
Na Codex 5.2, głównym modelu testowym, wyszukiwanie IDE-native zredukowało P95 opóźnienia o 16.44%, z 268.71 sekund do 213.17 sekund. Mediana opóźnienia spadła o 8.33% (83.11s do 79.03s). Całkowity koszt spadł o 5.60%, z 44.17 USD do 41.67 USD. Przekroczenia budżetu, czyli zadania przekraczające limit 0.50 USD, spadły z 6.67% do 4.44%, redukcja o 33.28%. To nie są średnie wybrane pod tezę. Poprawa P95 oznacza, że najgorsze zadania stały się szybsze, nie tylko typowe.
Policzyłem kroki wyszukiwania w trasach: ponad 12 ślepych wywołań bez IDE wobec 3 ukierunkowanych z IDE. Zadanie oznaczone "Update service and controller layers for comments and replies" zajęło 472 sekundy bez wyszukiwania IDE. Agent wykonał 12+ kroków wyszukiwania i eksploracji: list files, grep, jar inspect, javap, curl download, decompile, zanim znalazł właściwy kod. Z wyszukiwaniem IDE-native to samo zadanie zajęło 127 sekund. Trzy wywołania wyszukiwania, gotowe.
Inna trasa pokazuje zadanie deserializatora Jacksona spadające z 150 sekund do 34 sekund. Wzorzec jest spójny: agenci z narzędziami shell tracą kroki na ślepe odkrywanie. Wyszukiwanie IDE-native kieruje je od razu do właściwych plików.
Wyniki cross-model dodają wiarygodności. GPT 5.4 na Kotlinie zanotował 13.48% redukcji całkowitych kosztów, największą poprawę kosztową wśród wszystkich par model-język. W Javie GPT 5.4 nadal poprawił wynik o 4.07%. Jednakże P95 opóźnienia na Kotlinie nie było statystycznie istotne, co oznacza, że zyski koncentrują się w typowym przypadku, a najgorsze przypadki pozostają bez zmian.
Oto szczera część. JetBrains informuje, że nie ma statystycznie istotnej zmiany jakości. Wyszukiwanie IDE-native nie sprawia, że agenci piszą lepszy kod. Sprawia, że znajdują kod szybciej i wydają mniej tokenów. Efektywność, nie poprawność.
Problem dostawcy jest nie do uniknięcia. JetBrains zaprojektował zadania ewaluacyjne, wybrał modele i przeprowadził benchmarki na własnym produkcie. Zadania pochodzą z wewnętrznego zestawu testowego JetBrains, mocno przechylonego w stronę Javy i Kotlina, języków, w których model projektu IntelliJ jest najgłębszy. Python, TypeScript i .NET są ujęte jako "planowane", ale nieprzetestowane. Zadania ewaluacyjne również faworyzują scenariusze wyszukiwania strukturalnego (aktualizacje service/controller, deserializatory Jacksona), które sprzyjają narzędziom IDE-native bardziej niż grepowi. Brakuje zadań wymagających wyszukiwania w sieci lub analizy cross-repo.
Wskaźniki adopcji pokazują wyraźne różnice: Codex używał IDE-native przy 91% wywołań, Claude Opus używał go w 53% przypadków. Claude Haiku tylko w 28%, preferując grep i find. Modele z silnymi wbudowanymi możliwościami wyszukiwania korzystają mniej z narzędzi IDE, co sugeruje malejące zwroty dla już zdolnych modeli.
Metodologia jest transparentna. Niezależne badanie MorphLLM wykazało, że dla agentów kodujących rusztowanie ma większe znaczenie niż model, co zgadza się z wnioskiem JetBrains, że narzędzia zmieniają wydajność niezależnie od wyboru modelu. JetBrains raportuje wyniki zerowe. Istotność statystyczna jest testowana. Warianty konfiguracji są otwarcie porównywane: wariant "4 Search Tools" miał najniższy koszt (40.53 USD), ale JetBrains wybrał "Unified Tool + Router" dla najlepszej latencji (79.03s), wymieniając marginalne oszczędności na szybkość. Do obrony przy interaktywnych sesjach, ale JetBrains nadal wybiera zwycięzcę z własnego wyścigu.
Liczby są prawdziwe. Metoda jest rygorystyczna. Ale JetBrains jest zarówno sędzią, jak i biegaczem. Poczekaj na niezależną replikację na TypeScripcie i Pythonie, zanim przebudujesz swój pipeline agentów wokół wyszukiwania IDE-native.