Miért nem elég a "vibe coding" egy valódi termékhez

Volt egy hétvége, amikor egy alapító megmutatta, amit épített. AI segítségével, nulláról indult, és két nap alatt működő webalkalmazása lett. Bejelentkezés, irányítópult, adatok mentése – minden megvolt. Nem volt informatikai diplomája, nem járt bootcampre, csak egy jó ötlete volt és tudott promptidezni.

Aztán megkérdezte, hogy segítsek neki eljuttatni a terméket a valódi felhasználókig.

Onnantól kezdődött az érdekes rész.

A prototípus és a valóság közötti szakadék

A prototípus azért működött, mert ő volt az egyetlen felhasználó. Ahogy megpróbáltunk hozzáadni egy második embert, rögtön előjöttek aConcurrency hibák. Az adatbázisnak nem volt migrációs sémája, szóval egy visszaállítás elpusztította volna az adatokat. Nem voltak tesztek, tehát bármilyen refaktorálás olyan volt, mintha vakon próbálnál robbanószert hatástalanítani. És a deployolás egy kézi folyamat volt, nulladik dokumentációval.

A hétvégi projektje remek bizonyíték volt arra, hogy az ötlete működik. De nem volt production-ready szoftver.

És itt van az a rész, amit a "vibe coding" körüli diskurzus folyton figyelmen kívül hagy. Az eszközök valódiak. A sebesség valódi. A szoftverkészítés demokratizálása tényleg izgalmas. De van egy különbség a kódgenerálás és a szoftvermérnöközés között. És ez a különbség sokkal fontosabb, mint amilyennek a legtöbb ember gondolja – egészen addig, amíg hajnali háromkor nem áll egy incidens kellős közepén.

Az az egy metrika, ami számít

Van egy kérdés, amit folyton felteszek, amikor AI által generált kóddal találkozom: biztonságosan beolvasztható-e egy megosztott codebase-be?

Nem "működik-e". Nem "a demo működött-e". Biztonságosan beolvasztható. Ebben a szóban rengeteg súly van. Ez azt jelenti, hogy a kódot át tudja nézni valaki, aki nem írta. Azt jelenti, hogy a tesztek a viselkedést ellenőrzik, nem csak azt, hogy a kód nem crashel. Azt jelenti, hogy a rollback lehetséges adatvesztés nélkül. Azt jelenti, hogy a változtatás elég szűk ahhoz, hogy meg lehessen érteni és el lehessen magyarázni.

Amikor egy vibe coder sikert mér, általában azt méri, mennyi idő alatt lett első működő verzió. Ez egy hasznos metrika discovery és prototípus készítéshez. De amint a szoftver megosztott környezetbe kerül, ez a metrika használhatatlanná válik. Most már az a kérdés, mennyi idő alatt lehet biztonságosan beolvasztani – és ebbe beletartozik a code review költsége, a tesztek minősége, a deploy kockázata, a koordinációs overhead és a jövőbeli karbantartási teher.

Egy szoftvermérnök az elejétől kezdve az egész életciklusra gondol. Egy vibe coder gyakran csak később szembesül ezekkel a szempontokkal, amikor már sokkal többe kerül őket kezelni.

Kódgenerálás vs. Kódtulajdonlás

Van egy finom, de kritikus eltolódás, ami bekövetkezik, amikor az AI generálja a kódod. A kimenet még nem a te munkád. Ez egy kiindulópont, amit át kell alakítani valamivé, amit ténylegesen tulajdonolsz.

A tulajdonlás több dolgot jelent. El tudod magyarázni minden jelentős döntést a változtatásban. Érted, miért létezik minden fájl és mit csinál. Szűkíteni tudtad a változtatást arra, amire kellett, felesleges boilerplate vagy nem kapcsolódó takarítás nélkül. Írtál vagy ellenőriztél teszteket, amik a viselkedést ellenőrzik, nem csak a coverage metrikákat. Végiggondoltad a rollback utat.

Ez az a munka, amit az AI nem tud helyetted elvégezni. Az AI generál. Te döntesz. És a "döntesz" azt jelenti, hogy végiggondoltad az alternatívákat, mérlegelted az előnyöket és hátrányokat, és megértetted a következményeket.

Amikor AI által generált kódot nézek, ami nincs megfelelően tulajdonolva, gyakran ugyanazokat a problémákat látom. Változtatások, amik túl nagyok, mert a modell többet generált a szükségesnél. Package-ek, amiket indoklás nélkül adtak hozzá. Tesztek, amik úgy néznek ki, mintha coverage eszközt elégítenének ki, nem pedig valódi hibákat fognának. Boilerplate, ami azért létezik, mert a modell az alapértelmezett scaffoldingot választotta az egyszerűség helyett.

