Replit, Kilo Code és Symbotic technikai vezetői szerint az ügynökalapú (agentic) mesterséges intelligencia egyre mélyebben beépül a vállalati fejlesztési folyamatokba — ez gyors hatékonyságnövekedést hoz, de új kérdéseket is felvet a biztonság, költség- és működésmenedzsment, valamint a többmodell-architektúrák támogatása körül. A VB Transform 2026 konferencián elhangzott tapasztalatok szerint a cégek különböző megközelítéseket alkalmaznak a kockázatkezelésre, a modellek választására és a költségek kordában tartására.
Mennyire agentikus a fejlesztés? Ki csinál kódot?
Kilo Code társalapítója, Emilie Schario elmondta, hogy mérésük szerint a mérnökök ma már csupán körülbelül 1%-ban olvasnak vagy írnak közvetlenül kódot — a többit ügynökök végzik. Ez a változás új feladatokat ad a fejlesztőcsapatoknak: mely rendszereket érdemes átadni az ügynököknek, ki vállalja a takarítást, ha a modellek hibáznak, és hogyan lehet támogatni a több modellből álló rendszereket.
Zöldmező vs. barna mező: hol erős az AI?
Jared Go, a Symbotic (raktári automatizálással foglalkozó vállalat) AI és felhő területért felelős elismert mérnöke azt hangsúlyozta, hogy az ügynökök különösen jól teljesítenek zöldmezős (greenfield) projektekben — új kódalapok létrehozásában. A barna mezős (brownfield), azaz meglévő rendszerekhez való hozzáírás, frissítés és karbantartás sokkal nagyobb kihívást jelent, és ott továbbra is szükség van emberi döntésekre a termékirányításban.
Replit: "human on the loop" és kockázatos PR-ek kezelése
Replitnél más a megközelítés: Amol Jain, a vállalat produktmérnökségi vezetője szerint a cég „nagyon agentikus” irányba ment, de óvatos a kódgenerálásnál. Replit belső eszköze minden pull requestet (PR) ügynökök révén értékel, majd kockázati pontszámot rendel hozzá. Az alacsony kockázatú PR-eket a szerző maga automatikusan merge-eli, a magasabb kockázatúakat emberi reviewer olvassa át és ad visszajelzést. Jain fogalmazása szerint céljuk a „human on the loop, nem human in the loop” modell: az ügynökök végzik az end-to-end tervezést, implementációt és tesztelést, egy flottnyi, saját felhő-VMon futó ügynök segítségével, hozzáférés- és tokenvezérelt biztonsággal.
Egy gyakorlati példa: egy nehezen reprodukálható, mély rendszerhibát egy AI manager ügynök kapott; a manager több al-ügynököt indított, amelyek először feltárták a hibát, majd további ügynökök találták meg a javítást — hat órával később már készen volt egy PR, amelyet a modellek generáltak.
Többmodell-stratégia: a zártság oldódik
A szolgáltatók és ügyfelek egyre inkább elmozdulnak a lock-in modellektől a többmodell-választás felé. Kilo Code_gateway-je több mint 500 modellt támogat, mondta Schario: a fejlesztőeszköznek el kellene választania a használt szoftvert és a mögöttes modellt. Gyakori gyakorlat például, hogy drágább, frontier-szintű modelleket használnak az architektúra és tervezés kezdeti fázisában, majd áttérnek olcsóbb, open-weight modellekre a kivitelezéshez.
Fontos továbbá figyelembe venni a modellszolgáltatók korlátait: egyes modelleket zárt vagy izolált környezetben kell futtatni, vagy régióspecifikus követelmények miatt vannak korlátozások. Az irányítási döntésekbe be kell építeni, hogy mi a szervezet számára fontos: adatreteníciós szabályok, kulcsok kezelése, commitok jellege stb., tette hozzá Schario.
Replit szerint is gyakran ők döntik el, melyik modellt használják mikor, hogy minimalizálják a költséget és maximalizálják a képességet — mivel a cég jobban látja a költség-képesség arányt, mint egyes felhasználói.
Tokenköltségek, tokenmaxxing és költségkontroll
A gyorsan növekvő tokenköltségek komoly kérdésként jelennek meg: egyes cégeknél bevezettek tokenmaxxinget (felhasználási korlátokat) és havi költségsávokat. Schario szerint mind belsőleg, mind ügyféloldalon hallanak aggodalmakat: ügyfelek előforduló panasza, hogy „véletlenül ellőttem az egész éves AI-költségvetést”. Kilo Code ajánlása: drága modelleket használni tervezésre, aztán olcsóbb modelleket a megvalósításhoz.
Schario hangsúlyozta a képességmegosztás, erős útmutatások és a Model Context Protocol (MCP) fontosságát, mert ezek révén a csapatok jobban kihasználhatják a modelleket. Ő jelenleg a „költség per pull request” mutatót nézi: ez szerinte közeli közelségben méri az értéket, mert a költés önmagában nem probléma — a baj, ha nincs megtérülés.
Symboticnál Jared Go elmondta, hogy havi költségsávokat állapítottak meg dolgozóinak, és egy belső eszköz mutatja a menedzsereknek a PR-okat és felhasználási trendeket, lehetővé téve, hogy szükség szerint áthelyezzenek felhasználókat más szintre. Amikor Cursor megszüntette a régi kedvezményt és mindenkit a teljes árazásra állított át — még a frontier modellekre is —, a cég kénytelen volt hatékonysági átalakulást végrehajtani.
Replitnél is előfordult, hogy a költségprobléma kikerült az IT irányítása alól: az ügynököket a mérnökökön túlra is kiterjesztették, és kiderült, hogy egy ügyfélszolgálati felhasználó óriási összeget költött, mert egy automatizációt GPT 5.5 Pro Max-szal futtatott. Jain szerint addig a pontig a megtérülés egyértelmű volt — 3X-es mérnöki produktivitást láttak, így nem kérdőjeleződött meg a költés.
Működési következtetések: láthatóság, model routing és alapbeállítások
Mindhárom cég tapasztalata szerint kritikus a költségek és használat láthatóvá tétele anélkül, hogy az "anti-produktív" lenne: azaz ne akadályozza a munkát, de jelezze a pazarlást. A model routing (melyik modell mikor fusson), ésszerű alapbeállítások és a többmodell-támogatás alapvető elemei annak, hogy a szervezetek a legtöbbet hozzák ki az agentic AI-ból anélkül, hogy a költségek elszabadulnának.
A kulcskérdések továbbra is: melyik munkát adjuk át az ügynököknek, hogyan biztosítjuk a biztonságot és megfelelőséget, ki viseli a felelősséget a modellek hibáiért, és miként mérjük a valódi megtérülést az új munkamódszerekre építve.
Mikor történt mindez?
A megjegyzések és példák a VB Transform 2026 rendezvény egyik beszélgetésén hangzottak el, ahol a Replit, Kilo Code és Symbotic képviselői osztották meg gyakorlati tapasztalataikat és irányelveiket.
