Írta: Kwame Boateng

Az MI-vel támogatott kódolást gyakran a páros programozás gyorsabb változataként írják le. Ez az összehasonlítás mára túl szűkké vált. Amikor egy ügynök át tud vizsgálni egy repositoryt, több fájlt is módosítani tud, eszközöket futtathat, előnézetet generálhat, és pull requestet nyithat, a központi együttműködési probléma már nem egyszerűen az, hogy „Tud-e kódot írni?” Hanem az, hogy „Az emberek látják, át tudják nézni, jóvá tudják hagyni, és később rekonstruálni tudják-e, mi történt?”

Ezért lehet, hogy az ügynökökkel támogatott szoftvercsapatok legfontosabb tervezési változása a privát promptoktól a látható munkaterületek felé való elmozdulás. A Slack Code például a leírás szerint projektcsatornákat egyesít kódoló ügynökökkel, kód-diffek auditálásával, élő HTML-előnézetekkel, visszajelzési és jóváhagyási munkafolyamatokkal, automatikus archiválással és auditnaplókkal. A GitHub Copilot alkalmazása emellett hozzáadott egy „Munkám” panelt az issue-k és pull requestek projektek közötti rendszerezéséhez. Ezek a funkciók egy gyakorlati alapelv felé mutatnak: az ügynök munkájának kevésbé kellene átláthatatlan válaszra, inkább egy ellenőrzött gyártási folyamaton áthaladó változáscsomagra hasonlítania.

A chat nem a munkanyilvántartás

Egy ügynökkel folytatott beszélgetés hasznos lehet egy ötlet feltárásához, de gyenge hivatalos nyilvántartás. Fontos részletek rejtőzhetnek egy hosszú szálban: mely fájlok változtak, mely parancsok futottak le, milyen feltételezéseket tett az ügynök, mit utasított el az ellenőrző, és hogy a végső eredmény eltér-e az első javaslattól.

Egy tartós munkaterület ellenőrizhetővé teszi ezeket a részleteket. Össze kell kapcsolnia a kérést egy konkrét repositoryval vagy projekttel, meg kell őriznie az ügynök tervét, meg kell mutatnia az eszközműveleteket és a fájlváltozásokat, hivatkozásokat kell biztosítania a tesztekhez és az előnézetekhez, valamint rögzítenie kell, ki hagyta jóvá az eredményt. A pontos felület változhat — lehet issue-követő, pull request, együttműködési csatorna vagy ügynökkonzol —, de az információnak a munkamenet befejezése után is meg kell maradnia.

Ez nemcsak megfelelőségi, hanem hétköznapi mérnöki okokból is fontos. Ha két héttel később megjelenik egy hiba, a csapatnak többre van szüksége a végső diffnél. Tudnia kellhet, mi volt az eredeti követelmény, mi volt a generált terv, milyen teszteredmények álltak rendelkezésre, milyen megjegyzéseket tett az ellenőrző, és hogy egy ember kifejezetten elfogadott-e egy kockázatos kompromisszumot. A tartós nyilvántartás lerövidíti ezt a vizsgálatot.

A látható munka öt rétege

A kódoló ügynököket bevezető csapatok minden változást tekinthetnek egy kis, ellenőrizhető ügyiratnak. Különösen hasznos öt réteg:

  1. Szándék: az issue, az elfogadási kritériumok, a korlátok és a kért hatókör.
  2. Terv: az ügynök által javasolt megközelítés, mielőtt fájlokat módosítana. Nem triviális feladat esetén ez jóváhagyási ellenőrzési pont, nem puszta díszítés.
  3. Diff: a pontos hozzáadások, törlések, függőségváltozások, konfigurációs módosítások és generált eszközök.
  4. Bizonyíték: teszteredmények, lint kimenete, biztonsági ellenőrzések, képernyőképek, valamint adott esetben élő vagy telepíthető előnézet.
  5. Döntési nyilvántartás: az ellenőrző megjegyzései, a kért módosítások, a jóváhagyás, az elutasítás, a visszaállítás vagy az utómunkálatok.

Nem az a cél, hogy minden változást egy nehézkes bizottságon kelljen átvinni. Egy elgépelésnek és egy fizetési folyamat módosításának nem kell azonos ellenőrzéseken átesnie. A cél az, hogy az ellenőrzés szintje arányos legyen a lehetséges hatással.

