>A kód olcsó lett, az ítélőképesség nem

Van az a pillanat, amikor valaki két nap alatt újraír egy komplett banki rendszert AI-al. Legalábbis ezt mondja róla.

Kívülről ez elég könnyen tűnik abszurdnak. Az ember első reakciója az lenne, hogy jó, akkor most mindenki vegyen egy nagy levegőt, tegyük le a laptopot, és beszéljük át, mit jelent ebben a mondatban az, hogy „komplett”, mit jelent az, hogy „banki”, és mit jelent az, hogy „rendszer”.

De ez a reakció önmagában kevés. Mert közben van a történetnek egy kényelmetlenebb része is: az illető valószínűleg tényleg mutatott valamit, ami működött. Volt képernyő. Volt folyamat. Volt adat. Lehetett kattintani. Lehetett demózni. És ha a főnökei félig komolyan vették, akkor nem csak ő hitte el, hogy történt valami.

Történt is. Csak nem biztos, hogy az történt, aminek elsőre látszik.

Az AI-al támogatott fejlesztés egyik legnagyobb hatása, hogy brutálisan leviszi az első működő verzió árát. Amit régebben specifikálni kellett, fejlesztői kapacitásra kellett tenni, sprintbe kellett illeszteni, majd valahogy kivárni, azt ma egy ügyesebb ember néhány óra vagy néhány nap alatt képernyőre tudja hozni. Nem makettként, nem drótvázként, hanem működőnek tűnő alkalmazásként.

Ez óriási dolog. És szerintem az jár rossz úton, aki ezt megpróbálja lesöpörni azzal, hogy „ez csak játék”, „ez csak bohóckodás”, „ez nem igazi fejlesztés”. Mert sokszor nagyon is igazi. Az AI tud komponenseket írni, adatbázist kezelni, API-t összekötni, jogosultságot imitálni, adminfelületet rajzolni, e-mailt küldeni, dokumentumot generálni, dashboardot építeni.

Aki product oldalról nézi, annak ez felszabadító. Végre nem kell minden ötletet heteken át magyarázni ahhoz, hogy kiderüljön, van-e benne valami. A vibe coding nem hülyeség. Sőt, sok esetben a legjobb módja annak, hogy az ember ne beszéljen túl sokáig a semmiről.

A gond ott kezdődik, amikor a működő első verziót összekeverjük a működtethető rendszerrel.

Egy demó nagyon kevés dolgot vizsgál. Általában egy ember használja, egy ismert útvonalon, előre sejtett adatokkal, jóindulatú környezetben. A demóban nincs igazi terhelés. Nincs hónapok óta gyűlő adat. Nincs tíz párhuzamos felhasználó, aki éppen mást csinál. Nincs audit. Nincs migrációs kényszer. Nincs visszaállás egy félresikerült release után. Nincs olyan ügyféladat, amit nem lett volna szabad látni. Nincs olyan pénzügyi folyamat, ahol egy rosszul kezelt állapotból valódi kár lesz.

Én ezt a saját bőrömön is elég gyorsan megtapasztaltam. Mivel nincs klasszikus fejlesztői múltam, sokszor nem tudom első ránézésre megítélni, hogy egy AI-al összerakott kód mennyire production ready. Azt látom, hogy működik-e. Látom, hogy elindul-e. Látom, hogy meg lehet-e mutatni. És nagyon könnyű ilyenkor azt érezni, hogy ha már ennyire működik, akkor a nehéz részen túl vagyunk.

Aztán elkezdi használni az ember.

Nálam több saját appnál is ott jöttek elő a problémák, ahol a demó már régen sikeres volt. Egy felhasználónál minden szép volt. A válaszidők rendben voltak, az oldalak betöltöttek, a folyamat végigment. Öt felhasználónál már jelentkeztek furcsaságok. Húsznál pedig kiderült, hogy az egész mögött olyan adatbázis-struktúra van, amit nem lehet normálisan skálázni.

És itt jött a legérdekesebb rész: nem arról volt szó, hogy a kód látványosan hibás lett volna. Nem dobált folyamatosan exceptiont. Nem volt tele nyilvánvaló baromsággal. Több másik agent is megnézte, és alapvetően rendben lévőnek ítélte. A prompttal sem az volt a baj, hogy rosszul kértem volna. Egyszerűen arról volt szó, hogy a rendszer olyan irányba nőtt, amely egy darabig elfedte a saját bajait.

