A vibe coding valódi veszélyei: hibák, amelyek akkor is pénzbe kerülnek, ha az alkalmazás működik
Röviden
Egy korábbi cikkben már írtam arról, hogy a vibe coding gyors, de veszélyes tud lenni megfelelő szakmai ellenőrzés nélkül. Ott két példát mutattam be részletesen: a hiányzó ÁSZF-et vagy adatkezelési tájékoztatót, és a kiszivárgott API-kulcsokat. Ha ezt még nem olvastad, itt éred el: Ezt kell tudnod, mielőtt saját szoftvert készítesz AI-jal.
Ez a cikk azt folytatja, amit ott ígértem: további olyan hibákat mutat be, amiket a vibe coding könnyen kihagy. A közös bennük, hogy egyik sem azon bukik le, hogy egy gomb nem működik. Az alkalmazás elsőre tökéletesen működhet, a hiba mégis pénzbe kerül: egy váratlan API-számla, egy adatvédelmi bírság, egy fizetés nélkül megszerzett előfizetés vagy egy hónapról hónapra növekvő szerverköltség formájában.
API-kulcsok nincsenek rejtve
Erről már részletesen írtam az előző cikkben, itt csak röviden összefoglalom. A titkos, szerveroldali API-kulcs — például egy OpenAI vagy egy éles Stripe kulcs — nem kerülhet a kliensoldali kódba vagy egy nyilvánosan elérhető fájlba. Ha kiszivárog, valaki a te nevedben, a te költségedre használhatja a szolgáltatást, vagy hozzáférhet olyan adatokhoz, amikhez nem lenne szabad.
A teljes magyarázatot és a konkrét példákat itt olvashatod: Vibe coding veszélyei.
Helytelen jogosultságkezelés
A jogosultságkezelés azt dönti el, hogy egy bejelentkezett felhasználó ténylegesen hozzáférhet-e egy adott adathoz vagy funkcióhoz, nem csak azt, hogy be van-e jelentkezve. Ez a két dolog nem ugyanaz, és a vibe coding gyakran csak az elsőt oldja meg.
Egy egyszerű promptból induló alkalmazásnál könnyen előfordul, hogy a backend minden bejelentkezett felhasználónak megengedi egy adott végpont elérését, de nem ellenőrzi, hogy az adott sor, fájl vagy megrendelés valóban az övé-e. Ilyenkor elég a kérésben szereplő azonosítót átírni, és máris más felhasználó profiljához, dokumentumaihoz vagy számlájához lehet hozzáférni, sőt akár módosítani vagy törölni is azt.
A következmény nem elméleti. Ha személyes adatok érintettek, ez a GDPR szerint adatvédelmi incidens, amit be kell jelenteni, és amiért a hatóság akár 20 millió eurós, vagy az éves árbevétel 4%-ának megfelelő bírságot is kiszabhat. Ehhez jön a bizalomvesztés, ami hosszú távon ugyanúgy bevételkiesés.
Nyilvánosan elérhető adatbázis vagy fájltár
Ez a hiba gyakran nem is a kódban van, hanem a háttérszolgáltatás beállításában. Egy adatbázis vagy egy cloud storage alapértelmezett hozzáférési szabályai néha megengedőbbek, mint amit egy éles alkalmazásnál szabadna, és egy vibe codeolt projektnél ezt könnyen elfelejtik szigorítani.
Ha ez történik, a felhasználói adatok, a feltöltött fájlok, a számlák vagy akár a belső dokumentumok is elérhetők lehetnek bárki számára, aki tudja a megfelelő linket vagy végpontot, bejelentkezés nélkül.
A következmény ugyanaz, mint a jogosultsági hibánál: adatvédelmi incidens, bejelentési kötelezettség, bírság és bizalomvesztés. A különbség csak annyi, hogy itt a hibát nem elég a kódban javítani, a szolgáltatás konfigurációját is át kell nézni.
Hiányzó rate limit
A rate limit korlátozza, hogy egy felhasználó vagy IP-cím hányszor hívhat meg egy funkciót adott idő alatt. Bejelentkezés, jelszó-visszaállítás, email- vagy SMS-küldés, egy AI-funkció vagy akár egy egyszerű űrlap is ide tartozik, és a vibe coding ezt szinte sosem oldja meg magától, mert elsőre nem is látszik, hogy hiányzik.
Korlátozás nélkül egy automatizált script percek alatt eljuttathat több ezer kérést az alkalmazáshoz. Ha ez egy AI-funkciót hív meg, a te API-kulcsod fizeti a hívásokat. Ha email- vagy SMS-küldést indít el, a levelezőszolgáltatód vagy SMS-providered ugyanezt számlázza ki neked, akár néhány óra alatt is jelentős összeget.
Ugyanez a hiányzó korlátozás teszi lehetővé a spamet, illetve a jelszavak vagy kódok automatikus próbálgatását is, ami már közvetlenül biztonsági kockázat, nem csak költség.
Hibás fizetési visszaigazolás
A legtöbb fizetési folyamat úgy néz ki, hogy a felhasználó a fizetési szolgáltatónál fizet, majd visszairányítják egy „sikeres fizetés” oldalra. A hiba akkor történik, ha az alkalmazás csak ennek az oldalnak a betöltését tekinti bizonyítéknak, és nem ellenőrzi a fizetési szolgáltató szerveroldali visszaigazolását.
Ez a visszairányítás a böngészőben, kliensoldalon történik, amit meg lehet kerülni. Ha valaki egyszerűen rááll a „sikeres fizetés” URL-re, vagy megszakítja a fizetést a visszairányítás előtt, fizetés nélkül is hozzáférhet egy előfizetéshez, termékhez vagy prémium funkcióhoz.
A megbízható megoldás, hogy az alkalmazás a fizetési szolgáltató (például Stripe) szerveroldali webhookját várja meg és ellenőrzi a hozzá tartozó aláírással, és csak ez alapján ad hozzáférést, nem a böngésző visszairányítása alapján.
Nem frissített könyvtárak és függőségek
Az AI-fejlesztő eszközök gyakran régi kódpéldákból vagy már elavult dokumentációból dolgoznak. Ennek eredménye lehet egy olyan könyvtár- vagy csomagverzió, amelyben már ismert, kijavított biztonsági rés van, csak épp a projekt egy korábbi, sérülékeny verziót használ belőle.
Ez fejlesztéskor nem tűnik fel, hiszen az alkalmazás ugyanúgy működik. A probléma később jön elő: egy biztonsági incidens esetén nem elég a hibát kijavítani, ki kell deríteni, mi szivárgott ki, értesíteni kell az érintetteket, és sok esetben ez is hatósági bejelentési kötelezettséggel jár.
Ezért a technológiákat, könyvtárakat és integrációkat nem elég egyszer megválasztani, később is rendszeresen ellenőrizni és frissíteni kell őket.
Tervezési döntések, amik szintén pénzbe kerülnek
Az eddigi hibák biztonsági vagy jogi kockázatok voltak. Van azonban három olyan tervezési döntés is, ami nem biztonsági rés, mégis közvetlenül az üzemeltetési költséget vagy az alkalmazás üzleti eredményét rontja, és a vibe coding ezekre szinte sosem tér ki magától, mert egyik sem szükséges ahhoz, hogy az alkalmazás „működjön”.
SSR mindenhol, SSG vagy ISR helyett
Egy oldal többféleképpen épülhet fel: statikusan, előre legenerálva (SSG); rendszeres időközönként újragenerálva (ISR); vagy minden egyes látogatáskor újra, a szerveren (SSR). Az AI-eszközök gyakran az utóbbit, az SSR-t választják alapértelmezettként minden oldalhoz, mert az a legegyszerűbb megoldás, nem azért, mert az adott oldalnak arra lenne szüksége.
Ha egy tartalom nem változik minden másodpercben, nincs szükség rá, hogy minden egyes látogatónál újra lefusson a teljes szerveroldali renderelés. Ez feleslegesen leköti a szervert, ami nagyobb terhelésnél magasabb hosting- vagy compute-számlát jelent, és lassabb betöltést is okoz azoknál az oldalaknál, ahol egyébként simán lehetne statikus vagy időszakosan frissülő verziót használni.
Az adatok nem kerülnek cache-be
Ha egy alkalmazás minden egyes kéréshez újra lekérdezi ugyanazt az adatot az adatbázisból vagy egy külső API-tól, ahelyett hogy egy rövid ideig eltárolná és onnan szolgálná ki, az feleslegesen sok erőforrást és API-hívást használ el.
Ez sok látogatónál vagy gyakran hívott AI-funkciónál különösen érezhető: minden ismétlődő kérés külön adatbázis-terhelés vagy külön API-költség, miközben a válasz legtöbbször ugyanaz lenne cache-ből is.
Nincs optimista UI rendering
Ez a technika interaktív felületeken segít: valójában nem gyorsítja fel az alkalmazás működését, mégis ettől érződnek „instant” sebességűnek a jó alkalmazások.
Ha Instagramon like-olsz egy bejegyzést, nincs töltés, a like azonnal regisztráltnak látszik. Ez nem azért van, mert ennyire gyors a szerver, hanem mert a felhasználói oldal azonnal sikeresként jelzi a műveletet, még mielőtt a szerver ténylegesen elmentette volna. Csak ezután küldi el az adatot a szervernek, ami elmenti, és visszajelez, hogy sikeres volt-e. Ha igen, nem történik semmi látható; ha nem, a like eltűnik. Ha már láttál olyat, hogy egy like pár másodperc után magától visszavonódott, pontosan ez történt.
Optimista UI nélkül minden interakció töltésre vár, ami lassúnak és amatőrnek hat, még akkor is, ha technikailag minden rendben működik. Ez közvetlenül nem kerül pénzbe, de a gyengébb élmény rontja a konverziót és a visszatérést, ami hosszabb távon ugyanúgy bevételt jelent.
Összefoglalva
Egyik itt bemutatott hiba sem látszik azon, hogy megnyitod az alkalmazást. Mind a kilenc azután derül ki, amikor már fizetni kell értük: egy váratlan API-számlával, egy hatósági eljárással, egy elvesztett előfizetéssel vagy egy folyamatosan növekvő szerverköltséggel.
A vibe coding jó eszköz egy ötlet gyors kipróbálására. Amint viszont valódi felhasználók, adatok vagy fizetés kerül a rendszerbe, ugyanaz igaz, mint az előző cikkben: a sebesség nem helyettesíti a hozzáértést és az ellenőrzést.
Ezekhez a kockázatokhoz 2026 augusztusától egy új réteg is társult: az EU AI-rendelete. Ha AI-funkciót — chatbotot, tartalomgenerálást — építesz az alkalmazásodba, arra is érdemes odafigyelni: Új EU AI-szabályok: mit jelent ez, ha AI-jal fejlesztesz?.