A cikk szerzője: Markus Eisele
Ez a cikk eredetileg Markus Eisele The Main Thread című hírlevelében jelent meg, a szerző engedélyével közöljük újra.
Az utóbbi időben egy elterjedő fejlesztői gondolkodás szerint az ügynökök (agents) önállóan el tudják dönteni a részleteket: elegendő laza célmegfogalmazás, az ügynök „felfedez”, és menet közben korrigálunk. Gyors, rugalmas, korszerű. Eisele szerint ez tévút — nem azért, mert az ügynökök képtelenek volnának, sokszor képesek rá, hanem mert a költségeket rosszul számoljuk.
Az igazság az, hogy nem nullázunk költséget: eltoljuk, feldaraboljuk, és kevésbé láthatóvá tesszük azt.
Két véglet és a rejtett költségek
Vannak két szélső modell:
-
Minimális specifikáció: a szándékot laza módon írjuk le, az ügynök szabadon értelmez, a fejlesztés azonnal kezdődhet. Az előzetes emberi munka költsége szinte nulla. Viszont később felhalmozódik a javítási ciklusok költsége: tokenfelhasználás, emberi újraindítások, és az, hogy minden kimenetet embereknek kell ellenőrizni.
-
Teljes, formális specifikáció: TDD, BDD, Gherkin forgatókönyvek, elfogadási kritériumok lefixálva, mielőtt egy sor kód is lefutna. Az előzetes emberi ráfordítás jelentős és látható, de az utólagos ellenőrzés költsége alapvetően más: a tesztek lesznek az oracle-ok — automatikus, ismételhető, fáradhatatlan ellenőrzést adnak.
A csere az, hogy mikor és milyen „valutában” fizetünk: a minimális specifikáció előrehozza a tokenköltséget és hátrahagyja az emberi ítéletet; a nehéz specifikáció emberi időt frontálisan igényel, de az automatizált ellenőrzés után kevesebb emberi felügyelet szükséges.
A teljes költség a specifikáció teljességéhez képest U-alakú: a minimum valahol a jól strukturált elfogadási kritériumok vagy BDD forgatókönyvek körül van — nem a nulla specifikációnál, és nem egy 40 oldalas követelménydokumentumnál.
Több ügynök együttműködése (multi-agent) eltolja a minimumot jobbra, mert az eltérések összeadódnak az átadások során.
A specifikáció problémája nem tűnt el
A szoftvermérnökség valódi nehézsége mindig a „mi legyen” megválaszolása volt: mit kell megvalósítani, mi tilos, mely kompromisszumok számítanak, mit engedhet meg a rendszer, és mit jelent a „kész” egy kaotikus valóságban. Ezt a problémát sokáig belesűrítettük meetingekbe, backlogokba, review-kba és QA-ciklusokba.
Az ügynökök csökkentik a kód előállításának súrlódását — ez nagyszerű — de ugyanakkor a hiányzó döntések később bukkannak fel, mert a rendszer képes plausibilis implementációt előállítani még mielőtt bárki tisztázná a szándékot.
A holt tér a specifikáció és a verifikáció felé mozog.
A specifikáció írása csak a feladat fele
Gyakran elhanyagolt pont: a specifikációt validálni kell, mielőtt átadjuk az ügynöknek.
Egy specifikáció hibái csak akkor válnak láthatóvá, amikor az ügynök végrehajtja azt. Lehet belső ellentmondás, hiányosság (például nem kezeli a harmadik fél API-jának 429-es válaszát), tesztelhetetlenség vagy egyszerűen az, hogy pontosan azt írjuk le, amit gondoltunk, de nem azt, amit valójában szerettünk volna.
Ha egy ügynök pontosan végrehajt egy hibás specifikációt, a probléma nehezebben debuggolható: az implementáció megfelel a specifikációnak, a hiba a specifikációban van. A javítási ciklus ezután drágább, mert nemcsak kódot, hanem gondolatmenetet kell visszafejteni.
A specifikáció validálása külön költségkategória: meg kell vizsgálni a belső következetességet, a teljességet, a tesztelhetőséget, és azt, hogy a leírt viselkedés valóban azt a célt szolgálja-e, amit építeni akarunk.
Hogyan használhatók ügynökök a specifikációhoz
Van egy harmadik stratégia, amit a kétpólusú gondolkodás figyelmen kívül hagy: használjuk az ügynököket a specifikáció megírására és validálására, majd külön implementációs ügynököket a végrehajtásra.
Ez megváltoztatja a költségszerkezetet: egy specifikációt először egy draftoló ügynök készít el a durva szándékból; egy másik, ellenőrző (adversarial) ügynök stresszteszteli a vázlatot következetesség, teljesség és tesztelhetőség szempontjából; egy harmadik ügynök fordítja a túlélő állításokat futtatható tesztekre. Az ember felülvizsgálja a végeredményt, ami gyorsabb, mint nulláról írni.
Fontos, hogy az ügynök ne legyen puszta jegyző: legyen szkeptikus termékmérnök-szerű szerepe. Nevezzék meg a feltételezéseket, különítsék el a célokat a nem-céloktól, adjanak példákat és kontra-példákat, jelöljék a mechanikusan tesztelhető részeket, és mutassák meg a tipikus kudarci módokat.
Egy hasznos prompt példája: „Fogalmazd meg a legkisebb specifikációt, amivel egy másik ügynök biztonságosan megvalósíthatná ezt. Tartalmazzon feltételezéseket, nem-célokat, elfogadási kritériumokat, szélső eseteket, megfigyelhető kimeneteket és nyitott kérdéseket. Jelöld meg, mely részek automata tesztté alakíthatók, és melyek igényelnek emberi felülvizsgálatot.”
Majd fussuk át egy másik ügynökkel: „Támadd meg ezt a specifikációt: találj ellentmondásokat, homályos kifejezéseket, rejtett függőségeket, tesztelhetetlen állításokat és hiányzó kudarci módokat.”
A cél nem automatizált prózai specifikáció, hanem ember által jóváhagyott, ügynökök által előterjesztett és ellenségesen ellenőrzött specifikáció, aminek annyi része legyen végrehajtható oracle, amennyit a domain enged.
Hogyan segít a BDD
A behavior-driven development (BDD), jól csinálva, egyesíti a specifikáció-írást és -validációt ugyanabba az artefaktumba. A Gherkin forgatókönyv egyszerre leírás és futtatható teszt: egyből lefuttatható a vázimplementációval, és ha a forgatókönyv futtatható akar lenni, sok homályosságot fel kell oldani.
Ezért a költséggörbe minimuma részben azért van a BDD környékén, mert az eszköz maga beépített validációt nyújt. A formátum előnyt ad, mert a validáció automatizálható.
Ugyanakkor valaki még mindig jól meg kell írja a forgatókönyveket: Gherkin is rosszul írható, és a szintaxis nem szünteti meg a szemantikai homályosságot.
Mi történik a multi-agent csővezetékeknél
Egyetlen jól körülhatárolt feladatra futtatott ügynöknél az alulspecifikálás visszafordítható: a visszacsatolás rövid, a javítás lokális és költsége kiszámítható.
Multi-agent rendszerek esetén más osztályú problémával állunk szemben: ha Agent A kimenete Agent B bemenete, akkor A eltérése összeadódik B futásában. B keményen és magabiztosan dolgozik egy rossz alapon. Mire az emberhez visszaér a hiba, az több réteg koherensnek tűnő, de torz eredményét takarja.
Ez a töréspont a specifikáció felé tolódik: a specifikációnak itt koordinációs szerződésként kell viselkednie az ügynökök között — erősen tipizált interfészekkel, invariánsokkal, engedélyezett homályossággal és validációs ellenőrzésekkel.
Ha a koordináló specifikáció hibás, nem egy ügynök csinál rosszat, hanem sokan, párhuzamosan, különböző módon.
Mely metodológiák maradnak relevánsak
Nem lesz minden, amit eddig megtanultunk, felesleges, de megváltoznak azok a részek, amelyek valódi támaszt nyújtottak.
- Az „Agile mint színjáték” problémás: a státuszfelmondások, a fikciós becslések és a ceremóniák, amelyek csak bizonyítéknak szolgálnak, hogy az incertiditást „megszelídítettük”, kevésbé szükségesek.
- Az Agile mint visszacsatolási filozófia továbbra is értékes: rövid ciklusok, működő szoftver, ügyfélkollaboráció és a terv hajlékonysága fontosabbak lesznek, mert az ügynökök gyorsan sok téves dolgot tudnak létrehozni.
- XP és tesztelő első megközelítések túlélnek, mert az implementáció olcsóbb lett, és az automatikus oracle-ok értéke nő.
- Pair programming átalakul ember–ügynök párosítássá: a lényege megmarad: a tervezési ítélet legyen közel a kódtermeléshez.
A metodológiák, amelyek gyors visszajelzést hoznak, megmaradnak; amelyek csak státusz-jelentést szolgálnak, elhalványulnak.
Hol érdemes befektetni?
A gyakorlati következtetés nem az, hogy mindig írj teljes BDD specifikációt, és nem az, hogy mindig engedd az ügynököt szabadon bolyongani. A legjobb pont munkafüggő, és a kalkulációnak őszintén számolnia kell a specifikáció validálásának költségét.
- Egyetlen ügynök kis, jól körülhatárolt feladatánál elég lehet a strukturált szándék: cél, példák, nem-célok és néhány elfogadási kritérium. A BDD itt túlzás lehet.
- Determinisztikus, jól érthető munkáknál (API integrációk, CRUD, adattranzformációk) a töréspont jobbra van: több specifikáció hamar megtérül, mert a domain korlátozható és a tesztek automatikusíthatók.
- Explorációs vagy kreatív munkáknál a túlzott specifikáció korlátozza az ügynök rugalmasságát: itt a töréspont balra tolódik.
- Multi-agent rendszernél a sweet spot ismét jobbra tolódik: az átadási szerződés a termék. Minden ügynökhatárra szerződést, sémát, invariánsokat és validációs ellenőrzéseket kell tenni.
Minden esetben: validáld a specifikációt — emberrel, ügynökkel vagy végrehajtható formátummal (például BDD). Ha kihagyod, a költséget később, magasabb kamattal fizeted meg, rosszabb diagnosztikai lehetőséggel.
Az ügynökök ígérete a nulla-spec munkára csábító, de a könyvelés, amit figyelmen kívül hagy, valós. Az ügynökök egyre jobbak lesznek; a költségszámítás viszont még mindig az ember feladata marad.