Amikor jeleztem a teljesítményproblémát, a megoldás első körben nem az volt, hogy visszamegyünk az adatmodellhez, megnézzük a lekérdezéseket, megértjük a hozzáférési mintákat, és újragondoljuk a struktúrát. Hanem az, hogy prefetch került minden linkre. Ettől a rendszer egy ideig gyorsabbnak tűnt. Csak közben a valódi probléma nem megoldódott, hanem el lett takarva a következő határig.

Aztán a következő határnál már füstölt a szerver.

Kattintásonként száz plusz oldal töltődött be, mindenhol nem jól optimalizált queryk futottak, és mire kiderült, hogy az egész alapja rossz helyen van, már volt benne annyi adat, hogy a migráció önmagában fájdalmas munkává vált. Ez az a pont, ahol egy tapasztalt architect valószínűleg sokkal korábban szólt volna. Nem azért, mert ő gyorsabban gépeli be a kódot. Hanem mert látja, hogy egy döntésből később milyen rendszer következik.

Ez az ítélőképesség nem lett olcsóbb. A kód előállítása lett olcsóbb. Az első verzió lett olcsóbb. A képernyőre kerülés lett olcsóbb. A kipróbálás lett olcsóbb. De annak eldöntése, hogy az így létrejött megoldás milyen terhelést bír, milyen adatmodellre épül, hogyan viselkedik hibás állapotban, mit lehet belőle visszamigrálni, és milyen következménye lesz egy rossz döntésnek, nem lett automatikusan olcsóbb.

Sőt, bizonyos értelemben drágább lett. Régen ugyanis a lassúság valamennyire védett. Ha valamit nehéz volt megépíteni, akkor több ponton kellett átmenni, mire valódi rendszer lett belőle. Ez persze rengeteg fölösleges bürokráciát is jelentett, de volt benne egy természetes fék. Ma ez a fék eltűnt. Egy ember, egy AI-eszköz és néhány este alatt előállhat valami, ami elég jó ahhoz, hogy szervezeti vitát indítson el.

Ez nagyon jó, ha prototípusról beszélünk. És nagyon veszélyes, ha közben mindenki úgy kezd viselkedni, mintha már túl lennénk a mérnöki munkán.

Enterprise környezetben a fejlesztés nagy része nem a látványos képernyőkről szól. Pláne nem banki környezetben. Ott a rendszer értéke sokszor azokban a rétegekben van, amelyeket a demóban senki nem lát. Jogosultsági modellben. Audit trailben. Naplózásban. Visszakövethetőségben. Adatkonzisztenciában. Hibakezelésben. Terhelhetőségben. Release-folyamatban. Monitoringban. Security review-ban. Abban, hogy ha valami félremegy, akkor nem csak annyit tudunk mondani, hogy „érdekes, nálam működött”.

Ezeket az AI nem fogja magától teljesen megoldani csak azért, mert megkérjük, hogy írjon production ready kódot.

Ez a „production ready” kifejezés amúgy is becsapós. Úgy hangzik, mintha egy minőségi kapcsoló lenne a kódban. Mintha ugyanazt a feladatot meg lehetne kérni kétféleképp: egyszer gyorsan, egyszer production ready módon. Nyilván lehet jobb promptot írni. Lehet kérni teszteket, loggingot, indexeket, hibakezelést, security szempontokat. Ezek mind számítanak. De ettől még az AI csak abból dolgozik, amit valahogy megkap.

Tudni kell, milyen adatok lesznek benne. Kik használják. Milyen gyakran. Milyen jogosultsági határok vannak. Mit kell auditálni. Mi történik, ha egy folyamat félbeszakad. Mi a legrosszabb adatállapot, ami előfordulhat. Melyik régi rendszerrel kell együtt élnie. Mi az, amit jogilag nem lehet csak úgy törölni. Mi az, amit üzletileg nem lehet elveszíteni. És mi az, amit három hónap múlva is érteni kell, amikor már senki nem emlékszik az eredeti promptokra.

