A vibe coding megváltoztatta, hogy kik képesek működőnek tűnő alkalmazást létrehozni. Egy prompt képes képernyőket generálni, API-t csatlakoztatni és hihető munkafolyamatot összeállítani, még mielőtt egy hagyományos fejlesztőcsapat befejezné az első tervfelülvizsgálatát.

Ez a sebesség új problémát teremt a toborzásban és a szállításban: egy demó többé nem erős bizonyíték arra, hogy a szoftver jó. A munkáltatók egyre gyakrabban tesznek fel egy nehezebb kérdést: helyesen viselkedik-e ez az MI által létrehozott rendszer akkor is, amikor a bemenetek rendezetlenek, a függőségek meghibásodnak, a felhasználók megismétlik a műveleteket, és az alapul szolgáló modell megváltozik?

A választ egy olyan minőségi mérce adja majd meg, amely kevésbé a vizuális csiszoltságra, inkább a fegyelmezett szoftver-ellenőrzésre hasonlít. Azok tűnnek majd ki, akik nem csupán megmutatják, mit hozott létre egy MI-kódolóeszköz. Azt is bemutatják, hogyan tesztelték, mire nem képes biztonságosan, és honnan tudják, hogy egy módosítás nem tört el valami mást.

A benchmark bizonyíték, nem ranglistán elért pontszám

A nyílt forráskódú kódolóügynök-benchmarkok hasznos kiindulópontot kínálnak, de eltérő képességeket mérnek. A SWE-bench valós GitHub-problémákat és repository-pillanatképeket használ, ezért releváns a karbantartási munkához. A Terminal-Bench a parancssori interakciót teszteli. A többi felsorolt benchmark, köztük a SlopCodeBench és a ProgramBench, a generált kód és az ügynökviselkedés különböző aspektusaira összpontosít.

Ezek a benchmarkok segíthetnek az eszközök összehasonlításában vagy egy alapvonal meghatározásában, de a munkáltatóknak óvatosnak kell lenniük azzal, hogy bármelyetlen pontszámot a gyártási használatra való alkalmasság bizonyítékaként kezeljenek. Egy modell, amely repository-problémákat old meg, még előállíthat nem biztonságos jogosultságkezelési logikát. Egy ügynök, amely teljesíti a terminálfeladatokat, nem biztos, hogy megőrzi az állapotot egy hosszú munkafolyamat során. Egy csiszolt webalkalmazás átmehet egy sikeres útvonalat bemutató demón, miközben hibásan kezeli az újrapróbálkozásokat vagy a dupla fizetéseket.

Ezért egy hiteles portfóliónak vagy belső felülvizsgálatnak célspecifikus értékelési készletet kell tartalmaznia. A készletben szerepelhetnek jellemző hibajelentések, normál felhasználói folyamatok, hibásan formázott bemenetek, jogosultsági határok, függőségi hibák és korábban javított regressziók. Minden esethez egyértelműen meghatározott elvárt eredménynek kell tartoznia, nem csupán egy helyesnek tűnő képernyőképnek.

Az MI által létrehozott szoftver minimális tesztcsomagja

Egy kis alkalmazáshoz hasznos minőségi csomag állítható össze bonyolult kutatólaboratórium nélkül is:

  • Elfogadási tesztek: ellenőrzik a felhasználó számára látható viselkedést a legfontosabb munkafolyamatokban, beleértve a sikeres és sikertelen kimeneteleket is.
  • Egység- és integrációs tesztek: elszigetelten ellenőrzik az üzleti szabályokat, és megerősítik, hogy az adatbázisok, az API-k, a várólisták és a hitelesítés a szándéknak megfelelően működnek együtt.
  • Negatív tesztek: hiányzó, hibásan formázott, túlméretezett, duplikált és jogosulatlan bemeneteket küldenek. Az MI által generált kód gyakran a promptban bemutatott útvonalon tűnik a legerősebbnek, ezért a nem kért útvonalak számítanak igazán.
  • Regressziós tesztek: minden felfedezett hibát állandó tesztté alakítanak. Egy javítás utáni zöld demó nem elég, ha ugyanaz a hiba visszatérhet a következő generált módosításban.
  • Biztonsági ellenőrzések: tesztelik a hozzáférés-vezérlést, a titkok kezelését, a kódinjekció elleni védelmet, a függőségek sérülékenységeit, valamint azt, hogy a nem megbízható tartalom befolyásolhatja-e az eszközhívásokat vagy a kiemelt jogosultságú műveleteket.
  • Üzemeltetési ellenőrzések: ellenőrzik az időkorlátokat, az újrapróbálkozásokat, az idempotenciát, a naplózást, a riasztásokat és a biztonságos viselkedést akkor, amikor egy függőség nem érhető el.

