A vibe coding – amikor promptokkal generáltatod a kódot, és nem olvasod el, csak azt nézed, működik-e – prototípusra kiváló, termékre önmagában nem elég. A generált kód sokszor tényleg fut, de közben biztonsági réseket, következetlen szerkezetet és technikai adósságot hordoz, amit valakinek később érteni, javítani és üzemeltetni kell. Nálunk az AI gyorsít, de minden sort ember néz át, aki felel is érte.
Ezt nem AI-szkeptikusként írjuk: mi is naponta használunk kódgeneráló eszközöket. Épp ezért látjuk, hol ér véget a „pár este alatt összeraktam” és hol kezdődik az, amire ügyfeleket, adatokat és fizetéseket lehet bízni.
- A vibe coding ötletek kipróbálására és belső eszközökre jó. A kifejezést kitaláló Andrej Karpathy is eldobható hétvégi projektekre értette.
- A Veracode 100+ nyelvi modellt vizsgáló tesztjeiben a generált kód az esetek 45%-ában tartalmazott biztonsági hibát, és ez az újabb modellekkel sem javult.
- A modellek nem létező csomagneveket is kitalálnak, amit támadók kihasználhatnak (slopsquatting).
- A legnagyobb költség nem a hiba, hanem az, hogy senki sem érti a kódot, amikor hozzá kell nyúlni.
- Az AI maradjon gyorsító: ember dönt az architektúráról, ember nézi át a diffet, és az agent nem kap éles hozzáférést.
Mit jelent pontosan a vibe coding, és mire jó?
A kifejezés Andrej Karpathytól származik, aki 2025 februárjában egy X-bejegyzésben úgy írta le, mint egy új kódolási módot, ahol teljesen átadod magad a hangulatnak, és elfelejted, hogy a kód egyáltalán létezik. Fontos részlet, hogy ő maga eldobható hétvégi projektekre szánta, nem éles rendszerekre. Azóta a szó jelentése kitágult, és sokan bármilyen promptvezérelt fejlesztést így hívnak.
Mi két dolgot választunk szét:
- Vibe coding: a kódot nem olvasod el, a hibaüzenetet visszamásolod a promptba, és addig ismétled, amíg „jó lesz”.
- AI-asszisztált fejlesztés: az AI javasol, ír, refaktorál, de egy fejlesztő érti, átnézi és vállalja a végeredményt.
Az első teljesen legitim, ha a tét kicsi: kattintható demó egy befektetőnek, egy ötlet gyors validálása, egy belső szkript, ami egy táblázatot rendez át. Ha kidobod, semmi baj. A gond ott kezdődik, amikor a demóból csendben termék lesz.
Miért nem elég, ha a kód „működik”?
Mert a „működik” általában annyit jelent, hogy a boldog úton működik: helyes adatokkal, egy felhasználóval, a fejlesztő gépén. Egy termék ennél sokkal többet kell bírjon.
| Kérdés | Prototípus | Termék |
|---|---|---|
| Ki látja az adatokat? | Mindenki, aki tudja a linket | Csak akinek jogosultsága van |
| Mi történik hibás bemenetnél? | Összeomlik vagy furcsán viselkedik | Érthető hibaüzenet, naplózás |
| Hogyan változik az adatbázis? | Újragenerálod | Migráció, visszaállítható mentés |
| Ki tudja javítani fél év múlva? | Aki emlékszik a promptokra | Bárki, aki olvassa a kódot és a teszteket |
A generált kód ezeket a kérdéseket nem kérdezi meg magától. Ha te sem, akkor senki.
Milyen biztonsági kockázatokat hoz a vibe coding?
Nem biztonságos alapértelmezések
A Veracode 2025-ös GenAI Code Security Reportja 80 kódolási feladatot futtatott le több mint 100 nyelvi modellen Java, JavaScript, Python és C# nyelven. Az eredmény: a generált kód az esetek 45%-ában biztonsági hibát vitt be, vagyis amikor volt biztonságos és nem biztonságos megoldás is, a modell ennyiszer az utóbbit választotta. A sajtóközlemény szerint a cross-site scripting (XSS) típusú hibák 86%-ánál a modellek nem védekeztek, és miközben a szintaktikai helyesség javult, a biztonsági teljesítmény az idővel nem változott.
Hiányzó jogosultságkezelés
A CVE-2025-48757 a Lovable platformmal generált oldalakat érintette: a nem megfelelő Row-Level Security (RLS) szabályok miatt hitelesítés nélkül lehetett olvasni és írni az adatbázistáblákat. A Lovable vitatja a besorolást, azzal érvelve, hogy az alkalmazás adatainak védelme a felhasználó felelőssége. Ebben igazuk van, és pont ez a lényeg: a felelősség nálad marad akkor is, ha a kódot nem te írtad.
Kitalált csomagok
A modellek néha olyan függőséget importálnak, ami nem is létezik. Spracklen és társai kutatása (USENIX Security 2025) szerint ez kereskedelmi modelleknél 5,2%, nyílt modelleknél 21,7% körüli arányban fordult elő. Ha egy támadó regisztrálja a kitalált nevet egy rosszindulatú csomaggal, a következő npm install már az ő kódját futtatja. Ezt hívják slopsquattingnak. Egy 2026-os utánkövetés szerint az újabb modelleknél szűkült a sáv, de a kockázat megmaradt.
Agent éles hozzáféréssel
2025 júliusában Jason Lemkin, a SaaStr alapítója nyilvánosan dokumentálta, hogy a Replit AI-agentje egy kódbefagyasztás alatt, kifejezett tiltás ellenére törölte az éles adatbázisát. Nem az a tanulság, hogy egy eszköz rossz, hanem hogy egy agent pontosan annyi kárt tud okozni, amennyi jogot kap.
Hogyan lesz a gyors kódból technikai adósság?
A biztonsági hiba legalább kideríthető. A nehezebb probléma az, hogy a promptonként generált kódbázis nem egy fejből születik. Gyakran ugyanazt a feladatot három helyen háromféleképp oldja meg, a hibakezelés hol van, hol nincs, és a modell a következő kérésnél szívesebben ír új kódot, mint hogy a meglévőt rendbe tegye. Teszt jellemzően csak akkor készül, ha kéred.
Az eredmény az, amit mi megértési adósságnak hívunk: van egy működő rendszer, de senki sem tudja megmondani, miért működik, és mi romlik el, ha egy sort átírsz. Ilyenkor minden új funkció lassabb és kockázatosabb, mert előbb a meglévő kódot kell visszafejteni.
Az érzett gyorsaság ráadásul csalóka lehet. A METR randomizált kísérletében 16 tapasztalt nyílt forráskódú fejlesztő 246 valós feladaton dolgozott, saját, jól ismert kódbázisán. AI-eszközökkel 19%-kal tovább tartott a munka, miközben utólag úgy becsülték, hogy 20%-kal gyorsabbak voltak. A METR maga is hangsúlyozza, hogy ez a 2025 eleji eszközökre vonatkozik, és nem általánosítható minden helyzetre. A tanulság nálunk mégis megmaradt: amit nem mérsz, azt könnyű túlbecsülni.
Hogyan használjuk mi az AI-t fejlesztés közben?
Nem tiltjuk, hanem keretet adunk neki. A mi szabályaink:
- Az architektúráról ember dönt. Adatmodell, jogosultságok, integrációk: ezeket nem promptból találjuk ki.
- Minden diffet elolvasunk. Ha nem értjük, nem kerül be.
- A kritikus utakra teszt kerül: bejelentkezés, fizetés, rendelés, adatexport.
- Minden új függőséget ellenőrzünk: létezik-e, karbantartják-e, kell-e egyáltalán.
- Az agent nem kap éles hozzáférést, és nem lát titkos kulcsokat.
- Hitelesítésnél és fizetésnél külön biztonsági átnézés van.
Ha már van egy vibe codinggal épült MVP-d, és kezd komolyra fordulni, ezt a sorrendet javasoljuk:
- Térképezd fel, hol vannak a személyes és fizetési adatok, és ki fér hozzájuk.
- Ellenőrizd az adatbázis-szabályokat (például RLS) és a kódban vagy a repóban maradt kulcsokat.
- Írj teszteket a pénzt hozó folyamatokra, mielőtt bármit átírsz.
- Nézd át a függőségeket.
- Csak ezután dönts: refaktorálás vagy újraírás. Néha az MVP legnagyobb értéke a validált ötlet, nem a kód.
Ha a pénzügyi oldaláról is gondolkodnál, hogy hol éri meg AI-ra építeni, arról az AI a vállalkozásodban 2026-ban cikkünkben írtunk.
Gyakori kérdések
Lehet vibe codinggal MVP-t építeni?
Igen, ötlet validálására kifejezetten jó. Csak legyen világos, hogy prototípus, és mielőtt valódi felhasználói adat kerül bele, valaki nézze át a jogosultságokat és a biztonságot.
Az újabb modellek már biztonságos kódot írnak?
Jobban írnak kódot, de a Veracode mérése szerint a biztonsági teljesítményük nem javult a szintaktikai helyességgel együtt. A felülvizsgálatot nem váltja ki egy jobb modell.
Mi a különbség a vibe coding és az AI-asszisztált fejlesztés között?
Az, hogy van-e valaki, aki érti és vállalja a kódot. Ugyanaz az eszköz mindkettőre használható, a különbség a folyamatban van: átnézés, tesztek, jogosultságok.
Átvesztek AI-jal generált projektet?
Igen. Először felmérjük, mi van benne és mi a kockázat, és csak utána mondjuk meg, hogy javítani vagy újraépíteni érdemes.
Ha egy prototípusból terméket építenél, vagy egy meglévő, gyorsan összerakott rendszert tennél rendbe, nézd meg, hogyan dolgozunk az egyedi szoftverfejlesztésnél. Egy app, webshop és weboldal együttes felépítését a G8 Alakváltók esettanulmányban mutatjuk be.