Ezt nem azért mondom, hogy visszategyük a fejlesztőket valami romantikus, érinthetetlen helyre. Sőt. Szerintem a fejlesztők szerepe is változik. Ha az AI leveszi a vállukról az ismétlődő kódolás egy részét, akkor még kevésbé lesz védhető az a fejlesztői munka, amely csak ticketek mechanikus ledarálásából áll. Az „én írom a kódot, tehát enyém a tudás” pozíció gyengülni fog.

De ettől nem az következik, hogy nem kell fejlesztő. Hanem az, hogy még fontosabb lesz, milyen fejlesztő kell.

Olyan ember kell, aki érti a rendszert, nem csak a syntaxot. Aki nem sértődik meg azon, hogy az első verziót már nem ő írta. Aki nem azzal kezdi, hogy „ezt ki kell dobni”, csak mert AI-al készült. De nem is engedi át productionbe csak azért, mert látványosan működik. Aki képes azt mondani: ez jó prototípus, ezt érdemes továbbvinni, de az adatmodellhez hozzá kell nyúlni, a jogosultságot újra kell gondolni, a queryket mérni kell, a migrációs utat meg kell tervezni, és előbb beszéljünk arról, mi történik, ha ezt ötven ember használja egyszerre.

A vibe coding tehát nem a fejlesztés ellensége. Inkább egy új bejárat a fejlesztésbe.

Az első verziót olyan emberek is meg tudják csinálni, akik korábban legfeljebb specifikációt írtak hozzá. Ez óriási változás product oldalon. Sokkal gyorsabban lehet ötletet próbálni, folyamatot modellezni, belső eszközt összerakni, ügyfélélményt megmutatni. Rengeteg rossz ötlet hamarabb bukhat meg, és rengeteg jó ötlet hamarabb kaphat formát.

Csak közben ki kell mondani, hogy a vibe coding nem ugyanazt a kérdést válaszolja meg, mint az enterprise engineering. Az egyik azt kérdezi: el tudjuk-e képzelni működés közben? A másik azt kérdezi: rá merjük-e bízni a működésünket? A kettő között pedig nem egy kis polírozás van, hanem sokszor maga a szakma.

Szerintem ez lesz a következő évek egyik kellemetlen szervezeti konfliktusa. Az üzleti oldal látni fogja, hogy amit eddig hónapokig tartott megkapni, abból most két nap alatt van valami. A fejlesztői oldal látni fogja, hogy ez a valami tele van rejtett kockázatokkal. Mindkét oldalnak igaza lesz valamiben, és mindkét oldal hajlamos lesz rosszul érvelni.

Az üzleti oldal ott fog tévedni, ha azt hiszi, hogy a működő demó leleplezte a fejlesztők fölöslegességét. A fejlesztői oldal ott fog tévedni, ha azt hiszi, hogy a rejtett kockázatokra hivatkozva továbbra is ugyanúgy lehet lassan, zártan és nehezen hozzáférhetően dolgozni, mint korábban.

A jó válasz valahol középen van, de nem kényelmes kompromisszumként. Inkább új munkamegosztásként. Az AI-al készült első verzió legyen természetes része a gondolkodásnak. Legyen prototípus, vitaanyag, belső eszköz, product discovery, validáció. De amikor rendszer lesz belőle, akkor lépjen be az a szakmai réteg, amely nem a képernyőt nézi, hanem a következményeket.

Mert a kód ma már tényleg olcsóbb. Az első verzió sokszor szinte zavarba ejtően olcsó. Egy húsz dolláros előfizetés, pár jól megírt prompt, néhány óra makacsság, és ott van valami, amire régen külön projektet kellett volna nyitni. Ezt nem érdemes tagadni, mert aki tagadja, az elveszíti a vitát azokkal szemben, akik már használják.

De az ítélőképesség nem lett olcsóbb. A felelősség nem lett olcsóbb. A rossz adatmodell későbbi ára nem lett olcsóbb. A migráció nem lett olcsóbb. A security incidens nem lett olcsóbb. Az audit előtt előkerülő hiányzó döntési napló nem lett olcsóbb. Az a pillanat sem lett olcsóbb, amikor egy szervezet rájön, hogy amit gyors prototípusnak hitt, arra közben elkezdett működést építeni.

A kérdés ezért nem az, hogy lehet-e AI-al rendszert írni. Lehet. A kérdés az, hogy mikor vesszük észre: amit az AI olcsón adott, abból csak akkor lesz valódi rendszer, ha valaki drágán gondolkodik róla.