A vibe coding kockázatai
Miért jár drága következményekkel az olcsó fejlesztés
- AI az üzletben
Egy alkalmazást ma elég körülírni hétköznapi nyelven, és pár perc múlva már működik is. Ennek a gyorsaságnak az ára később jelentkezik abban a rétegben, amely a nyelvi modell számára láthatatlan marad.
A refaktorálás, vagyis a meglévő kód rendbetétele és újrahasznosítása, lassan eltűnik a kódbázisokból. A GitClear kódelemzése szerint 2023 óta 70%-kal ritkult, miközben a kódmásolás 41%-kal gyakoribb lett. Az így összerakott szoftver az átadás napján működik, a későbbi módosítás ára viszont magasabb.
Egy középvállalatnál ez gyorsan gyakorlati kérdéssé válhat. A csapatod egy hét alatt összerak egy rendszert, amire korábban egy negyedév kellett, és a megrendelt fejlesztés kihagyása hirtelen tiszta megtakarításnak látszik. Hogy tényleg spórolsz-e vele, azon múlik, mi történik az eredménnyel a bemutató után.
Mire jó valójában a vibe coding
A fogalmat Andrej Karpathy vezette be 2025 februárjában: hétköznapi nyelven körülírod, mit szeretnél, a kódot a modell írja meg, a kód maga pedig szinte láthatatlanná válik a munka közben. A használat mostanra gyakorlatilag általános, hiszen a Stack Overflow 2025-ös fejlesztői felmérésében a válaszadók 84%-a használ mesterséges intelligenciára (MI) épülő eszközöket a fejlesztésben, vagy tervezi a bevezetésüket. A jelenséget a Collins-szótár is jegyzi: ezt választotta a 2025-ös év szavának.
A nyereség valódi, ha a munka az alábbi négy eset valamelyikébe tartozik:
- prototípus, amely megmutatja, érdemes-e pénzt fektetni egy ötletbe
- belső szkript, amelyet egyetlen ember futtat havonta egyszer
- nyers felület, amelyen öt felhasználóval leteszteltek egy feltételezést
- első változat, amelyet a fejlesztő úgyis újraír
Ezt a négy esetet egy közös vonás köti össze: ha a kód rossznak bizonyul, a költség kicsi marad és jól láthatóan jelentkezik.
A számla a harmadik évben érkezik
A GitClear kódelemzése 2023 és 2026 között 623 millió kódváltozást vizsgált és ezek alapján követte a szerkezeti minőség mutatószámait. Három mutatószám írja le azt, amit a fejlesztők kusza kódbázisnak neveznek:
- A duplikált kódblokkok aránya 2023 óta 81%-kal nőtt, ami az adatsor eddigi csúcsa. Minden másolat továbbgyűrűző terhet ró a csapatra: aki az egyik példányban javít, annak meg kell keresnie az összes testvérpéldányt és el kell döntenie, kell-e ott is javítania.
- A kód belső összekapcsoltsága 35%-kal csökkent. Az új kód sokkal ritkábban hívja meg a meglévőt, ehelyett önálló fájlokba kerül, és magával hozza annak a logikának a saját változatát, amely a kódbázisban már létezik.
- A hosszú távú karbantartás 74%-kal csökkent. A régi kódrétegek érintetlenül maradnak, és egyre nehezebben mozdíthatók: a tizenkét hónapnál régebbi kódot érintő módosítások aránya a mögöttes adatsorban 1,7%-ról 0,46%-ra esett.
Ezt hívják technológiai adósságnak. Üzleti nyelvre fordítva: negyedévről negyedévre több szoftver gyűlik nálad, és egyre kevesebbet értesz belőle. A következő módosítás ára emelkedik, miközben az előző fejlesztésről kiállított számla feltűnően alacsony.
A „majdnem jó” kód működési kockázatot jelent
Az MI-eszközöknél a fejlesztők leggyakrabban egyetlen bosszúságot említenek: a majdnem jó eredményt. A Stack Overflow 2025-ös felmérésében a válaszadók kétharmada ezt nevezte meg fő fájdalompontként. A bizalom közben a használattal ellentétes irányba mozdult: a válaszadók 46%-a bizalmatlan az MI-válaszok pontosságában, 33%-a megbízik bennük, és mindössze 3%-a sorolja magát a nagyon bízók közé.
A majdnem jó kód túlél egy bemutatót, a negyedéves záráson viszont elbukik.
Az önértékelés itt megbízhatatlan műszer. A METR 2025-ös randomizált, kontrollált vizsgálatában tizenhat tapasztalt fejlesztő vett részt. A résztvevők 19%-kal hosszabb idő alatt végezték el a feladatokat, amikor MI-eszközöket használhattak, utólag viszont úgy becsülték, hogy ugyanezek az eszközök 20%-kal gyorsították a munkájukat.A METR azóta jelezte, hogy az eredeti kísérleti elrendezésnek megvannak a korlátai: a későbbi méréseket szelekciós torzítás terheli, mert sokan nem vállaltak részvételt MI nélkül. Ami tartósan megmarad, az a mért idő és az emlékezetben őrzött idő közötti eltérés.
A következmények a jogosultságokkal együtt növekednek. 2025 júliusában egy nyilvános vibe coding-kísérletben egy Repliten futó MI-ügynök törölt egy éles adatbázist, miközben érvényben volt a „semmit ne módosíts” utasítás. Utána azt jelentette, hogy a helyreállítás lehetetlen. A folyamatot a The Register dokumentálta, és azt is megírta, hogy az ügynök már az előző napon hamis adatokkal és hamis kimutatásokkal takarta el a hibáit. A visszaállítás végül mégis működött, a tanulság pedig megmaradt: az éles jogosultsággal rendelkező ügynök gyorsabban cselekszik, mint ahogy bárki át tudná nézni a munkáját.
Megnő a kockázat, ha az AI-eszközök gyorsabban épülnek be a mindennapi munkába, mint ahogy a használatukat szabályozó kontrollok kialakulnak. Hogy mi történik, amikor a munkatársak a hivatalos folyamatokon kívül kezdenek AI-t használni, arról a Shadow AI a munkahelyen →cikkünkben írunk.
Egy teljes réteg láthatatlan marad a modell számára
A modell a promptodat és azt a fájlt látja, amelyen éppen dolgozik. A céged adatvilága láthatatlan marad számára, így nincs honnan tudnia a következőket:
- a három ügyféltáblád közül melyik tartalmazza a hiteles adatot
- mikor tölti be az ERP az adatait, és mikor szinkronizál a CRM, vagyis mikor mutat a kettő eltérő számokat
- mit takar az „aktív ügyfél” a pénzügyön, és mit az értékesítésen
- melyik adatmező számít személyes adatnak a GDPR szerint, és hova kerülhet át
A generált kód csak abból az adatkörnyezetből tud dolgozni, amelyet megmutatunk neki. Ha nem egyértelmű, ki felel az adatokért, mit jelentenek az egyes fogalmak, és melyik rendszer számít hiteles forrásnak, a probléma már a modell alatt elkezdődik. Erről a Miért buknak el az AI-projektek data governance nélkül →cikkünkben írunk.
Az MI-vel generált kód azt feltételezi, hogy ezek a kérdések már el vannak döntve: abba a táblába ír, amelyikre rámutatsz, és azon a kulcson kapcsolja össze a rekordokat, amelyet megemlítettél. Az alkalmazás a bemutatón szépen fut, éles üzemben viszont helyesnek látszó értékeket ír rossz helyre. A hiba hónapokkal később bukkan elő egy vezetői jelentésben olyan számban, amelyet senki nem tud megmagyarázni.
Ezért lesz ugyanabból a promptból az egyik cégnél használható eszköz, a másiknál drága káosz. A DORA 2025-ös jelentése közel 5000 informatikai szakembert kérdezett meg és arra jutott, hogy az MI elsődlegesen erősítőként működik: felnagyítja a szervezet meglévő erősségeit és gyengeségeit.
Hol húzódik a határ a prototípus és az éles rendszer között
Integrációs projektjeinkben rendszeresen ugyanez a minta tér vissza. A prototípus prototípusként megéri az árát. A drága esetek akkor kezdődnek, amikor egy prototípus csendben infrastruktúrává válik, miközben mindenki mással van elfoglalva. Nem került mögé adatmodell, és gazdája sincs.
Ez a kétféle sors öt kérdésen múlik, és mindegyikre érdemes írásban válaszolni.
1. Hiteles forrás.
Melyik rendszer felel az egyes adatokért, és ütközés esetén melyik példány érvényes?
2. Adatgazda.
Ki tartja karban az alkalmazást tizenkét hónap múlva, és tud-e már erről a feladatról?
3. Hibakezelés.
Mi történik, ha hibás adat érkezik, és hol válik láthatóvá a hiba?
4. Jogosultságok.
Mit olvashat, írhat és törölhet ez az alkalmazás, és mi tartja távol az éles adatoktól?
5. Továbblépés.
Ha a prototípus beválik, hogyan néz ki a rendesen megtervezett változat és mennyibe kerül?
Ahol mind az öt válasz megvan, ott az MI-támogatás érezhetően felgyorsítja annak a csapatnak a munkáját, amely tudja, merre tart. Ahol ezek a válaszok hiányoznak, ott a gyorsaság drága.
A nehezebb rész továbbra is az, hogy mit érdemes megépíteni
Az olcsó fejlesztés addig marad olcsó, amíg prototípus marad. A drága változat az, amelyik bemutatóként érkezett, adatmodell nélkül került éles üzembe, és ma az ERP és a számlázási folyamat között működik, egyetlen ember gondozásában, aki már csak félig-meddig emlékszik rá, hogyan épült fel.
A szoftver előállítása mostanra a könnyebbik rész. Tervezést az kíván, hogy mit építsünk meg, milyen adatokra építsük, és milyen sorrendben készítsük el.
Melyik rendszerük mondja meg az igazat?
Ha a rendszerek gyorsabban szaporodnak, mint a dokumentáció, érdemes egy strukturált felméréssel kezdeni. Az Omnit Adat-helyzetkép megmutatja, hol szakad meg az adatok útja, mely rendszerek mondanak egymásnak ellent, és mi érdemli meg elsőként a figyelmet. A felmérés két-három hét alatt készül el, két-három workshoppal és nyolc-tizenkét oldalas vezetői összefoglalóval zárul. Az ár nettó 1450 EUR-tól indul.
Ha előbb csak magát a kérdést szeretné tisztázni, díjmentes 30 perces konzultációra várjuk.
Források
- Collins Dictionary. (2025). Word of the Year 2025: AI Meets Authenticity as Society Shifts. A „vibe coding” eredetének és jelentésének forrása. Cikk megnyitása →
- DORA. (2025). State of AI-assisted Software Development. Az AI szervezeti erősségeket és gyengeségeket felerősítő szerepéről szóló megállapítás forrása. Cikk megnyitása →
- GitClear. (2026). The Maintainability Gap: AI Code Quality in 2026. A 623 millió kódváltozás alapján mért duplikációs, refaktorálási, összekapcsoltsági és karbantartási adatok forrása. Cikk megnyitása →
- METR. (2025. július). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. A 19%-os lassulás és a 20%-os becsült gyorsulás forrása. Cikk megnyitása →
- Stack Overflow. (2025). 2025 Developer Survey: AI. A 84%-os használati arány, a bizalmi és bizalmatlansági adatok, valamint a fejlesztői problémák forrása. Cikk megnyitása →
- Stack Overflow. (2026. február 18.). Mind the Gap: Closing the AI Trust Gap for Developers. Az AI-eszközök használata és a beléjük vetett bizalom közötti eltérés elemzésének forrása. Cikk megnyitása →
- The Register. (2025. július). Replit Database Deletion Coverage. A Replit éles adatbázisának törlésével kapcsolatos incidens forrása. Cikk megnyitása →
Fekszi Csaba
Fekszi Csaba informatikai szakértő, több mint két évtizedes tapasztalattal az adatmérnökség, a rendszerarchitektúra és az Mesterséges Intelligencia alapú folyamatoptimalizálás területén. Munkájának középpontjában olyan skálázható megoldások tervezése áll, amelyek mérhető üzleti értéket teremtenek.
Kapcsolódó cikkek
A felszín alatti 70%, amit a legtöbb ajánlat nem mutat meg
Miért akad el olyan sok AI-projekt — és hogyan léphetsz végre túl a pilot fázison
A vállalati mesterséges intelligencia valódi akadályai, és hogy mit csinálnak másképp a sikeres cégek
Biztos benne, hogy az AI a megfelelő következő lépés?
Segítünk feltárni a valódi lehetőségeket, korlátokat és a reális következő lépéseket.