Vibe-codeolt MVP: mi hiányzik belőle mindig, mielőtt élesbe mehet

Mit jelent a vibe coding, és miért lett belőle iparág

A kifejezést Andrej Karpathy dobta be 2025 februárjában, és fél év alatt műfaj lett belőle: leírod egy AI-eszköznek, mit szeretnél, elfogadod a kódot, amit visszaad, és megy tovább a beszélgetés. Lovable, Bolt, v0, Cursor, Replit. Egy működő MVP így napok alatt összeáll, olyasmi is, amire két éve még hónapos fejlesztést mondott volna bárki.

Ez a rész valódi érték. Aki vibe codinggal validál egy ötletet, az okosan használja az eszközt: a demó eldönti, kell-e egyáltalán a termék, mielőtt komoly pénz menne bele.

A gond ott kezdődik, amikor a demó élesbe megy. Fizető ügyfél kerül bele, valódi személyes adat, valódi forgalom. A szoftvermentés és modernizálás munkáink jó része pontosan innen indul: az app működik, a felület szép, és a felszín alatt hat dolog hiányzik belőle. Szinte mindig ugyanaz a hat.

Ez a cikk az a lista, amit élesítés előtt magadon is végig tudsz futtatni. Minden ponthoz adunk egy konkrét ellenőrzést. Egy részük tíz perc, és egyikhez sem kell fejlesztőnek lenned.

Egy dolgot érdemes előre tisztázni. A lenti példák egy része a saját kódbázisunkból való, a saját mérnöki naplónkból, méréssel megtalálva és kijavítva. Gondosan épített rendszerekben is születnek ilyen hibák. A különbség az, hogy egy vibe-codeolt appban sűrűbben vannak jelen, és nincs mellettük napló, ami elmondaná, hol keresd őket.

A lista egyben

A hat pont, mielőtt részletesen végigmennénk rajtuk:

1. Hitelesítés. Hány önálló rétegen akad el egy jogosulatlan kérés? Egy réteg kevés.
2. Adat. Az üzleti szabályaid az adatbázisban élnek, vagy csak a kódban? Utóbbi versenyhelyzetben megszakad.
3. Biztonság. Hol vannak a kulcsaid, mit enged a soronkénti jogosultság, és ellenőrzött-e minden bemenet?
4. Mentés. Mi van a backupban, meddig őrződik, és állítottál-e már vissza belőle?
5. Megfigyelhetőség. Ha éjjel eltörik valami, mi szól, és mikor?
6. Tesztek és kapuk. A zöld pipa azt méri-e, aminek a törése pénzbe kerül?

Ha mind a hatra magabiztos igen a válasz, ezt a cikket nyugodtan becsukhatod. A tapasztalatunk szerint generált MVP-nél a hatból négy-öt szokott elvérezni, jellemzően úgy, hogy a tulajdonosa az elsőről sem tud.

1. Hitelesítés: hány rétegen bukik el a betolakodó?

A generált appokban a belépés jellemzően egy rétegen múlik: van egy átirányítás, ami a be nem jelentkezett látogatót a login oldalra küldi. Ez kevés. Az átirányítás a kliensen vagy egy proxy-rétegben fut, és mindkettő megkerülhető: kikapcsolt JavaScript, közvetlen API-hívás, egy félresikerült deploy, és a védett oldal ott van bárki előtt.

A mi szabályunk három réteg, és mindhárom önállóan is tart: a proxy átirányít, a védett layout szerver­oldalon újra ellenőrzi a sessiont, és minden egyes írási művelet a végrehajtás előtt még egyszer megkérdezi, ki a hívó. A proxy csak kényelem. A layout és a mutáció a valódi zár.

Ellenőrzés: jelentkezz ki, tiltsd le a JavaScriptet, és nyisd meg az admin felület URL-jét. Utána böngésző nélkül, curl-lel kérd le ugyanazt. Ha bármelyik válaszban ott az adat, egy rétegen áll az egész rendszered.

Ide tartozik a jelszókezelés és a munkamenet-lejárat is. Ha az app saját jelszótárolást generált magának, nézd meg, mivel hash-eli. Ha nem tudod kideríteni fél óra alatt, az önmagában válasz.

2. Adat: a szabály a kódban él vagy az adatbázisban?

A generált kód tele van olyan szabályokkal, amiket egy ciklus ígér meg: „egy felhasználónak egy előfizetése van", „egy rendelésről egyszer megy ki e-mail". A ciklus be is tartja, amíg egyetlen kérés fut egyszerre. Két egyidejű kérésnél az ígéret megszakad, és születik két előfizetés, két levél, két levonás.

