Az ügynökalapú programozást bevezető csapatok többségénél a szűk keresztmetszet a kódgenerálásról az ellenőrzésre helyeződik át; az ellenőrzési ciklus átalakítása nélkül a nettó sebességnövekedés szinte nulla.
Nagy léptékű CI-környezetekben – több millió éjszakai teszt és több száz mérnök mellett – az ügynökök legértékesebb feladata nem a kódgenerálás, hanem a hibák felelősökhöz irányítása és osztályozása.
Az ügynök hasznos kimenete kiállja az alapos vizsgálatot, és nem csupán mintázatokat ismer fel, hanem az ok-okozati összefüggéseket is megmagyarázza.
A bizonyítékgyűjtési és kontextus-összeállítási réteg megtervezése fontosabb, mint a generálási rétegé.
Az ügynökalapú programozásról szóló beszélgetések többsége még mindig egy egyszerű ígéretből indul ki: több kód, gyorsabban.
Ez olykor egy ambiciózusabb jövőképpé bővül, amelyben az ügynökök megtervezik a munkát, PR-eket nyitnak, és minimális emberi beavatkozással élesítik a módosításokat. A legtöbb mérnöki csapat számára azonban a legkézzelfoghatóbb rövid távú érték ennél szűkebb területen jelentkezik. Az iteráció költségének csökkentéséről van szó.
A szoftverszállítás nem pusztán kódgenerálás. A kódírás csak egyetlen szakasza annak a hosszabb ciklusnak, amely az ellenőrzést, a tesztelést, az üzembe helyezést és probléma esetén a kivizsgálást is magában foglalja. Azok a csapatok, amelyek az ellenőrzési ciklus átalakítása nélkül vezetik be az ügynökalapú programozást, többnyire csak a folyamat későbbi pontjára helyezik át a szűk keresztmetszetet.
A generálás felgyorsítása önmagában nem teszi automatikusan gyorsabbá a csapatot. Csupán több munkát helyezhet át az ellenőrzésre, az igazolásra és a bizalom megteremtésére.
Sok mérnöki környezetben nem az első változat elkészítése költséges, hanem annak igazolása, hogy az eredmény valóban megbízható.
A módosítás valóban kijavította a hibát vagy javított a rendszeren? Nem okozott máshol regressziót? A hiba a kódban, a környezetben, a tesztekben vagy valamelyik függőségben van? A javasolt javítás a kiváltó okot kezeli, vagy csak a látható tünetet?
Az ügynökök ebben segíthetnek – nem azért, mert helyettesítik a mérnököket, hanem mert strukturált első elemzést végezhetnek a rendezetlen bizonyítékokon: átvizsgálhatják a naplókat, összevethetik a közelmúltbeli módosításokat, összefoglalhatják a releváns jeleket, feltárhatják a valószínű okokat, ellenőrzéseket futtathatnak, és ember által tovább vizsgálható eredményt adhatnak.
Sok csapatnál nem a kód nulláról történő generálása az ügynök leghatékonyabb alkalmazási módja. Sokkal inkább az, hogy leszűkítse a probléma keresési terét, mielőtt valaki órákat töltene ugyanezzel manuálisan.
Ez különösen jól látható a nagy léptékű hibakeresési munkafolyamatokban. Képzeljünk el egy éjszakai CI-folyamatot, amely több száz mérnök által módosított kódbázisokon több millió tesztet futtat – egyik ügyfelünknél ez a mindennapi valóság. Hiba esetén nehéz megtalálni és értesíteni a felelőst. A probléma lehet az alkalmazáskódban, egy függőségben, a tesztelési végrehajtási környezetben vagy a technológiai lánc más részén. A naplók mérete több gigabájt is lehet, és nem mindig az a csapat találkozik először a problémával, amelyik felel érte.
Egy ilyen munkafolyamatban nem az a természetes megoldás, hogy egyetlen ügynök írja meg a javítást. Inkább olyan rendszerre van szükség, amely gyorsan leszűkíti a probléma terét.
Egy hasznos folyamat begyűjtheti a naplókat, kiválaszthatja a releváns bizonyítékokat, összefoglalhatja a lényeges információkat, tesztkörnyezetben vizsgálhatja a kódot, majd strukturált gyökérokelemzést készíthet megbízhatósági pontszámmal, nyomon követhető megállapításokkal és javasolt következő lépésekkel. A megbízhatósági pontszám kialakításához egy szakterületi szakértő értékeli az ügynök kezdeti kimenetét. Ezt ezután egy bíróként működő LLM kapja meg, amely a későbbiekben automatizálja a pontozást, miközben összhangban marad az emberi megítéléssel.
A cél nem a mérnöki ítélőképesség kiiktatása, hanem az, hogy az ellenőrzést végzők jobb kiindulópontot kapjanak. A regressziók osztályozása, a PR-ek ellenőrzése, a tesztek javítása, a kiadás validálása és az üzembe helyezés utáni kivizsgálás mind hasonló felépítésű. Mindegyik sok bizonyítékot és ellenőrzést igényel, ráadásul tele van bizonytalansággal. Nem azt várják az ügynöktől, hogy helyettesítse a mérnöki folyamatot, csupán azt, hogy segítsen előrevinni.
Ezért is fontos, hogy a csapatok körültekintően értékeljék ezeket a rendszereket.
Nem az a helyes kérdés, hogy egy ügynök képes-e önmagában lenyűgöző eredményt létrehozni. A jobb kérdés az, hogy javít-e egy valós munkafolyamaton anélkül, hogy máshol hátráltatná azt.
Azt kell vizsgálni, hogy a kimenet elég konkrét-e az ellenőrzéshez, megmagyarázza-e az ok-okozati összefüggéseket ahelyett, hogy pusztán mintázatokat keresne, és könnyebbé teszi-e az ellenőrzést ahelyett, hogy megnehezítené. Egy hihető válasz nem feltétlenül hasznos. A gyakorlatban a csapatok akkor bíznak meg az ügynök kimenetében, ha az kiállja az alapos vizsgálatot, és konkrétan ellenőrizhető megállapításokat kínál.
A mélyebb tanulság az, hogy a hasznos ügynökalapú rendszerekhez nem elég a generálás. Az is meghatározó, hogyan gyűjtik össze a bizonyítékokat, miként állítják össze a kontextust, hogyan ellenőrzik a kimeneteket, és miként jelzik a bizonytalanságot az ellenőrzést végző személynek.
Ezért valószínűtlen, hogy az ügynökalapú mérnöki munka közeljövőjét egyetlen hatalmas ugrás jelenti majd a teljes autonómia felé. Valószínűbb, hogy gondosan megtervezett, szoros ciklusok sora lesz, amelyekben az ügynökök segítenek a csapatoknak kevesebb felesleges munkával átvizsgálni, ellenőrizni, igazolni és finomítani a munkájukat.
Ez talán kevésbé látványos, mint a széles körű autonómia ígérete, de sokkal közelebb áll ahhoz, ahogyan a valóban hasznos rendszereket ténylegesen bevezetik.