A három kar, amit senki sem húz meg – avagy miért bukik el a kódagented

Légy őszinte magaddal egy pillanatra. Valószínűleg kipróbáltál már egy kódagentet, megnézted, ahogy ír egy-két függvényt, és azt gondoltad: "Hm, ez jó." Aztán megpróbáltad komoly feladatra használni – valamire, ami tényleg számít –, és falba ütköztél.

Lehet, hogy olyan API-kat hallucinált, amik nem léteznek. Lehet, hogy javított egy hibát, miközben három másikat elrontott. Vagy egyszerűen csak ült ott, pörgött a kurzor, és várt, hogy magyarázd el neki, mit is akarsz pontosan. Ismerős?

Íme a kellemetlen igazság: az agented nem romlott el. Csak rosszul használod.

Pontosabban: valószínűleg egyetlen kart mozgatsz meg, miközben három áll rendelkezésedre.

A három kar, amiről senki sem beszél

Minden kódagent – legyen szó Claude Code-ról, Cursorról, Copilotról vagy bármi másról – ugyanarra az alaplogikára épül. Kap információt, csinál vele valamit, majd visszajelzést kap. Ennyi. Ennyi az egész gépezet.

De itt rontja el a legtöbb ember: egyik vagy két kart optimalizálja, a harmadikat teljesen figyelmen kívül hagyja. És élesben, éles projektekben pont ez a hiányzó kar válik a plafonná.

Nézzük meg, mit jelent ez a gyakorlatban.

LÁTÁS: Mit tud valójában az agented?

Kicsomagolva az agented csak a kódodat és a shellt látja. Ennyi. Nem ismeri a csapatod kódolási standardjait. Nem tud arról a furcsa megoldásról, amit a senior mérnökötök adott hozzá három éve egy örökölt integrációhoz. Nem tudja, hogy mi számít "készennek" a projektetekben.

Amikor csapatokkal beszélek, akik küzdenek az AI-támogatott fejlesztéssel, a probléma szinte mindig a kontextus. Az agent vakon repül. Olyan kódot ír, ami technikailag működik, de nem illeszkedik a kódbázisotok mintázataihoz, figyelmen kívül hagyja az elnevezési konvenciókat, vagy újra feltalálja a kereket, amit a csapatotok már megoldott.

A javítás? Csomagold a kontextust úgy, mintha egy új junior fejlesztőnek adnál át munkát. Mely fájlokat olvassa el először? Mely konvenciók fontosak? Hogy néz ki az architektúrátok? A legtöbb eszköz kínál lehetőséget ennek beinjektálására – rendszerpromptok, dokumentációs hivatkozások, skill fájlok. Használd őket.

** CSELEKVÉS: Mit tud valójában csinálni az agented?**

Itt válik igazán érdekessé a dolog. Egy alap agent tud fájlokat szerkeszteni és teszteket futtatni. Egy konfigurált agent lekérdezheti az API-kat, ellenőrizheti a CI állapotát, elolvashatja a Slack üzeneteket, vagy interakcióba léphet a felhő infrastruktúrával.

Minél több cselekvési lehetősége van az agentnek, annál kevesebbet kell manuálisan áthidalnod. Szeretnéd, hogy az agent ellenőrizze, egy deployment valóban sikerült-e, mielőtt lezárja a ticketet? Ehhez hozzá kell férnie a felhőkonzolodhoz. Szeretnéd, hogy koordináljon a csapattal? Hozzá kell férnie a kommunikációs csatornákhoz.

Ez nem arról szól, hogy sci-fi AI-tenger urat építs. Arról szól, hogy megszűnjön a manuális munka az eszközök közötti váltogatásban. Minden alt-tab egy átadás, ahol kontextus vész el. Minél többet tud az agent autonóm módon csinálni a munkafolyamatodon belül, annál szorosabb lesz ez a hurok.

KORREKCIÓ: Honnan tudja az agented, hogy elrontotta?

Ez a kar, amit a legtöbb csapat teljesen elhanyagol, és emiatt érzik megbízhatatlannak az agentjüket.