A saját monitoring­rendszerünkben ez konkrétan így nézett ki: azt akartuk, hogy egy incidensről pontosan egy riasztó e-mail menjen ki. Az első változat ezt a küldő kód logikájával ígérte meg. A végleges változatban egy részleges unique index mondja ki az adatbázisban, hogy site-onként és hibatípusonként egyszerre legfeljebb egy nyitott incidens létezhet. Az ígéretből tény lett: ezt az állapotot mostantól a Postgres utasítja vissza, akárhogy fut éppen a kód.

Vibe-codeolt appban ilyen megkötést ritkán találsz, mert a promptban senki nem kéri, és a hiba a demóban sosem jön elő. Éles terhelésnél jön elő, pénzzel.

Ellenőrzés: nyisd meg az adatbázis sémáját, és keresd a UNIQUE, CHECK és FOREIGN KEY sorokat. Ha a tábláidon ezekből alig van valami, akkor minden üzleti szabályod csak a kódban él, és versenyhelyzetben egyik sem garantált. Külön kérdés, hogy léteznek-e migrációs fájlok, vagy a séma kézzel kattintgatva áll össze; utóbbi esetben a sémád jelenlegi állapotát senki nem tudja reprodukálni.

3. Biztonság: kulcsok, jogosultság, bemenet

Három dolgot nézünk meg minden auditban elsőként, mert mindhárom percek alatt ellenőrizhető, és mindhárom rendszeresen nyitva van.

Az első a kulcsok helye. A generált kód hajlamos a legerősebb kulccsal dolgozni, mert azzal minden elsőre működik. Ha az adatbázis admin szintű kulcsa a kliensoldali kódba került, az a teljes adatbázisod nyilvános írási joga. Keresd meg a buildelt JavaScriptben: ha egy service_role vagy hasonló nevű titok szerepel benne, azonnal cserélni kell, és át kell szervezni a hozzáférést.

A második a soronkénti jogosultság. Supabase és társai tudnak row-level securityt; a kérdés az, be van-e kapcsolva minden táblán, és van-e mögötte tényleges szabály. Egy kikapcsolt RLS-ű tábla annyit jelent, hogy aki bármihez hozzáfér, az mindenhez hozzáfér.

A harmadik a bemenet. Minden mező, amibe a felhasználó ír, és ami utána megjelenik valahol, XSS-jelölt; minden webhook, amit külső szolgáltatás hív, aláírás­ellenőrzés nélkül nyitott ajtó. A mi kontakt űrlapunk mögött honeypot, kérésszám­korlát és séma­validálás ül, a webhookjaink pedig a nyers kérés­testen ellenőriznek HMAC-aláírást, még a feldolgozás előtt. Egyik sem bonyolult. Az a baj, hogy a prompt alapján egyik sem születik meg magától.

Ellenőrzés: grepeld végig a repót a kulcsaid értékére, futtasd le, milyen táblákon nincs RLS, és nézd meg, hogy a webhook­kezelőid a feldolgozás előtt vagy után ellenőriznek-e aláírást. Ha nincs kedved ehhez egyedül, az ingyenes AI-audit keretében ránézünk.

4. Mentés: mikor próbáltál utoljára visszaállítani?

A mentés az a pont, ahol a legkevesebb a vita és a legnagyobb a csend. A kérdés nem az, hogy „van-e backup". Három kérdés van: mi van benne, meddig őrződik, és állítottál-e már vissza belőle.

A saját rendszerünkön ez a három kérdés két kellemetlen választ adott, és mindkettőt leírtuk az üzemeltetési dokumentációnkba. Az egyik: a napi adatbázismentés a feltöltött fájlokat egyáltalán nem tartalmazza, mert a tárhely­objektumok nem részei az adatbázis­backupnak; aki nálunk fájlt tölt fel, arról külön mentési útvonal nélkül nincs másolat. A másik: a visszaállítási próbát megírtuk lépésről lépésre, és a checklistünkben a mai napig az áll mellette, hogy „NOT PERFORMED". Amíg egyszer le nem fut, a mentésünk létezése állítás, a visszaállíthatósága nem.

Egy vibe-codeolt appnál jellemzően az első kérdésnél elakad a beszélgetés, mert a hosting alapértelmezett backupján kívül semmi nincs, és senki nem tudja, az mit fed le.

Ellenőrzés: írd le egy sorban, mi történne, ha most azonnal törlődne az adatbázisod. Ha a válaszhoz meg kell nyitnod a szolgáltató dokumentációját, a valódi válasz az, hogy nem tudod.

5. Megfigyelhetőség: látod-e, amikor baj van?

A leggyakoribb éles állapot a néma hiba. Az app fut, a felhasználónál valami nem működik, és erről semmi nem szól senkinek.

