Markus Eisele szerint az ügynök(agents)-által generált kód elfogadásának feltételeként bizonyítékot kell kérni, amely összekapcsolja a megállapodott viselkedést, az implementációt és a teszteket. A javaslat lényege, hogy a review erőforrásait a változás „blast radius” — azaz egy hiba hatásának kiterjedése — alapján osszuk be, és ne csak a megváltozott sorok száma szerint. A cél, hogy a fontos döntéseket és nyitott kérdéseket dokumentáljuk, és csak ott végezzünk mély kódellenőrzést, ahol annak következményei nagyok.
Mi a probléma?
Az ügynökök gyorsan képesek működő implementációt és teszteket generálni, de a pull request jóváhagyása továbbra is emberi döntés marad. Ha minden generált sorhoz arányos mennyiségű emberi ellenőrzés szükséges lenne, a review lesz a kapacitás korlátja. A kérdés az: hogyan döntsük el, hogy hol érdemes időt tölteni az ellenőrzéssel?
Blast radius — a változás hatóköre
Eisele példáján: egy visszatérítés-kezelő szolgáltatásnál bevezetünk egy jóváhagyási lépést — 100 € fölötti visszatérítésekhez engedély szükséges, pontosan 100 €-nál nem. Az ügynök bevezeti a jóváhagyást és hozzá teszteket, miközben a fizetési integrációnál retry (újraküldés) logikát is ad hozzá időkorlát után. Ez a retry jelentősen megnövelheti a blast radius-t, különösen ha a retry a megosztott fizetési kliensbe kerül; akkor minden visszatérítésre hatással lehet, és ismételt pénzkifizetést okozhat.
A változás sorainak száma nem árulja el a hatókört. Ehelyett határozzuk meg, hogy egy módosítás milyen műveleteket érinthet, és ellenőrizzük, hogy az implementáció marad-e ezen a határon belül. Fontos figyelembe venni azt is, mennyire nehéz visszacsinálni egy hibát (például kétszer kifizetett összeget nem lehet egyszerűen visszaállítani).
Kétirányú nyomkövetés (bidirectional traceability)
Érdemes mind a specifikációból követni az implementációt és a teszteket, mind pedig visszafelé: az implementációból megmutathatónak kell lennie, miért tartozik egy viselkedés ehhez a pull requesthez. NASA szoftvermérnöki irányelvei is leírják a követelmények nyomkövetését implementáción és verifikáción keresztül; ez az ötlet jól alkalmazható egy átlagos pull requestre is.
Az ügynök segíthet megtalálni ezeket a kapcsolatokat: adjuk meg neki a megállapodott specifikációt és a repository változásait, és kérjük, hogy jelezze a hiányzó vagy megmagyarázatlan viselkedést. Kezdjük a megváltozott fájlokkal, és kövessük a hívásokat is, mert egy megosztott kliens megváltoztatása olyan kód viselkedését módosíthatja, amelyet nem szerkesztettek ebben a PR-ben.
A tesztek is osztozhatnak a hibán
A tesztek önmagukban nem garantálják a helyességet: ha az ügynök félreértelmezi az elvárást (például "above €100" helyett "€100 and above"), az implementáció és a teszt is ugyanúgy hibás lehet, és a CI zöldet ad. Ezért a reviewernek ellenőriznie kell a tesztek elvárt kimenetét a megállapodott viselkedéssel szemben, különösen a határértékeket.
Használjunk másik ügynököt arra, hogy javasoljon elfelejtett eseteket és ellenőrizze, hogy az assert-ek megfelelnek-e a követelményeknek, de tartsuk meg az emberi ellenőrzést is: egy másik modell is elkövetheti ugyanazt a félreértelmezést. Egy 2026-os tanulmány LLM-ek követelmény-megfelelésre vonatkozó ítéleteit vizsgálva arra mutatott rá, hogy modellek elutasíthatnak helyes implementációkat és elfogadhatnak hibásakat — ez óvatosságra int, amikor modellek magabiztos magyarázatait használjuk elfogadásként.
Tegyük könnyen ellenőrizhetővé a bizonyítékot
Követeljünk rövid review rekordot minden pull requesthez, amely összekapcsolja a megállapodott viselkedést a tesztekkel és feltárja a nyitott döntéseket. Példa egy ilyen rekord elemeire a visszatérítési esetre:
- Megállapodott viselkedés: 100 € fölötti visszatérítések várnak engedélyre; pontosan 100 € nem.
- Bizonyíték: határérték-tesztek ellenőrzik, mikor küldi a szolgáltatás a fizetési kérést; a PR hivatkozik a releváns assert-ekre és a CI eredményeire.
- További viselkedés: a fizetési kliens újraküldést ad timeout után.
- Blast radius: ha a retry a megosztott kliensre vonatkozik, minden visszatérítés érintett lehet; ellenőrizni kell a kliens hívóit.
- Nyitott kérdés: a tesztek nem fedik le, hogy a szolgáltató ténylegesen teljesítette-e a visszatérítést a timeout előtt; a biztonságos retry-s viselkedést még ki kell dolgozni.
Kezdjük a review-t ezzel a dokumentummal: ellenőrizzük, hogy a jóváhagyási assert-ek valóban a megállapodott szabályt vizsgálják, majd fókuszáljunk a retry-re, ahol a bizonyíték és a scope hiányos. Kösse össze a reviewer, hogy mely tesztek futottak le az adott revízión; a „tesztek zöldek” állítás túl általános.
Ellenőrizzük a módosításokat a tesztekben és az elfogadási kritériumokban is
Hasonlítsuk össze a teszteket az elfogadott kiindulási feltételekkel. Ha egy korábbi acceptance test azt várta, hogy egy 100 €-os visszatérítés továbbhalad, de az ügynök most átírta a tesztet jóváhagyási elvárásra, a megváltozott implementáció és teszt összhangja mellett is felfedi a követelmény megváltoztatását. A tesztek frissítése része lehet a normál fejlesztésnek, de a reviewernek el kell döntenie, hogy ez a viselkedésváltás szándékos-e; az ilyen változásoknak dokumentált döntést kell hagyniuk.
Állítsuk be a review mélységét a blast radius alapján
A review mélységét igazítsuk a lehetséges hatásokhoz és a bizonyítékok erejéhez. Kövessük az érintett hívásokat akkor is, ha azok a diff-en kívül esnek, ha egy hiba pénzmozgást érinthet. Rutinszerű, korlátozott hatású változásoknál kevesebb időt kell eltölteni a rekonstrukcióval, ha a viselkedés és a tesztek jól ismertek és megbízhatóak. Ha a folyamat rutinszerűen talál hiányzó feltételezéseket, fejlesszük a teszteket, mielőtt tovább csökkentenénk az emberi ellenőrzést.
A bizonyíték legyen a fejlesztési ciklus része
Ajánlott folyamat:
- A fejlesztés előtt egyeztessék a fejlesztővel és a követelménygazdával a viselkedést és a várt blast radius-t.
- Az ügynök implementál az adott scope-on belül és elkészít egy rövid review rekordot.
- A CI lefuttatja a teszteket a javasolt revízió ellen.
- A reviewer megvizsgálja a bizonyítékot, és ahol a következmények nagyok, közvetlen kódellenőrzést végez.
- Korlátozott felbontású rollouttal engedélyezze a kiadást, majd a produkcióbeli viselkedés alapján javítsa a teszteket és a specifikációt.
A review rekord része legyen a "definition of done". A fejlesztő felelős a rekord pontosságáért, még akkor is, ha az ügynök írta a kódot. A reviewer felelős az elfogadásért; fontos állítások esetén, ha nincs megfelelő bizonyíték, a döntés maradjon nyitott.
Tartsa a blast radius-t korlátozva
Ne keverjük össze az approval-funkció bevezetését a megosztott fizetési kliens áttervezésével, hacsak nincs szükség a kettő egyidejű változtatására. Külön PR-ek segítik a döntések átláthatóságát, de a megvalósítás is számít: egy egy soros változtatás egy megosztott kliensben mindenkire hatással lehet. Használjunk kontrollált kiadásokat (A/B), és győződjünk meg róla, hogy a valódi kifizetések előtt vannak megfelelő ellenőrzések.
Következtetés
A javasolt gyakorlat: kérjünk rövid, szemrevételezhető bizonyítékot minden agent-generált pull requesthez, határozzuk meg a megengedett blast radius-t előre, és dokumentáljuk a nyitott kérdéseket. A review erőforrásait irányítsuk oda, ahol egy hiba nagy kárt okozhat, és használjuk a CI-t, A/B rollouteket és a visszajelzést a produkcióból a tesztek és a specifikációk folyamatos javítására. Így több ügynök által generált kódot fogadhatunk el anélkül, hogy elveszítenénk az egyes változások következményeinek megértését és kontrollját.
Szerző: Markus Eisele
(Forrásmegjegyzés: az eredeti cikk hivatkozik egy 2026-os tanulmányra a nagy nyelvi modellek követelmény-megfeleléséről.)