A jóváhagyásokat műveletekhez kell kötni

Az „ember a folyamatban” túl homályos ahhoz, hogy hasznos kontroll legyen. Előfordulhat, hogy valaki úgy hagy jóvá egy tervet, hogy nem látja az abból születő diffet, vagy úgy hagy jóvá egy kódmódosítást, hogy nem veszi észre: az ügynök egy telepítési fájlt is módosított. A jobb munkafolyamatok egyértelműen meghatározzák, mire jogosít a jóváhagyás.

Egy csapat például engedélyezheti, hogy az ügynök automatikusan olvasson egy repositoryt és helyi teszteket futtasson, jóváhagyást kérhet, mielőtt a kijelölt branchen kívül ír, és külön jóváhagyást írhat elő az összevonás vagy a telepítés előtt. Az ügynök javasolhat adatbázis-migrációt, de megtilthatják neki annak éles környezetben történő végrehajtását. Az Egyesült Arab Emírségek javasolt megközelítése annak osztályozására, hogy mely feladatokat hajthatják végre az ügynökök, illetve melyeket csak ajánlhatnak, ugyanezt a tágabb mintázatot tükrözi: az autonómiát feladatonként kell kiosztani, nem pedig globálisan feltételezni.

A jóváhagyásoknak hatókörre és lejáratra is szükségük van. A „frissítsd a nyitóoldal szövegét” jóváhagyása nem adhat észrevétlenül engedélyt egy új analitikai csomag bevezetésére. A tegnap jóváhagyott tervnek ma nem szabad automatikusan kiterjednie egy lényegesen módosított diffre. A felületnek láthatóvá kell tennie ezeket a határokat.

Az előnézetek az ellenőrzést szemlévé alakítják

A kód átnézése gyakran könnyebb, ha az emberek megvizsgálhatják az eredményt, ahelyett hogy a forrásfájlokból kellene kikövetkeztetniük. Egy élő HTML-előnézet felfedheti a hibás térközöket, a hiányzó állapotokat, a nem hozzáférhető vezérlőelemeket vagy a navigáció nem szándékos módosítását, amelyet az ellenőrző egy szöveges diffben esetleg nem vesz észre.

Az előnézetek nem bizonyítják a helyességet. A tesztek és a forráskód ellenőrzése mellett kell szerepelniük, nem azok helyett. Ugyanakkor közös vitatási objektumot hoznak létre: az ellenőrző rámutathat egy konkrét képernyőre, állapotra vagy interakcióra, és a javasolt módosításhoz kapcsolva hagyhat visszajelzést.

Ez különösen értékes, amikor nem szakértők is részt vesznek az ellenőrzésben. Lehet, hogy egy termékmenedzser nem tudja megítélni egy keretrendszer módosítását, de ő lehet a megfelelő személy annak megerősítésére, hogy a munkafolyamat megfelel a követelménynek. Egy tervező ellenőrizheti a vizuális regressziót. Egy biztonsági szakértő a jogosultságokra és az adatkezelésre összpontosíthat. Az ügynökökkel támogatott munkaterület minden kérdést ahhoz a személyhez irányíthat, aki a legalkalmasabb a megválaszolására.

A diffeknek nemcsak színre, hanem kontextusra is szükségük van

A megszokott piros-zöld diff továbbra is alapvető, de az ügynök által generált változások elég átfogóak lehetnek ahhoz, hogy túlterheljék az ellenőrzőt. A csapatoknak arra kell kérniük az ügynököket, hogy a commitokat vagy változáscsoportokat szűken tartsák, magyarázzák el, miért változott meg minden lényeges fájl, és külön azonosítsák a generált vagy szállítói fájlokat.

Hasznos áttekintési kérdések többek között:

  • Milyen, a felhasználó által látható viselkedés változott?
  • Mely fájlok módosultak csak a megvalósítás támogatása érdekében?
  • Milyen feltételezéseket tett az ügynök a meglévő viselkedéssel kapcsolatban?
  • Mely teszteket adták hozzá, módosították vagy nem futtatták le?
  • Érintheti ez a változás a jogosultságokat, az adatmegőrzést, a számlázást vagy külső API-kat?