Egy példa a saját oldalunkról arra, milyen alattomos ez a kategória. Hónapokig minden nem létező URL-ünk 200-as státuszkóddal válaszolt 404 helyett, mert egy ártatlannak látszó betöltőképernyő-fájl a mögötte lévő oldalakat egy olyan határba csomagolta, ami a választ azelőtt véglegesítette, hogy a „nincs ilyen oldal" ág lefuthatott volna. A látogató a hibaoldalt látta, a keresőrobot sikeres választ kapott. Vizuálisan tökéletes, méréssel azonnal kibukik: egyetlen curl -I megmutatja.

Ugyanebbe a családba tartozik a hibagyűjtés hiánya. Ha nincs bekötve error tracking, a felhasználóid a monitoringod: akkor tudsz meg egy hibáról, amikor valaki veszi a fáradságot és ír. A legtöbben szó nélkül elmennek.

Ellenőrzés: kérj le curl -I-vel egy biztosan nem létező URL-t az appodon, és nézd meg a státuszkódot. Utána válaszolj egy mondatban: ha ma éjjel kivételt dob a fizetési folyamatod, honnan tudod meg, és mikor?

6. Tesztek és kapuk: azt mérik, amit hiszel?

Az utolsó pont kettős. Az első fele egyszerű: generált MVP-ben teszt jellemzően nincs, és a pénzt érintő útvonalakra (regisztráció, fizetés, jogosultság) élesítés előtt minimum kell. A második fele a kényelmetlenebb: a zöld kapu csak azt garantálja, amit tényleg mér.

Erre is van saját esetünk. A fordítási rendszerünk hiányzó szöveg esetén hibadobás helyett a kulcs útvonalát írja ki, ezért három admin képernyőnk úgy került élesbe, hogy a címek helyén adminFiles.sectionTitle jellegű nyers kulcsok álltak, miközben a típusellenőrzés, a lint, a tesztek és a build mind zöldek voltak. Minden kapu átengedte, mert egyik kapu sem ezt mérte. Azóta külön parancs ellenőrzi, hogy minden szövegkulcs mindkét nyelven feloldódik, és ez a parancs a CI kötelező lépése.

A tanulság vibe-codeolt appra hatványozottan igaz: az, hogy „lefordul és elindul", nem minőségi kapu. Az a kérdés, mi az a három-négy dolog, aminek a törése azonnal pénzbe kerül, és van-e olyan automatikus ellenőrzés, ami pont azokat nézi.

Ellenőrzés: van-e a repódban CI-konfiguráció egyáltalán? Ha van, sorold fel, mit futtat. Ha a lista csak „build", akkor a kapud annyit mond: a kód lefordul.

Ráadás: amit csak méréssel látsz

Egy utolsó történet, mert jól mutatja, miért kevés a ránézés. A saját nyitóoldalunkon a 3D-s látvány­elem asztali gépre készült, mobilon egy hidden osztályú konténerben ült, és nem látszott. A csomagja viszont letöltődött minden telefonra: 877 982 byte nyersen, 231 452 byte tömörítve, mert a dinamikus betöltés a komponens mountjához kötődik, a CSS-beli láthatósághoz semmi köze. Fizetett minden mobil látogató egy kb. negyed megabájtos számlát egy elemért, amit soha nem látott. A képernyőn ebből semmi nem látszott; a hálózati fülön az első mérésnél kibukott.

A generált kód tele van ilyen tételekkel, mert a generálásnál senki nem méri, mi megy át a dróton. Élesítés előtt egyszer végig kell mérni: mekkora a kezdő oldal, mi tölt be mobilon, mennyi az LCP. Ide számok kellenek, a benyomás ebben a műfajban rendre téved.

Rendbetétel vagy újraírás?

A hat pont átfutása után jön a valódi döntés: megtartható-e a kódbázis. A jó hír, hogy a válasz gyakrabban igen, mint ahogy elsőre tűnik; a generált kód sokszor rendbe tehető, ha a szerkezete értelmes. A rossz hír, hogy ezt ránézésre senki nem tudja megmondani, mi sem. Ezért nálunk a mentési munka mindig auditból indul, és árat is utána mondunk; a többi szolgáltatásunk kiinduló árait az árak oldalon publikáljuk, fix árat és határidőt pedig írásban, az ajánlatban rögzítünk.

Ha most van egy működő demód és közeledik az éles indulás, futtasd végig rajta a fenti hat ellenőrzést. Ami átmegy, azzal nyertél egy nyugodt éjszakát. Ami elakad, arról írj nekünk, és 24 órán belül megmondjuk, mennyi munka rendbe tenni.