A Netflix szerint hatékonyabbá tehetők a kódoló AI-ügynökök

A Java- és Kotlin-kód navigálása okozta a nehézséget

A Netflix, a JetBrains és a vállalat alkalmazásfejlesztési, generatív AI- és ügynökalapú fejlesztési életciklussal foglalkozó csapatai azt vizsgálták, hogyan lehet pontosabbá tenni a kódoló ügynökök munkáját fej nélküli környezetben. Ilyenkor nincs megnyitva IntelliJ IDEA, az ügynök mégis hozzáférhet a fejlesztőkörnyezet kódértelmezési képességeihez.

A probléma különösen a Java- és Kotlin-projekteknél jelentős. A JVM-es projektek könyvtárai gyakran csak JAR-fájl formájában érhetők el, forráskód nélkül. Az ügynököknek ilyenkor ki kell találniuk, melyik fájl lehet fontos, ki kell csomagolniuk a JAR-t, esetleg vissza kell fejteniük az osztályfájlokat, majd egy hiányos kódnézetben kell keresniük.

A JetBrains megoldása az IntelliJ IDEA kódindexelő motorjára épül. Ez a projekt forrásfájljairól és a könyvtárakról is determinisztikus indexet készít, amelyet egy nyelvi szerverprotokollon, LSP-n keresztül lehet elérni.

A Netflix saját háttérfolyamattal tartotta melegen az indexet

Az LSP önmagában nem adott egyszerű módot arra, hogy egy kódoló ügynök meghívja a szolgáltatást, és a folyamatok kezelését sem oldotta meg. A Netflix ezért démont és parancssori felületet épített hozzá. A JetBrains a közlemény szerint dolgozik saját démonon, de az értékelés idején ilyen megoldás még nem állt rendelkezésre.

Az index elkészítése időt vesz igénybe, ezért minden új LSP-folyamat indítása több másodperces hidegindítást jelentett volna. A Netflix démonja projektenként kezeli a munkameneteket, és memóriában tartja a hozzájuk tartozó indexet. Ugyanazon projekt következő hívása így kihagyhatja az indexelést, és közvetlenül a már futó szerverhez kapcsolódik.

A démont és a parancssori eszközt Java nyelven fejlesztették, GraalVM-fájlként terjesztik, így a forrás szerint nem jár JVM-es indítási vagy futásidejű többlettel.

Valós kódalapokon hasonlították össze az ügynököket

A Netflix a vizsgálatot 2026 júliusában és augusztusában végezte két valódi kódalapon. Az egyik egy közepes méretű, Spring Boot 4-et és Gradle-t használó belső szolgáltatás volt, a másik a Netflix nyílt forráskódú DGS Frameworkje, amely Kotlin- és Java-kódot is tartalmaz.

A tesztekben kisebb navigációs feladatokat és teljes folyamatokat is vizsgáltak. Az előbbiek között szerepelt egy interfész használati helyeinek vagy implementációinak megkeresése, illetve egy osztály szerkezetének feltérképezése. A teljes feladatok új funkciók megvalósítását, osztályok átalakítását és kód eltávolítását tartalmazták.

A Claude Code Opus 5, a Claude Code Sonnet 5 és a Codex GPT-5.6 Sol modellel futott. Minden összehasonlításban ugyanaz a modell, feladat és kódalap szerepelt, az egyetlen változó az volt, hogy az ügynök használhatta-e a JetBrains kódértelmezését.

Kevesebb token, rövidebb futási idő

A JetBrains szerint minden vizsgált modellnél, ügynöknél és feladattípusnál javult a hatékonyság. A tipikus eredmény 20, 30 százalék közötti javulás volt, a legjobb esetben pedig körülbelül 65 százalékot mértek. A nyereség a tokenfelhasználás és a befejezésig eltelt idő megtakarítását együttesen tükrözte.

A legerősebb modellek magas erőfeszítési beállítás mellett érték el a legnagyobb javulást. A kódnavigációs feladatokban minden vizsgált modell kevesebb tokent használt, a megtakarítás nagyjából 15 és 60 százalék között mozgott. A helyesség a legtöbb futásban változatlan maradt, két esetben javult, és egyszer sem romlott.

A JetBrains hangsúlyozza, hogy az adatok pillanatfelvételnek számítanak. Az új modellverziók módosíthatják, hogyan keresnek, következtetnek és használják az eszközöket az ügynökök, ezért a százalékos értékek idővel változhatnak.