JetBrains: IDE-Native Search przyspiesza agentów AI i obniża koszty
Dlaczego ten temat jest ważny
W świecie narzędzi AI dla programistów często skupiamy się głównie na samym modelu. W tym przypadku zainteresowało nas jednak coś innego: czy agent AI może działać lepiej nie dlatego, że dostał „mądrzejszy” model, ale dlatego, że dostał lepszy dostęp do kodu i struktury projektu przez IDE. Właśnie to postanowił sprawdzić JetBrains.
Od czego wychodził problem
JetBrains zwrócił uwagę na bardzo praktyczny problem. Gdy agenci AI przeszukują projekt, często korzystają z narzędzi takich jak grep i find. To rozwiązania skuteczne, ale nie rozumieją semantyki języka, granic symboli ani struktury projektu. W efekcie agent musi wykonywać więcej kroków, przetwarzać więcej szumu i zużywać więcej tokenów, zanim dotrze do właściwego miejsca w kodzie.
Co dokładnie zostało zbudowane
W eksperymencie wykorzystano prebundlowany skill, czyli gotowy zestaw zachowań agenta, połączony z jednym zunifikowanym narzędziem MCP do wyszukiwania. To narzędzie obsługiwało cztery tryby: wyszukiwanie plików, tekstu, wyrażeń regularnych oraz symboli. Dodatkowo działał uniwersalny router, który kierował zapytania do odpowiedniego backendu. Dzięki temu agent nie musiał sam zgadywać, jakiego rodzaju wyszukiwania powinien użyć.
Co daje wyszukiwanie natywne dla IDE
Najważniejsza przewaga tego podejścia polega na tym, że narzędzia natywne dla IDE mogą korzystać z indeksów projektu, AST i modeli projektu. Tego klasyczne narzędzia shellowe po prostu nie widzą. W praktyce oznacza to szybsze dotarcie do właściwych fragmentów kodu i mniej zbędnych kroków po drodze.
Jak wyglądała metodologia testu
JetBrains uruchamiał MCP server obok IDE, aby agent miał dostęp do odpowiednio skonfigurowanych narzędzi i skilli. Następnie porównywano identyczne zadania programistyczne wykonywane z takim toolingiem i bez niego. Wyniki analizowano metodą paired delta analysis, a poprawę raportowano tylko wtedy, gdy spełniony był próg istotności statystycznej p < 0,05 przy 95% przedziałach ufności.
Jakie wskaźniki były mierzone
W badaniu śledzono cztery główne obszary. Pierwszym była jakość, rozumiana jako odsetek zadań, w których wszystkie testy przechodziły poprawnie. Drugim było opóźnienie, mierzone medianą i P95 czasu wykonania. Trzecim był koszt, liczony przez przeliczenie zużycia tokenów na dolary. Czwartym była dyscyplina budżetowa, czyli to, jak często pojedyncze zadanie przekraczało limit 0,50 USD.
Jaką konfigurację uznano za najlepszą
Zanim wybrano finalne rozwiązanie, przetestowano cztery warianty konfiguracji. Ostatecznie wybrano zestaw składający się z prebundlowanego search skilla, zunifikowanego narzędzia IDE-native search oraz uniwersalnego routera. To właśnie ten wariant dał najlepszy kompromis między opóźnieniem a kosztem.
Jakie były główne wyniki
Najważniejsze dane są bardzo konkretne. W porównaniu z baseline’em bez dodatkowego toolingu mediana czasu wykonania zadania spadła o 8,33%, z 83,11 s do 79,03 s. P95 latency spadło o 16,44%, z 268,71 s do 213,17 s. Łączny koszt zmniejszył się o 5,60%, z 44,17 USD do 41,67 USD. Udział zadań przekraczających budżet 0,50 USD spadł o 33,28%, z 6,67% do 4,44%. Jednocześnie JetBrains podkreślił, że nie odnotowano statystycznie istotnej zmiany jakości.
Co te liczby znaczą w praktyce
Z naszej perspektywy to bardzo istotny wniosek. Nie mówimy tutaj o kosmetycznej zmianie, ale o realnym skróceniu czasu działania agenta i ograniczeniu kosztów jego pracy. Szczególnie mocno wygląda spadek P95 latency i liczby przekroczeń budżetu, bo to właśnie te wskaźniki najlepiej pokazują, czy narzędzie jest przewidywalne i opłacalne przy większej liczbie zadań. Dane JetBrains wskazują, że IDE-native search poprawia właśnie te praktyczne aspekty pracy agenta.
Jak zmienia się ścieżka pracy agenta
JetBrains pokazał też skrócone trace’y zadań, w których różnica była wyraźna. W wariancie bazowym agent długo „szukał kontekstu”: listował pliki, wykonywał kolejne wyszukiwania, inspekcje JAR-ów, dekompilację i czytał wiele plików, zanim przeszedł do właściwej zmiany. W wariancie z prebundlowanym skill’em i zunifikowanym wyszukiwaniem szybciej trafiał do istotnych plików i wykonywał mniej zbędnych operacji. W jednym pokazanym przypadku czas zadania spadł z 472 s do 127 s, a w innym ze 150 s do 34 s.
Czy efekt utrzymał się na innych modelach
JetBrains nie zatrzymał się na jednym przebiegu testowym. Eksperyment został ponownie uruchomiony z GPT 5.4 na codebase’ach Java i Kotlin. W Javie mediana opóźnienia spadła o 3,75%, całkowity koszt o 4,07%, a P95 o 13,00%. W Kotlinie mediana opóźnienia spadła o 6,92%, a całkowity koszt aż o 13,48%; w tym przypadku zmiana P95 nie była statystycznie istotna. To pokazuje, że efekt nie ograniczał się do jednego modelu i jednego zestawu zadań.
Jak różne modele korzystały z nowego narzędzia
Bardzo ciekawe są też dane o adopcji toolingu. Codex kierował 91% swoich zapytań wyszukiwawczych przez nowe narzędzie IDE-native search. Claude Opus korzystał z niego przy około połowie wyszukiwań, a Claude Haiku tylko w 28% przypadków, częściej pozostając przy grep i find. JetBrains interpretuje to w prosty sposób: tam, gdzie model ma już mocne własne mechanizmy wyszukiwania, zysk z dodatkowego toolingu może być mniejszy. Tam, gdzie search jest słabszy, różnica robi się naprawdę odczuwalna.
Co z tego wynika dla ekosystemu JetBrains
Dla nas to ważny sygnał, że przyszłość AI w IDE nie zależy wyłącznie od coraz lepszych modeli. Równie istotne staje się to, jak głęboko agent jest osadzony w środowisku programistycznym i jak dobrze potrafi korzystać z kontekstu projektu. W praktyce wzmacnia to rolę IDE jako aktywnego źródła wiedzy o kodzie, a nie tylko jako miejsca, w którym wyświetlają się sugestie AI. Właśnie w tym kierunku JetBrains rozwija swój ekosystem AI.
Co JetBrains planuje dalej
Firma zapowiada dalsze testy na mniejszych modelach, bo według jej założenia to właśnie one mogą zyskać jeszcze więcej dzięki lepszemu wyszukiwaniu. Zakres badań ma też zostać rozszerzony na Python, .NET i TypeScript. Równolegle zwycięska konfiguracja jest przygotowywana do zintegrowanego IntelliJ IDEA MCP Server, a kolejnym krokiem ma być domyślne włączenie tej funkcji w przyszłych aktualizacjach AI Assistant plugin.
Jak można przetestować to wcześniej
JetBrains podał także wersję eksperymentalną dla osób, które chcą sprawdzić rozwiązanie przed domyślnym rolloutem. Wymaga ona ustawienia na true trzech registry keys: llm.chat.agent.codex.mcp.idea, llm.chat.agent.skills.settings.enabled oraz llm.agents.contrib.bundled.skills.sync.enabled. Firma rekomenduje też wybór Codex w AI Assistant, bo to właśnie ten model najlepiej wykorzystywał nowy tooling w przeprowadzonych testach.
Nasz wniosek
Po przejrzeniu tego eksperymentu wniosek wydaje nam się jasny: gdy agent AI dostaje dostęp do wyszukiwania natywnie osadzonego w IDE, może działać szybciej, taniej i bardziej przewidywalnie, bez utraty jakości potwierdzonej testami. Dla użytkowników JetBrains AI to nie jest drobna ciekawostka, ale bardzo konkretny kierunek rozwoju narzędzi AI w IDE.
Poznaj całą gamę produktów JetBrains tutaj!
https://cswiat.pl/jetbrains/comparison/
Zakup wygodnie to co chcesz poniżej!