Az agentednek visszajelzésre van szüksége. Nem csak "ez a kód nem működik", hanem árnyalt jelzésekre a minőségről, stílusról és szándékról. A linterek elkapják a szintaxisproblémákat. A tesztek elkapják a funkcionális hibákat. A code review elkapja az architekturális problémákat. De az agented nem tud reagálni olyan visszajelzésre, amit soha nem kap meg.

Gondolj így: minden automatikus korrekció, amivel az agented találkozik, egy tanulási pillanat. Minden figyelmen kívül hagyott hiba egy elszalasztott lehetőség. Minél szorosabbak a visszacsatolási hurkok, annál gyorsabban javul az agented.

Itt buknak el a legtöbbet a csapatok. Kézzel futtatják a teszteket, alkalmanként megnézik a linteket, és akkor nézik át a kódot, amikor eszükbe jut. De ahhoz, hogy az agented megbízható legyen, ezeknek a checkeknek automatikusnak és gyorsnak kell lenniük. Az a 45 perces CI pipeline halálos csapás az agent produktivitására. Azonnali visszajelzés? Ott kezdődik a varázslat.

A leggyengébb láncszem elve

Íme az a mentális modell, ami megváltoztatta, ahogyan erre gondolok:

Képzeld el három rúdat. Egy a Látásnak, egy a Cselekvésnek, egy a Korrekciónak. Az agented összesített képessége a legrövidebb rúdnál van maximálva.

Láttam már csapatokat, akik erőforrásokat öntöttek abba, hogy az agentjük jobb kódot írjon (Cselekvés), de soha nem adták meg a megfelelő kontextust (Látás), szóval újra és újra ugyanazokat a hibákat követte el. Láttam csapatokat, akik kifinomult visszajelzési rendszereket építettek (Korrekció), de az agent nem férhetett hozzá azokhoz az információkhoz, amikre szüksége lett volna a visszajelzés alkalmazásához (Látás). Minden esetben az a kar volt a szűk keresztmetszet, amit senki nem gondolt meghúzni.

Ez nem csak megérzés. Ez bármely olyan rendszer strukturális kényszere, amely észleli a környezetét, cselekszik rajta, és alkalmazkodik. Gondolj a reinforcement learning rendszerekre – szükségük van megfigyelésre (LÁTÁS), akcióterekre (CSELEKVÉS) és jutalmazó jelzésekre (KORREKCIÓ). Vedd el bármelyiket, és a rendszer degradálódik. A kódagented ugyanúgy működik.

Mit jelent ez a csapatodnak?

Ha kódagenteket értékelsz éles munkára, ne csak játékszerű feladatokon teszteld őket. Futtasd őket olyan szcenáriókban, amelyek mindhárom kart megterhelik:

• Tudja az agent elérni a kontextust, ami a kódbázisotok megértéséhez kell?
• Tud az agent olyan cselekvéseket végrehajtani, amelyek illeszkednek a valós munkafolyamatotokba?
• Kap az agent elég gyors visszajelzést ahhoz, hogy korrigálja magát?

Ha bármelyikre a válasz "nem igazán", oda kell irányítani az erőforrásaidat.

Mérnöki vezetőknek és architecteknek: ez nem az igazi eszköz megtalálásáról szól. A megfelelő rendszer megépítéséről szól. Az eszköz csak a motor. A karok adják a váltót, az üzemanyagrendszert, a hűtést. Egy Ferrari hiányzó kerékkel nem szuperautó – csak egy törött autó.

A nagyobb kép

Még nagyon korai az AI-támogatott fejlesztés korszaka. A csapatok azt tanulják, hogy egyszerűen rádobni egy kódagentet a problémára nem elég. Azok a csapatok fognak a legtöbbet profitálni, akiknek nem a legokosabb modellje van – hanem a legszorosabb hurkok a látás, cselekvés és korrekció között.

Szóval mielőtt hibáztatnád az eszközt a csalódást keltő eredményekért, nézz őszintén a karjaidra. Melyik a legrövidebb? Ott van a lehetőséged.