A vibe coding ma már nem áll meg a kattintható prototípusnál. Egyre gyakrabban találkozunk olyan projektekkel, ahol egyetlen ember, AI-asszisztenssel, néhány hónap alatt összerak egy komplex rendszert: jogosultságkezeléssel, adminfelülettel, online fizetéssel, több külső szolgáltatás integrációjával. És a kód nem rossz.
Korábban arról írtunk, hogyan lesz a prototípusból éles termék. Most egy lépéssel tovább megyünk: mi a helyzet, ha a kód már rendben van, és mégsem állsz készen az élesítésre?
A kód kész, a termék még nem
Nemrég egy ilyen alkalmazást néztünk át élesítés előtt. Elindítottuk, lefuttattuk rajta a statikus kódelemzőket, a kollégákkal (és AI-jal is) megnéztük a teljes kódbázist. Az eredmény jobb volt, mint vártuk: egy korábbi biztonsági audit súlyos hibáinak nagy részét a fejlesztő már kijavította, a kód szerkezete rendezett volt, és a specifikációban leírt folyamatokat funkcionálisan megvalósította a rendszer.
Ez nem egyedi eset. Az AI-jal épített alkalmazásoknál, webes és mobilos projekteknél egyaránt, a kockázat jellemzően nem a kódban van, hanem körülötte:
- Nincs kialakított kiadási folyamat. A fő ágra küldött változás automatikusan élesbe kerülhet, kötelező build- és tesztellenőrzés nélkül.
- Nincs verziózás. Egy kiadásból nem derül ki, mi változott, és hogy a változás kompatibilis-e az előzővel. A szemantikus verziózás (semver) erre egyszerű szabályt ad: a MAJOR.MINOR.PATCH formátumban a főverzió emelése jelzi, ha valami visszafelé nem kompatibilis módon változott.
- Elavult függőségek. A keretrendszer és a csomagok verziója lemarad, ismert sebezhetőségekkel, pedig az elmúlt hetekben sorra jelentek meg 9-es pontszám feletti, kritikus CVE-k.
- Az éles rendszer eltér a repótól. Kézi módosítások egy webes felületen, adatbázis-migrációk, amelyekből nem lehet megbízhatóan újraépíteni az éles állapotot.
- Félig kezelt edge-case-ek, különösen a pénzügyi folyamatokban.
Egyik sem a rossz kód jele. Mindegyik annak a jele, hogy hiányzik az a szakmai rutin, amit egy fejlesztőcsapat évek alatt, gyakran fájdalmas tapasztalatokból épít fel.
Az első kiadás ilyenkor jellemzően még sikerül. A gond a másodiknál, vagy egy incidens keretében jön. Egy mobilalkalmazásnál például a régi verzió még hetekig a felhasználók telefonján fut, és ugyanazt a backendet hívja, mint az új. Ha a második kiadás észrevétlenül megtöri ezt a kompatibilitást, a régi alkalmazás egyik napról a másikra elromlik, és nincs gyors út visszafelé.
Kent Beck ezt a feszültséget features vs. futures néven írja le. Minden új funkció felél valamennyit a rendszer jövőbeli mozgásteréből, és ezt csak tesztekkel, rendezett szerkezettel és tudatos tervezéssel lehet visszaszerezni. Az AI-asszisztált fejlesztés ezt az egyensúlyt sürgetőbbé teszi: a funkciók gyorsabban jönnek, mint valaha, a jövő pedig ugyanilyen gyorsan fogy.
A tervrajz stimmel, de csak felülnézetből
Az AI-jal írt kód jellemzően hűen követi azt, amit kértél. A ház megfelel a tervrajznak. A gond az, hogy a tervrajz kétdimenziós: rajta vannak a szobák és az ajtók, de hiányzik róla a statika, a vezetékek és a vészkijárat.
Az AI a fő útvonalat, a „happy path”-et kiválóan megépíti. Az edge-case-ekre viszont akkor gondol, ha te gondolsz rájuk. Mi történik, ha a vásárló hetekkel később a bankjánál vitatja a terhelést? Ha az adminfelületen rögzített visszatérítés a fizetési szolgáltatónál meg sem történik? Ha valaki egy szkripttel ezerszer megnyitja az AI-alapú ügyfélszolgálati chatet, és a számlát te fizeted?
Ezeket a tapasztalatokat nem a kód írása közben szerzi meg az ember, hanem abból, hogy látott már élesben elromlani dolgokat. A harmadik dimenziót a tapasztalat rajzolja meg.
Ugyanaz az AI, ugyanazok a vakfoltok
Kézenfekvő ötlet: ha az AI írta a kódot, ellenőrizze is az AI. Ez részben működik, mi is használjuk az átvilágításoknál. Van azonban egy korlátja. Ha ugyanaz a modell írja, teszteli és javítja a kódot, mindhárom lépésben ugyanazok a vakfoltok lesznek jelen. Ami a fejlesztésnél nem „jutott eszébe”, az a tesztelésnél sem fog.
Incidens idején ez különösen veszélyes. Nyomás alatt, gyorsan javítunk, ugyanazzal az eszközzel és ugyanazzal a szemlélettel, amelyik a hibát létrehozta.
Külön figyelmet érdemel maga az AI-ügynök is. Ha a kódíró asszisztens jóváhagyás nélkül futtathat parancsokat és írhat fájlokat egy olyan gépen, ahonnan az éles rendszer is elérhető, az egy új típusú üzemeltetési kockázat.
A megoldás nem az, hogy dobjuk ki a prototípust és bízzuk a teljes projektet „szakértőkre” – hiszen ők is AI-t fognak használni –, hanem egy új, független nézőpont bevonása: más eszközök, egy tapasztalt külső szem, és valódi emberek, akik úgy használják a rendszert, ahogy a fejlesztő soha nem gondolta volna.
A láthatatlan réteg
Amitől egy működő alkalmazásból felelősen üzemeltethető termék lesz, az nagyrészt nem látszik a képernyőn. Négy területet szoktunk megnézni.
Folyamat. Egy változás nem közvetlenül a fejlesztő gépéről kerül élesbe, hanem automatikus ellenőrzéseken és egy külön tesztkörnyezeten keresztül. Az új funkciók fokozatosan, kis felhasználói körrel indulnak, és van út visszafelé, ha valami elromlik.
Üzemeltetés. Tudod, ha baj van, mielőtt a felhasználó szól. A kulcsok és jelszavak titkosítva vannak tárolva, nem a kódban. Az audit logokból utólag is visszakereshető, ki, mikor és mit csinált, ami vitás tranzakcióknál és incidenseknél aranyat ér.
Tudás. Ha egyetlen ember tudja, hogyan működik a rendszer, akkor az az ember a rendszer legnagyobb kockázata. Egy közérthető leírás az üzleti és technikai folyamatokról az első lépés ahhoz, hogy mást is be tudj vonni. Ehhez viszont neked is értened kell, amit építettél. Mitchell Hashimoto, a HashiCorp társalapítója ezt „whiteboard defense”-nek nevezi: bármikor félrehívhatnak, és el kell tudnod magyarázni, hogyan működik egy ügyfeleknek kiadott rendszered. Nem a függvénynevekre kell emlékezned, hanem arra, miért X és nem Y, mi történik, ha valaki rosszindulatúan használja, és hol mondja fel a szolgálatot. Prototípusnál ez mindegy, éles terméknél nem.
Jogi és adminisztratív oldal. Adatkezelési tájékoztató, a felhasznált szolgáltatók GDPR-megfelelése, incidenskezelési rend. Ezekről a kód semmit nem árul el, mégis élesítés előtt rendben kell lenniük. Ebben jogász a jó partner, de a technikai oldalt neki is valakinek el kell magyaráznia.
Mielőtt élesbe mész: ellenőrzőlista
Ha az alábbiak közül többre a válaszod „nem” vagy „nem tudom”, a kódod lehet, hogy kész, de a terméked még nem.
- Tesztlefedettség. Van automatikus tesztkészleted, és tudod, a kód mekkora részét fedi le? Az AI gyorsan ír teszteket, a kérdés az, hogy a fontos dolgokat teszteli-e.
- Specifikáció. Le van írva, mit kell csinálnia a rendszernek, és mit nem? Specifikáció nélkül a teszt csak azt ellenőrzi, amit a kód csinál, nem azt, amit kellene.
- Staging környezet. Van az élestől elkülönített tesztkörnyezeted, saját adatbázissal, ahol minden változás előbb kipróbálásra kerül?
- Quality gate-ek. Build, típusellenőrzés és tesztek kötelezően lefutnak, mielőtt bármi élesbe kerül? A kulcsok és jelszavak titkosítva, a kódon kívül vannak?
- Edge-case-ek. Végiggondoltad és kipróbáltad az edge-case-eket: visszatérítés, chargeback, megszakadt fizetés, duplikált kérés, visszaélés, váratlan költségrobbanás?
- SAST. Fut statikus kódelemzés (például SonarQube vagy Semgrep) minden változáson?
- Függőségek szkennelése. Ellenőrzöd a csomagokat és konténerképeket ismert sebezhetőségekre, például Trivy-vel? Tudod, mennyire elavult a keretrendszered?
- Emberi tesztelés tesztjegyzőkönyvekkel. Teszteltek valódi emberek előre megírt forgatókönyvek alapján, és dokumentáltad az eredményt, hogy később referenciaként visszanézhesd?
- Monitorozás és audit log. Riasztást kapsz, ha baj van? Utólag visszakereshető, ki mit csinált a rendszerben?
- Magas rendelkezésre állás (HA). Mi történik, ha kiesik egy komponens? Van redundancia, állapotfigyelés, automatikus újraindítás?
- Katasztrófa-helyreállítási (DR) terv. Van mentésed, és ki is próbáltad belőle a visszaállítást? Tudod, mennyi adatvesztést és kiesési időt bír el az üzleted?
Hogyan segítünk?
Ha a kódod megvan, és az élesítés előtt állsz, többféleképpen be tudunk kapcsolódni, attól függően, mennyit szeretnél magad csinálni.
Élesítés előtti átvilágítás. Átnézzük az alkalmazást és a körülötte lévő folyamatokat: statikus kódelemzés, függőségszkennelés, sebezhetőségi teszt a futó rendszeren, az edge-case-ek végiggondolása. Az eredmény egy prioritási sorrendbe tett, közérthető riport arról, mit kell rendbe tenni az élesítés előtt, és mi ráér később.
Élesítési környezet kialakítása. Felépítjük azt, ami hiányzik: automatizált kiadási folyamat, staging környezet, monitorozás, titkosított kulcskezelés, mentés és helyreállítási terv. Ha szeretnéd, az üzemeltetést is átvesszük.
Szakértői tanácsadás. Te fejlesztesz tovább, mi melletted állunk: átnézzük a döntéseidet, segítünk a tesztelésben és a javításokban, és ott vagyunk, ha élesben történik valami.
Hozd el, ami van. Megmondjuk, mi hiányzik ahhoz, hogy valódi felhasználók, valódi pénzzel, biztonságosan használhassák. Lépj velünk kapcsolatba!