Markus Eisele tapasztalatait ismertetem arról, hogyan használt egy kódgeneráló ügynököt a Task Viewer nevű, belső használatú segédprogram elkészítéséhez az IBM Bob platformon. A Task Viewer egyszerű kényelem‑plug‑in: nem kritikus része a termelésnek, és főként belső felhasználást szolgál.
Miért volt ez kísérlet a delegálásra?
Eisele számára a projekt elsősorban valós kísérlet volt arra, hogy megtudja, a megvalósítás mekkora részét érdemes átruháznia az ügynökre. A döntésnél fontos szempont volt, mit kell a feladatot végzőnek még megtanulnia: egy tapasztalt fejlesztő, aki ismeri az alkalmazást, könnyebben ellenőrzi az eredményt; egy újonnan tanuló fejlesztő számára viszont maga a megvalósítás is tanulási folyamat lehet.
Ellenőrzés és saját bevizsgálás továbbra is szükséges
Még ha az összes kódot az ügynök készíti is el, Eisele alapelve az volt, hogy manuálisan ellenőrzi a funkcionalitást és a dizájnt: használja az alkalmazást, megnézi, hogy viselkedik-e a tervek szerint, és hogy az információk olyan módon jelennek‑e meg, hogy követni lehessen őket. Ezek a kérdések akkor is fontosak, ha az alkalmazás kicsi volt és a megvalósítás nagy részét delegálták.
Automatizált és kézi ellenőrzések: UI tesztek és SQL lekérdezések
A Task Viewerhez Eisele sok UI tesztet írt, hogy ellenőrizze, a felület ténylegesen a várt adatokat mutatja‑e; ez lehetővé tette a vizsgálatok ismétlését az alkalmazás változásaival. Ugyanakkor a képernyőn megjelenő számok helyességét nem elég csak vizuálisan ellenőrizni: ezért SQL lekérdezéseket futtatott az alapul szolgáló adatokon, és visszament azokra a rekordokra, amelyeket az alkalmazásnak reprezentálnia kellett.
Ez az egyszerűnek tűnő lépés jelentős megértést igényel: tudni kell, mit jelent az adott eredmény, és mely rekordoknak kell hozzájárulniuk hozzá. Szükség van egy elvárásra, amivel összehasonlítjuk az alkalmazás kimenetét. Szerencsére a csapat tagjai segítettek feltárni az adatkapcsolatokat, amelyeket Eisele önállóan nem tudott volna levezetni vagy megmagyarázni.
A „80%-ig eljutott az ügynök” kifejezés problémája
Eisele megjegyzi, hogy a „The agent got me 80% of the way there” jellegű leírások nehezen értelmezhetők. Gyakran a felület és a futó rendszer megléte alapján a maradék munkát kisebbnek ítéljük, de ha a számítás rossz forrásrekordokra épül, az egész látszólag ésszerű lehet, amíg nem találunk módot a helyes ellenőrzésre. Az ügynök által írt kód mennyisége önmagában kevés információt ad arról, mennyi időbe telik megtalálni és kijavítani a divergens értelmezéseket.
Külső kutatási eredmények és a saját mérlegelés
Eisele hivatkozik a DORA (DevOps Research and Assessment) elemzésére, amely 1,110 Google szoftvermérnök válaszát vizsgálta: a kódgenerálás által megtakarított idő egy részét auditálásra és verifikációra fordítják. Ez alátámasztja Eisele állítását, miszerint a gépi segítséggel készült kódot is alaposan ellenőrizni kell, és bármilyen összehasonlításnál figyelembe kell venni azt az időt, amíg az eredményt elfogadhatónak tartjuk.
Egy további említett munka Shen és Tamkin vizsgálata, amelyben 52 fejlesztőt vontak be egy ismeretlen Python könyvtár tanulására irányuló randomizált kísérletbe. Az AI‑t használó résztvevők azonnali tudásfelmérésen alacsonyabb pontszámot értek el, de a kutatók azt is megfigyelték, hogy azok, akik aktívan együttműködtek az AI‑val, jobb tanulási eredményeket értek el. Ez arra figyelmeztet, hogy nem elég azt nézni, készült‑e el a funkció: azt is értékelni kell, mit tanult a fejlesztő a feladat kapcsán.
Hogyan döntsünk az ügynök autonómiájáról?
Eisele szerint érdemes a delegálásról még a munkakezdés előtt megállapodni: mely részeket végezze el maga az ügynök, és mely részeket a fejlesztő. A döntést két alapvető kérdés mentén lehet meghozni:
- Mennyi munkát igényel majd a csapatnak annak megállapítása, hogy az eredmény helyes a szándékolt használathoz?
- Mit kell megtanulnia a fejlesztőnek az adott feladat elvégzésével?
Előfordulhat, hogy a verifikáció egyszerű, de a feladat szándékosan marad a fejlesztőn azért, hogy elsajátítson egy készséget. Máskor a verifikáció hiánya indokolhatja, hogy az első lépéseket tapasztaltabb kollégák segítségével tegyék meg.
Konkrét példa: státusz‑szűrő az issue listában
Eisele egy képzeletbeli esetet részletez: egy új munkatárs „show only open issues” (csak a nyitott hibák mutatása) szűrőt adna egy kis Java alkalmazás listájához. Egy ügynök előállíthatná a request paramétert, a lekérdezési feltételt és a képernyőváltoztatásokat; ez tapasztalt fejlesztőnek jó delegálás lehet. A tanuló fejlesztőnek azonban meg kell értenie, mely státuszok számítanak nyitottnak, hol történik a rekordok kiválasztása, és hogyan kell a csapat által elvárt módon tesztelni.
Példaként: ha a lista egyszerre húsz elemet mutat, és a tesztadatban húsz lezárt issue követi az öt nyitott, akkor a „show only open issues” opciót választva az ötnek kell megjelennie. Ha azonban az alkalmazás előbb betölti a húszat, majd a böngészőben végzi el a szűrést, a képernyő üres lesz. A fejlesztő számára a különbség feltárása — hogy hol történik a szűrés és a lapozás — fontos tanulási alkalom.
Miután a fejlesztő meg tudja magyarázni a viselkedést és elkészítette az első tesztet, az ügynök átveheti a környező megvalósítást. Egy későbbi kérés, például szűrés assignee alapján, lehetőséget ad a tanultak alkalmazására és a csapat számára annak elbírálására, hogy mennyit delegáljanak a következő változtatásnál.
Tanulságok és javaslatok
Eisele tapasztalata szerint sok kódot lehet delegálni, ha adottak a következők: megbízható ellenőrzési módok, hozzáférés az adatokhoz, és kollegiális segítség, amikor a fejlesztő megértése hiányos. A csapatoknak érdemes ezeket a feltételeket megteremteni, mert a jobb tesztek csökkenthetik a változtatások elfogadásához szükséges energiát, míg a tanulásra fordított idő segít abban, hogy más fejlesztők később is megbízhatóan ítéljék meg a változásokat.
Gyakorlati javaslatok, amelyeket Eisele megfogalmaz:
- Mielőtt delegálnánk, egyeztessük, mi marad a fejlesztőnél és mi az ügynöknél, és mi indokolja ezt.
- Alakítsuk ki vagy javítsuk a verifikációs módszereket (UI tesztek, adatlekérdezések), hogy könnyebb legyen elfogadni egy változtatást.
- Hagyjunk lehetőséget a tanulásra: ha azt várjuk el, hogy a fejlesztő a következő változtatásért felelős legyen, tervezzük meg úgy az első feladatot, hogy az tanulási alkalom is legyen.
Eisele végkövetkeztetése az, hogy az autonóm ügynökök egyre nagyobb szerepet kaphatnak a fejlesztésben, de a delegálás mértékét a verifikációhoz szükséges munkával és a fejlesztő tanulási igényeivel összhangban kell meghatározni. Néha érdemes szándékosan megtartani a feladat egy részét egy embernél, még akkor is, ha az ügynök képes lenne azt is elvégezni, mert a megértés megszerzése hosszabb távon értéket teremt a csapat számára.