Ez közel áll ahhoz a minőségbiztosítási mérnöki szemlélethez, amelyet a Stack Overflow egy agentikus szoftverfejlesztési életciklusról szóló beszámolója ismertet. A fontos változás kulturális jellegű: a minőségbiztosítás nem az a végső ellenőrzés, amelyre azután kerül sor, hogy egy MI megírta a kódot. Ez az a struktúra, amely a gyors generálást kellően biztonságossá teszi a használathoz.

Ne csak a kimenetet, a vezénylést is tesztelje

Amikor a szoftver MI-ügynököt tartalmaz, a szokásos alkalmazástesztek szükségesek, de nem elegendők. A rendszer azért is meghibásodhat, mert a modell félreértett egy kérést, de azért is, mert a körülötte lévő vezénylés elvesztette a kontextust, kétszer hívott meg egy eszközt, hibásan formázott strukturált kimenetet fogadott el, vagy soha nem állt le.

Az összefoglaló által javasolt, bevezetés előtti regressziós területek gyakorlati ellenőrzőlistát alkotnak: kontextusvesztés, eszközök idempotenciája, promptinjekció, strukturált kimenet, leállás hiánya, a visszakeresés megalapozása és az állapot újratöltése. Ezek tesztelhető mérnöki tulajdonságok.

Például egy teszt kétszer futtathatja le ugyanazt a kérést, és megerősítheti, hogy a második próbálkozás nem hoz létre duplikált rendelést. Egy másik megszakíthat egy ügynököt egy munkafolyamat közepén, újraindíthatja, majd ellenőrizheti, hogy érvényes állapotból folytatja-e a munkát, ahelyett hogy megismételne egy visszafordíthatatlan műveletet. Egy visszakeresési teszt megkövetelheti a rendszertől, hogy csak egy jóváhagyott forráskészletből származó információt idézzen vagy adjon vissza. Egy strukturáltkimenet-teszt érvénytelen választ adhat, és megerősítheti, hogy az alkalmazás biztonságosan elutasítja azt, ahelyett hogy csendben érvényes adatként kezelné.

A hosszú ideig futó és többügynökös rendszereknek különösen egyértelmű hibanyilvántartásra van szükségük. A kutatók automatizált hibaattribúcióval dolgoznak, mert nehéz lehet azonosítani, melyik ügynök okozott egy hibát, és egy hosszú interakciós lánc mely pontján történt ez. Gyakorlati értelemben a csapatoknak adatvédelmi szempontból körültekintő auditnyomban kell megőrizniük az eszközhívásokat, a bemeneteket, a kimeneteket, a modellverziókat, az időbélyegeket, az állapotátmeneteket és a végső döntéseket. E bizonyíték nélkül egy piros teszt azt jelzi, hogy valami meghibásodott, de nem azt, hogy hol érdemes elkezdeni a javítást.

A reprodukálhatóság karrierelőnnyé válik

Az MI által generált kód változékony. Egy újrafuttatás eltérő megvalósítást eredményezhet; egy modellfrissítés megváltoztathatja a viselkedést; egy szolgáltatói kiesés módosíthatja az útválasztást vagy a késleltetést. A munkáltatók ezért értékelni fogják azokat a jelölteket, akik ismételhetővé tudják tenni az értékeléseket.

Ez azt jelenti, hogy ahol lehetséges, rögzíteni kell a modell-pillanatképeket, fel kell jegyezni a promptokat és a konfigurációt, szabályozni kell a véletlenszerűséget, amikor a platform ezt lehetővé teszi, és több próbát kell futtatni az olyan feladatoknál, amelyek kimenetele változó. Az összefoglaló kifejezetten a rögzített pillanatképeket, az elérhető helyeken az alacsony vagy nulla hőmérsékletet, valamint a konfidenciaintervallummal korlátozott CI/CD-kapu szerepét emeli ki hasznos védelmi intézkedésként.

Egy gyakorlati jelentésnek legalább három eredményt meg kell különböztetnie:

  1. Átmenési arány: hány eset sikeres.
  2. Következetesség: milyen gyakran sikeres ugyanaz az eset ismételt futtatások során.
  3. Súlyosság: hogy a hibák csupán kozmetikaiak, kellemetlenséget okoznak, adatkárosodással járnak, biztonsági szempontból jelentősek, vagy nem biztonságos külső műveletet idézhetnek elő.

Egy rendszer, amely 20 alacsony kockázatú formázási ellenőrzésből 19-et teljesít, nem feltétlenül jobb annál, amely 20 esetből 18-at teljesít, de soha nem lépi át a jogosultsági határt. A minőségi elvárásnak a következmények szerint kell súlyoznia a hibákat.