Ezek egyike sem az AI hibája. Az eredményei annak, hogy a szerző a generált kimenetet előrehaladásnak tekintette, nem pedig nyersanyagnak.

A review probléma, amiről senki nem beszél

Van valami, ami éjszakákon át ébren tart: az AI által generált kód megváltoztatja a code review egyenletet.

Amikor egy emberi mérnök ír kódot, általában van egy döntési nyomvonal. Lehet, hogy nem értesz egyet a választásaival, de legalább vannak választások. Megkérdezheted, miért azt az absztrakciót használta, miért ott van a validáció, miért azt a libraryt választotta. A válaszok lehetnek "nem gondoltam erre" vagy "reálisnak tűnt akkor", de legalább van egy ember, akit meg lehet kérdezni.

Az AI által generált kóddal néhány "döntés" nem is döntés egyáltalán. Ezek completions. A modell egy mintát választott, mert statisztikailag valószínű volt, nem pedig azért, mert illett a problémádhoz. És ha a szerző nem alakította át azt a completion tulajdonolt munkává, a review sokkal nehezebb problémává válik.

Nem kérdezheted meg a modellt, miért azt a megközelítést választotta. Nem kérdezheted meg a szerzőt, miért hozta azt a döntést, ha valójában nem tudja. Szóval a review vagy fájdalmas trial and error-en keresztül hoz felszínre problémákat, vagy egyáltalán nem történik meg.

Ezért hiszem, hogy a legfontosabb készség az AI-asszisztált fejlesztés korában nem a promptolás. Ez a képesség, hogy a generált kimenetet átvedd olyan kóddá, amit elég mélyen értesz ahhoz, hogy tulajdonolj, elmagyarázz és karbantarts.

Mit jelent ez a csapatodnak?

Ha prototípust építesz, hogy tesztelj egy ötletet, a vibe coding legitim megközelítés. A tanulási sebesség számít, amikor még feltételezéseket validálsz. Használd az eszközöket, mozogj gyorsan, építs valamit, amit meg tudsz mutatni az embereknek.

De ha az a prototípus valódi termékké fog válni, valahol a generált kódnak át kell mennie egy olyan ember kezén, aki mérnökként gondolkodik. Nem azért, hogy gatekeepeljen. Nem azért, hogy lassítson. Hanem azért, hogy biztosítsa: ami kiszállításra kerül, az olyan kód, amit a csapat meg tud érteni, karban tud tartani, és tud neki biztonságban megbízni.

A NameOceannál folyton ezt a mintát látjuk. Startupok, amik gyorsan mozognak AI eszközökkel, hogy validálják az ötleteiket, aztán falba ütköznek, amikor skálázniuk kell. A jó csapatok behoznak mérnöki segítséget abban a pontban. A rosszak pedig folytatják a feature-ök pakolását egy codebase-re, amit senki sem igazán ért.

A cél nem az, hogy elkerüld az AI-asszisztált fejlesztést. A cél az, hogy őszinte légy afelől, hol kezdődik és hol ér véget a munka. Az AI kódot generálhat. Neked kell szoftvert mérnökölnöd.

A lényeg

A vibe coding fantasztikus kiindulópont. Ez egy módja annak, hogy gyorsan tesztelj ötleteket, megtanuld, mi lehetséges, és koncepcióból valami kézzelfoghatóba juss hónapok hagyományos fejlesztés nélkül.

De a szoftvermérnöközés az egész életciklusról szól. Arról, hogy a kódot a csapatod át tudja nézni, karban tudja tartani, és tud benne bízni, amikor hajnali kettőkor baj van. A változtatásokról, amik elég szűkek ahhoz, hogy meg lehessen érteni őket, és szükség esetén vissza lehessen őket vonni. A felelősségvállalásról a döntésekért, még akkor is, ha azokat a döntéseket AI javaslatok informálták.

A legjobb fejlesztők, akiket ismerek, intenzíven használják az AI eszközöket. Csak nyitott szemmel teszik. Tudják, hogy a generált kód nyersanyag, nem késztermék. És tudják, hogy valakinek egyszer el kell végeznie azt a mérnöki munkát, ami a különbséget jelenti egy menő demo és egy olyan szoftver között, amit ténylegesen ki lehet szállítani.

Szóval igen, csináld bátran a vibe codingot. Építs gyorsan, kísérletezz szabadon, használj minden elérhető eszközt. Csak tudd, mikor jön el az idő, hogy váltani kell a vibe-ról a mérnöközésre. A jövőbeli önmagad és a jövőbeli csapatod meg fogja köszönni.