Ezek a kérdések a felülvizsgálatot a „nézz rá erre” homályos kéréséből ismételhető vizsgálattá alakítják. Emellett segítenek feltárni egy gyakori hibamódot: egy hihető funkciót, amelyet hiányos tesztfrissítés vagy véletlen konfigurációmódosítás kísér.

Archiváld a fontos gondolatmenetet

Nem feltétlenül hasznos minden modellbeszélgetés minden tokenjének megőrzése. A hosszú előzmények tárolása költséges és nehezen kereshető lehet, miközben a kontextustömörítéssel kapcsolatos kutatások arra figyelmeztetnek, hogy az összefoglalók fontos információkat veszíthetnek el. Ezért egy praktikus ellenőrzési nyomvonalnak a döntések szempontjából releváns elemeket kell megőriznie, nem pedig válogatás nélkül mindent elmentenie.

Legalább a kérést, a jóváhagyott tervet, a végleges diffet, az eszközök és tesztek eredményeit, az előnézetre vagy telepítésre mutató hivatkozást, a felülvizsgálók döntéseit és az engedélyezett kivételeket kell megőrizni. Ha egy ügynök külső forrásokat használt vagy belső dokumentumokat töltött le, rögzíteni kell a releváns forráshivatkozásokat és azt a pontot, amikor ezek hatással voltak a módosításra. Nagy kockázatú munkák esetén indokolt lehet a teljes interakciós és végrehajtási napló megőrzése.

Ahol a kockázatok ezt indokolják, tedd a nyilvántartásokat hamisításbiztossá, és még egy válsághelyzet előtt határozd meg a megőrzési szabályokat. Egy olyan ellenőrzési nyomvonal, amely egy csatorna archiválásakor eltűnik, vagy amely nem tudja megkülönböztetni a módosított eredményt az eredetitől, nem fogja támogatni a komoly vizsgálatot.

Mit változtat ez a szoftveres karriereken?

A kialakulóban lévő készség nem pusztán jobb promptok írása. Hanem olyan munka megtervezése, amelyet egy másik ember meg tud vizsgálni, és amelyben megbízhat. A fejlesztőknek magabiztosan kell meghatározniuk az elfogadási kritériumokat, fel kell bontaniuk a feladatokat, nagy léptékben kell áttekinteniük a diffeket, érdemi teszteket kell készíteniük, és el kell dönteniük, hol kell az ügynöknek megállnia és kérdeznie.

A termék- és dizájnszakembereknek nagyobb szerepük lesz az előnézetek áttekintésében és a szándék tisztázásában. A QA-mérnökök segíthetnek meghatározni a jóváhagyási kapukat és a hibás eseteket. A mérnökvezetőknek úgy kell majd mérniük az áteresztőképességet, hogy közben ne jutalmazzák a láthatatlan kockázatvállalást. A műszaki írók és az üzemeltetési szakemberek azzal járulhatnak hozzá, hogy tartóssá teszik a döntéseket, a kivételeket és az üzemeltetési útmutatókat.

Hasznos gyakorlat lehet egy rutinszerű funkció bizonyítási láncának feltérképezése: kérés, terv, branch, diff, tesztek, előnézet, jóváhagyás, kiadás és visszaállítás. Ezután kérdezd meg, hol kényszerülne egy jövőbeli csapattárs találgatni. Minden találgatási pont jelölt lehet egy jobb munkaterületre, egy egyértelműbb jogosultságra vagy egy tartósabb nyilvántartásra.

Egy egyszerű működési szabály

Engedd, hogy az ügynökök gyorsan mozogjanak egy látható, visszafordítható sávon belül. Adj nekik meghatározott munkaterületet, korlátozd az érzékeny műveleteket, követelj jóváhagyást az érdemi határoknál, csatolj bizonyítékot a módosításhoz, és őrizd meg a végső döntést. A cél nem az automatizálás lelassítása addig, amíg az a kézi kódolásra nem hasonlít. Hanem az, hogy a sebesség összeegyeztethető legyen az elszámoltathatósággal.

Az ügynökökkel támogatott fejlesztésben nem az a legjobb együttműködő, amelyik önmagában a legtöbb kódot állítja elő. Hanem az a rendszer, amelynek a munkája megérthető, megkérdőjelezhető, jóváhagyható, visszavonható és amelyből tanulni lehet.