Markus Eisele szerint az ügynökalapú fejlesztés körül egy gyakori tévhit él: elegendő egy homályos céldeklarációt adni a modelnek, majd majdnem ad hoc módon javítgatni a visszakapott eredményeket. Ez látszólag gyors és olcsó, de a javítási ciklusok kínzó költségeit eltakarja.
Egy rövid, egyszerű prompt vonzónak tűnik, mert azonnal elindítja a implementációt. A gyakorlatban azonban következik a korrekciók sorozata: kimenet áttekintése, cél tisztázása, változtatások kérése, tesztek újrafuttatása, az újabb hiányosságok felderítése és újrakezdés. Minden ilyen körnél valakinek el kell döntenie, hogy a rendszer valóban megfelel-e a szándéknak — ez a személy lesz az "orákulum".
A másik véglet, a teljes, formális specifikáció elkészítése, jelentős kezdeti költséggel jár. Elfogadási kritériumok, szerződéses tesztek vagy viselkedésvezérelt fejlesztés (BDD) forgatókönyvei időigényesek. Ugyanakkor a későbbi költségszerkezet más: az orákulum egy része végrehajthatóvá válik, egy automatizált teszt ugyanazt a feltételt ellenőrzi minden alkalommal, fáradtság és hangulatváltozás nélkül.
Valódi kompromisszumról van szó: nem arról, hogy a specifikáció jó vagy rossz, hanem arról, hol van az összköltség szempontjából optimális pont. A legtöbb ügynökalapú munkánál ez a középmező: elég struktúra a tevékenység korlátozásához, elég példák a szándék konkretizálásához, és elég végrehajtható ellenőrzés ahhoz, hogy az áttekintés ne találgatássá váljon. Nulla specifikáció nem intelligens takarékosság, hanem költséges "vibe-coding".
A szűk keresztmetszet elmozdult, nem eltűnt
A szoftvermérnökség sosem csak a kód írásáról szólt; mindig arról döntöttünk, mi létezzen, mi ne történjen meg, mely kompromisszumok számítanak, és mit jelent a „kész” a valós világban. Korábban a hiányzó specifikációra gyakran emberi súrlódás világított rá: egy reviewer észrevett egy szélső esetet, a QA talált egy nem leírt utat, vagy egy tapasztalt fejlesztő hordozta a követelmények egy részét a fejében.
Az ügynökök azonban átalakítják ezt: az implementáció gyorsabbá és olcsóbbá válik, így egy hiányosan megadott ötlet hihető rendszerként jelenhet meg még azelőtt, hogy bárki pontosan meghatározta volna a célját. A régi világban a homályos követelményeket az emberi lassúság fékezte; az ügynökök világában a gépi sebesség gyorsítja le a megjelenést. Emiatt a specifikáció újra fontos lesz — valójában mindig is az volt. Ahogy az implementáció olcsóbbá válik, a nehézség áthelyeződik arra, hogy mit jelent a „helyes”, és hogyan ellenőrizhető megbízhatóan.
A specifikáció írása önmagában nem elég
Gyakran kihagyott lépés, hogy a specifikációt felül kell vizsgálni. Még egy alaposnak tűnő írás is hibázhat: lehetnek benne ellentmondások, lefedi a kellemes útvonalat, de semmit sem mond a retry-okról, a rate limit-ekről vagy a részleges hibákról. Lehetnek ellenőrizhetetlen állítások, vagy pontatlanul fogalmazott részletek, amelyek azt mondják, amit leírtak, nem azt, amit valójában gondoltak.
Ha egy agent hűségesen végrehajt egy hibás specifikációt, a kudarc nehezebben diagnosztizálható: a kód koherensnek tűnhet, és akár a megadott ellenőrzéseket is teljesítheti, miközben a valós probléma a specifikációban él. Ezért a specifikáció validálását külön tételként kell kezelni. A következő kérdéseket fel kell tenni megkezdés előtt:
- Belsőleg konzisztens-e a spec?
- Elég teljes-e a feladathoz?
- Mely részek automatizálhatók tesztekké?
- Hol támaszkodunk még emberi ítéletre?
- Mely hibaállapotok hiányoznak, mert mindenki feltételezett valamit?
Az ügynökök segíthetnek a specifikáció tesztelésében, de nem akkor, ha csak annyit kérünk tőlük, hogy "írjanak követelményeket". Az ilyen prompt gyakran csupán polírozott ködöt ad. Hasznosabb egy konkrétabb instrukció: írjuk meg a lehető legkisebb specifikációt, amely lehetővé tenné, hogy egy másik agent biztonságosan implementálja a feladatot — tartalmazzon feltételezéseket, nongoal-okat, elfogadási kritériumokat, szél-eseteket, megfigyelhető kimeneteket és nyitott kérdéseket, és jelölje, mely állítások válhatnak automatizált tesztté.
Ezt a tervezetet aztán adjuk át másik agentnek, hogy támadja meg: keressen ellentmondásokat, homályos kifejezéseket, rejtett függőségeket, ellenőrizhetetlen állításokat és hiányzó hibaállapotokat. Ez az egyszerű munkafolyamat jelentősen csökkenti a használható specifikációig jutás költségét.
Miért kell erősebb szerződés a multi-agent rendszerekhez?
Egyetlen agent, kis, jól behatárolt feladattal, gyakran kijavítja a laza instrukciókat: a hurok rövid, a hatás körülhatárolt, és egy ember visszatéríti, ha elkalandozik. Multi-agent rendszerek esetén azonban interpretációs sodródás halmozódik. Az Agent B nem veszi észre, ha Agent A 10%-kal félreértett valamit: egyszerűen tényként kezeli A kimenetét. Mire egy ember látja a végeredményt, az eredeti hiba több, kompetensnek tűnő réteg alatt rejtőzhet.
Ilyenkor a specifikáció nem pusztán útmutató, inkább szerződés. Ennél több kell, mint egy bekezdésnyi szándék: séma (schema), invariánsok, megengedett homályosság, validációs szabályok és explicit hiba viselkedés. Sok esetben contract tesztekre, típusos interfészekre és géppel ellenőrizhető átadási formátumokra is szükség van. A handoff maga a termék része — kevésbé látványos, de a valóság szempontjából lényeges.
Itt talál otthont a BDD és az executable acceptance test: értékük nem csupán módszertan, hanem az, hogy a humán orákulum egy részét ismételhetővé tették. Amint a viselkedés elég stabil ahhoz, hogy pontosan meg lehessen határozni, egy végrehajtható specifikáció gyakran olcsóbb, mint még egy review-ciklus.
A specifikációnak lejárati ideje legyen
Egy gyakori hiba, hogy a csapatok úgy gondolják, több szöveg mindig biztonságosabb. A jelenlegi modellek esetében ez nem igaz. A probléma részben az a megfigyelés, hogy a modellek teljesítménye csökken, ahogy a bemenet nő, még egyszerű feladatoknál is. További gond, hogy a tervezési próza, példák, kommentek, ticketek és régi elfogadási kritériumok együttesen elmoshatják, mely részek aktív utasítások és melyek történelmi jegyzetek.
Ez nem klasszikus prompt injection; inkább önmagunk által okozott instrukció-sodródás. A kontextus régi tervezési szándékokat, félvalid példákat, régi generált terveket és talán már nem létező osztályokat írhat le. Ilyenkor a modell nem egy spec-et olvas, hanem több, versengő igazság átlagát. Ekkor az overspecification már nem segít, hanem zavaróvá válik: az agent nem tudja eldönteni, mi az aktív követelmény és mi a történeti megjegyzés.
Ezért érdemes a tervezési dokumentációt idővel csökkenteni: mi az, ami még szükséges (üzleti indoklás, non-goalok, biztonsági korlátok, külső szerződések és az a néhány invariáns, amit nem akarunk újra felfedezni próbálgatással), és mi az, ami már csak megismétli a létező osztályok és metódusok működését — azt töröljük.
Az API-k kód-szerűsége mint specifikáció
Optimistább megközelítés: egyes kódbázisok hamarabb eljutnak oda, hogy a „kód maga a specifikáció”. Az API-tervezés sokat számít itt. Ha egy belső API konvenciók, gyenge típusok, setup-mágia és általános hibák mögé rejti a viselkedést, az agent nem tudja a kódot tekinteni specifikációnak; vissza kell építenie a szabályokat szétszórt próza és próbálgatás alapján.
Ezzel szemben egy jól megtervezett API — explicit nevekkel, feladat-szintű metódusokkal, erős típusokkal, olvasható validációval, hasznos példákkal és akcióképes hibaüzenetekkel — konkrét támaszt nyújt az agentnek. Ha az agent meg tudja vizsgálni a felületet, látja, mit csinál egy metódus, érti, mi a legális input és hogyan lehet hibából felépülni anélkül, hogy találgatnia kellene, akkor a kód sokkal nagyobb részt vállal át a specifikáció terhéből.
Ez nem csak publikus SDK-kra vonatkozik: belső szolgáltatáshatárokra, könyvtárkliensekre, repo-abstractions-re és a monorepo segédosztályaira is. Minél könnyebb egy API-t felfedezni és megvizsgálni, annál inkább tekintheti az agent a kódot szerződésnek ahelyett, hogy több prózát húzna be a kontextusba.
Hova érdemes befektetni?
Eisele álláspontja szerint nincs univerzális, mindenre alkalmas mennyiségű specifikáció. A helyes mérték a feladat típusától függ:
- Kis, jól behatárolt feladatoknál a strukturált cél: a cél, néhány példa, nongoal-ok és világos elfogadási kritériumok gyakran elegendő.
- Determinisztikus munkáknál (CRUD-flows, API-integrációk, adattranzformációk) az optimális pont jobbra tolódik: ezek könnyen korlátozhatók és tesztelhetők, így a több specifikáció gyorsan visszahozza az árát. Itt a BDD, a contract tesztek és a végrehajtható elfogadási kritériumok különösen hasznosak.
- Felfedező munkáknál (architektúra-választások, kutatási összegzések, új termékötletek) az optimális pont balra tolódik: a túlzott specifikáció elfojthatja az ügynök rugalmasságát. Ilyenkor a határokat érdemes definiálni, nem a kimenetet: mi legyen igaz, mi ne történjen meg, milyen bizonyíték kell, és mely döntés igényel emberi közbeavatkozást.
- Multi-agent csővezetékeknél ismét jobbra tolódik: minden határ felé szerződés kell.
Közös szabály minden esetben: validáljuk a specifikációt, mielőtt skálázzuk az implementációt.
Mi marad meg az Agile-ből és az XP-ből?
Eisele szerint az ügynökök nem teszik feleslegessé az Agile- és XP-elveket, de újra strukturálják, mi a hasznos és mi volt csupán tűrhető költség. A ceremóniák, amelyek elsősorban az emberek óránkénti koordinációjára szolgáltak (napi státuszok, felfújt backlog-ritusok, túl magabiztos becslések), gyengülhetnek. Ugyanakkor a visszacsatolási logika életben marad: rövid ciklusok, vékony vertikális szeletek, stakeholder-áttekintés és működő szoftver továbbra is számítanak — talán most még jobban, mert az agentek gyorsan sok meggyőző, de hibás kódot tudnak előállítani.
A XP-ből különösen sok marad: tesztelő gondolkodás, folyamatos integráció és refaktorálás továbbra is fontosak, mert az implementáció olcsóbbá válása növeli a végrehajtható ellenőrzések értékét, és az agentek is tudnak „tiszta”, de hosszú távon tarthatatlan kódot generálni. A pair programming is átalakulhat: néha az ember dolgozik egy kódoló agenttel, néha egy model generál, egy másik pedig review-olja annak kódját. A lényeg a gyors tervezési visszajelzés fenntartása.
Kisebb kiadások (small releases) is túlélnek; sőt, fontosabbá válhatnak: nagy, olcsó változtatások csábítása veszélyes, a review, rollback és diagnózis könnyebb kis lépésekben.
A tényleges ütőkártya
Az ügynökalapú fejlesztés ígérete valós: az implementáció jelentősen olcsóbb lehet. Ahogy azonban a kód olcsóbb lesz, a sikert vagy bukást a specifikáció és annak verifikálása fogja eldönteni. A legtöbb előnyt azok a csapatok érik el, amelyek jól tudják, mikor elég három tétel, mikor kell valódi szerződés, és mikor kell a szerződést végrehajthatóvá tenni.
Az ügynökök egyre jobbak; a döntések még mindig a miénk.
— Markus Eisele (eredeti cikk alapján)