Az emberi ellenőrzésnek a kockázatra kell irányulnia, nem minden egyes sorra

A jobb automatizálás célja nem az, hogy valakit minden, az AI által előállított token újbóli elolvasására kényszerítsen. Hanem az, hogy az emberi figyelmet azokra a döntésekre irányítsa, amelyeket a tesztek nem tudnak teljes bizonyossággal eldönteni.

Az ellenőrzőknek az autentikációra és a jogosultságkezelésre, az adatmegőrzésre, a pénzügyi vagy szerződéses műveletekre, az adatvédelemre, a migrációkra, a hibák utáni helyreállításra, a külső felek engedélyeire, valamint azokra a változtatásokra kell összpontosítaniuk, amelyek magát a rendszer értékelési tesztkörnyezetét érintik. Egy agent esetében azt is ellenőrizniük kell, hogy milyen eszközöket hívhat meg, az egyes eszközök milyen adatokhoz férhetnek hozzá, és szükséges-e jóváhagyás egy visszafordíthatatlan művelet előtt.

A látható diffek, a jóváhagyási munkafolyamatok, az archivált beszélgetések és az auditnaplók — a Slack Code együttműködésen alapuló AI-kódolásról szóló leírásában kiemelt funkciók — egy szélesebb elvárás felé mutatnak: számítani fog annak története, hogyan készült a szoftver. Az ellenőrzőnek meg kell tudnia érteni a kérést, meg kell tudnia vizsgálni a létrehozott módosítást, látnia kell a tesztek bizonyítékait, és azonosítania kell, ki hagyta jóvá az élesítést.

Ez a nyilvántartás nem öncélú bürokrácia. Megkülönböztethetővé teszi a látványos demót egy kontrollált módosítástól, amelyet egy másik személy is karban tud tartani.

Mit érdemes bemutatni a portfólióban vagy az interjún

A jelöltek számára a legerősebb bemutató egy kis rendszer, amelynél szándékosan jól látható a minőség története. Tartalmazza a repositoryt, a beállítási útmutatót, az architektúrára vonatkozó megjegyzéseket, a tesztparancsokat, reprezentatív teszteseteket, az ismert korlátokat és egy rövid hibajelentést. Mutass be egy vagy két megtalált hibát, amelyeket regressziós tesztekké alakítottál. Térj ki arra, melyik modellt vagy kódoló agentet használtad, de ne állítsd be az eszközt a mérnöki döntések szerzőjeként.

Ha az alkalmazás agentet használ, dokumentáld az eszközengedélyeket, az állapotmodellt, az újrapróbálkozási szabályzatot, a leállási feltételt és az emberi jóváhagyási pontokat. Ha lekérdezéses információkinyerést használ, mutasd be, hogyan választja ki a forrásokat, és mi történik, amikor hiányzik a bizonyíték. Ha külső szolgáltatásokat hív, mutasd be az időtúllépések és a duplikált kérések kezelését.

Ne állíts megbízhatóságot egyetlen sikeres felvétel alapján. Egy ellenőrizhető állítás inkább így hangzik: „E 12 forgatókönyv 30 rögzített futtatása során a rendszer 28 esetben teljesítette az elfogadási kritériumokat; a két hiba bizonytalan dátumbevitellel volt kapcsolatos, és mindkettőt dokumentáltuk.” Maga a szám kevésbé fontos, mint a módszer, a határok és az őszinteség azzal kapcsolatban, ami még nincs tesztelve.

A gyorsaság új meghatározása

Az AI csökkenti az első verzió előállításának költségét. Nem szünteti meg annak költségét, hogy megállapítsuk, érdemes-e megbízni ebben a verzióban. Sőt, a gyorsabb generálás még fontosabbá teheti az értékelést, mert az élesítések között több ellenőrizetlen módosítás halmozódhat fel.

A vibe-kódolás utáni szakembert a következő ciklus alapján fogják megítélni: a viselkedés meghatározása, a kód generálása vagy módosítása, reális és támadó jellegű esetek tesztelése, a nagy kockázatú döntések vizsgálata, a hibák rögzítése, majd a rendszer fejlesztése a bizonyítékok elvesztése nélkül. A benchmarkok segíthetnek a képességek összehasonlításában. A QA-gyakorlatok határozzák meg, hogy ez a képesség megbízható szoftverré válik-e.

A minőségi elvárás tehát nem az, hogy „Képes vagy AI segítségével alkalmazást készíteni?” Hanem az, hogy „Bizonyítani tudod, mit csinál az alkalmazás, észre tudod venni, amikor már nem azt csinálja, és meg tudod tervezni azokat a korlátokat, amelyek megakadályozzák, hogy egy hiba incidenssé váljon?”