Amit a vibe coding sztorik elhallgatnak

A vibe coding sztorik szinte mind a demónál érnek véget. Arról, ami utána jön (a karbantartásról, a lassú korhadásról, a napi üzemeltetésről), alig ír valaki első kézből. Ez a cikk pont erről szól, és a fő állítása egyszerű: nem kód-tudás kell hozzá, hanem folyamat-tudás, és az pont a marketinges erőssége.

Ez a sorozat eddigi utolsó gyakorlati része. Az elsőben a teljes számláról volt szó, a másodikban a biztonságról. Most a legalulértékeltebb részről: mi történik a launch után.

Egy szó a pontosság kedvéért. Launchon itt a működő rendszer napi üzemét értem, nem a kereskedelmi nyitást. A platform a fejlesztés alatt végig élő, telepített környezetben futott, így az üzemeltetés kérdései már az első héttől jelen voltak. A kereskedelmi nyitás küszöbén állok: a fizetés és a számlázás élesben végigment, a nyilvános indulás még hátra van, és a tervben marad, hogy tapasztalt fejlesztővel is átnézetem az egészet.

A nap, amikor idegen munka ment ki élesbe

Kezdjük egy balesettel.

Július 23-án egyetlen elhamarkodott parancs a „csomagolj be mindent" utasítással besöpörte egy másik, párhuzamosan futó munkamenet félkész jogi szövegeit és egy adatbázis-módosítást, és élesbe küldte, mielőtt az adatbázis készen állt volna rá. Fizetés-törést kockáztatott. Marketinges hasonlattal: mintha a gyakornok a nyomdába a szomszéd asztalon heverő piszkozatot is beküldené a kész anyag mellé.

A tanulság nem az lett, hogy „legyek óvatosabb". Abból sosem lesz semmi. A tanulság az lett, hogy amit fontos betartani, azt ne kérésre bízd, hanem kapura.

A kérés nem szabály, a szabály nem kapu

Ez a cikk gondolati gerince, és nem csak az én tapasztalatom.

A vibe coding legismertebb tanulsága éppen erről szól. Amikor az AI-ügynök törölte Jason Lemkin éles adatbázisát, azt egy kifejezett tiltás ellenére tette, amit tizenegyszer, csupa nagybetűvel leírtak neki. Egy fejlesztő a Hacker Newson pontosan összefoglalta, miért: „az ügynök nem hibásodott meg. A feladatát teljesítette. Bármilyen szabályt adsz neki, az képlékeny."

A Claude Code fejlesztői közösségében ebből lett a konszenzus: ami minden egyes alkalommal meg kell történjen, arra automatikus kapu kell, nem utasítás. Maga az AI-eszköz gyártója, az Anthropic is így fogalmaz: ahol valami semmiképp nem történhet meg, ott az utasítás a rossz eszköz.

Az evolúció tehát ez: kérés, aztán leírt szabály, végül gépi kapu. Marketingesként ez ismerős. A brand-arculatot sem a jóindulat tartatja be, hanem a sablon, amiből nem lehet kilépni.

Az öt őr, amiből tizenegy lett

A júliusi baleset után nem több figyelmet állítottam be magamnak, hanem gépi őröket (hook). Az első öt a hetedik hétre állt fel, és mindegyik egy korábbi hibából született. Ezek másolható receptek, akkor is, ha nem te fogod megírni őket, hanem az AI-dnak adod feladatul.

1. Csomagolás-őr. Fizikailag megtagadja a válogatás nélküli „csomagolj be mindent" parancsot, ami a júliusi balesetet okozta. És nem csak tilt: megmondja, mit csinálj helyette. A csavar benne, hogy saját magát is ki kellett cselezni, nehogy egy üzenet, ami leírja a tiltott parancsot, kiváltsa a tiltást.

2. Élesítés-őr. Nem engedi a vak élesítést, ha közben egy másik munkamenet dolgozott ugyanazon. És ha maga az ellenőrzés hálózati hibába fut, akkor is tilt, mert éles rendszerre vakon nem megy ki semmi. Ugyanaz a „kudarcnál zár" elv, amiről a második részben írtam, csak a munkafolyamatra alkalmazva.

3. Foglalás-őr. Párhuzamos munkamenetek nem írhatnak egymás fájljaiba. Az első, aki hozzányúl egy fájlhoz, lefoglalja, a többi vár.

4. Rendrakás-őr. Egy leálló munkamenet nem hagyhat maga után félkész, elmentetlen munkát. Azért született, mert egy nagytakarításkor négy különböző helyen találtam hetekkel korábbi, elfeledett maradékot.

5. Nyelvhelyesség-őr. Ez a kedvencem, mert marketinges őr, nem fejlesztői. Az AI-írás egyik magyar árulkodó jele a hosszú gondolatjel túlhasználata. Az őr megállít, ha ilyet találna a látogatónak megjelenő szövegben, de nem javítja ki automatikusan, mert a helyes írásjelet csak a mondat ismeretében lehet eldönteni. Ez a legfontosabb mondat az egész cikkben a marketingeseknek: a márkahangot is lehet automatikus kapuval őrizni. Nem csak a kód minőségét, a szövegét is.

A következő hat hétben még hat őr jött, és mind ugyanabból a mintából: egy hiba kiment, és a tanulság nem szabály lett, hanem kapu. Egy design-őr megtiltja, hogy a felületbe beégetett betűméret vagy színkód kerüljön a közös tokenek helyett, mert egy ilyen eltérés csak időigényes manuális ellenőrzéssel vehető észre. Egy dia-őr zárt érték-készletet tart a leckék diáin: nincs olyan lekerekítés, betűméret vagy térköz, ami nem szerepel a közös létrán, és ha egy komponens visszaírná azt, amit a közös recept már megad, az őr szól, mert a felülírás némán nyerne. Egy szereplő-őr vigyáz arra, hogy a kurzus állandó szereplője minden dián ugyanazon a néven fusson, különben nem épül fel a karakter. Egy kezdőpont-őr a kivetített diák bal felső sarkát tartja egy helyen. Egy a lecke-oldal saját kánonját őrzi.

Az őrök mellé mérők is jöttek, kilenc darab, és ezek már nem tiltanak, hanem mérnek: futó rendszeren végiglapoznak minden diát, és megnézik, lóg-e le szöveg, csúszik-e felirat egy rajzra, egy vagy két vizuális nyelv fut-e egy leckén belül, kerekített-e minden kép, vág-e a doboz a képbe, egy vonalban áll-e, ami egy hasábban van, üresen maradt-e egy félvászon, és csupa nagybetűs-e egy mock, aminek nem szabadna. Több mint 1800 diát mérnek végig, és a nyitás előtti teljes körön mind zöld volt. A számot azért írom le, mert ez a láthatatlan rész: egy kiadás előtt a gép többet néz meg, mint amennyit egy ember egy nap alatt tudna.

Egyetlen út az éles rendszerbe

A júliusi baleset után hat héttel jött a második nagy rendrakás, és az már nem egy őr volt, hanem egy út.

Addig az élesítés annyi volt, hogy a kész változást felküldtem, és a tárhely magától kitette. Ez három kockázatot bízott a fegyelemre: hogy közben más munkamenet is felküldött valamit, hogy a változás piros (nem fordul, egy teszt bukik), és hogy egy titok, egy kulcs kicsúszik a kódban. Egy negyediket pedig, hogy két munkamenet ugyanabban a percben küld fel, egy őr eleve nem tud kezelni.

Ezért lett a mainbe egyetlen út, egy parancs. Sorrendben: megáll, ha van mentetlen változás; behúzza, ami közben a mainre került; végigkeresi a kimenő különbséget kulcs-mintákra; lefuttatja a négy ellenőrzést (típus, stílus, teszt, fordítás) egyszerre, és az első pirosnál a többit is leállítja; majd egy zárat tesz a közös git-könyvtárba, még egyszer ránéz, mozdult-e a main, és csak akkor küld. Ha mozdult, elengedi a zárat és újrakezdi. A nyers felküldést ugyanaz az élesítés-őr tagadja meg, és erre az útra irányít.

A rendrakás egy takarítást is hozott, és abból lett a cikk egyik legfontosabb tanulsága. A párhuzamos munkamenetek mind saját másolatban dolgoznak, és amikor egy munkamenet befejezte a dolgát, a másolat egy része ott maradt. Negyvenegy ilyen mappa volt, ebből tizenhárom élt. A maradék huszonnyolc mind egy szabályosan lezárt munka építési maradéka, ami kívülről folyamatban lévő munkának látszott. A takarítás első köre két olyan másolatot is elvitt, amiben éppen dolgozott valaki, mert „nincs benne mentetlen munka" nem ugyanaz, mint „senki nem dolgozik benne": egy éppen kiadó munkamenet pont tiszta. Azóta a takarító külön méri az aktivitást, négy órás ablakkal, és árva mappát csak bizonyítással töröl: minden fájlját ellenőrzi a repó saját tárában, és ami egyetlen mentésben sincs benne, az megállítja a törlést.

Csapatmunka egy emberrel

A launch utáni munka egyik meglepetése, hogy egyedül is lehet csapatban dolgozni.

A gyakorlatban több AI-munkamenetet futtatok egyszerre ugyanazon a projekten: az egyik leckét ír, a másik jogi szöveget, a harmadik auditál. Ehhez szerkezet kell, különben egymás munkáját írják felül. Két ügynök ugyanabba a fájlba ír, és a végén az összefésülés tovább tart, mint az eredeti feladat.

Egy saját eset erről. Két munkamenet két külön leckét épített, és mindkettő ugyanazt a sorszámot adta neki. A összefésülés után a „következő lecke" gomb némán átugrott egyet. A tanulság, ahogy a kód-mentéshez odaírtam: ezt a hibafajtát két külön-külön hibátlan munka összege szüli, ezért kell rá gép. Két önmagában helyes dolog összege is lehet hibás. Erre ember nem elég figyelmes, automata ellenőrzés viszont igen.

Ugyanez a párhuzamosság a hibakeresésben aranyat ér. Egy átvilágításnál négy AI-ügynököt futtattam egyszerre, mindegyik más szemszögből (jogi, üzemeltetési, pénzügyi szélső esetek, keresőoptimalizálás). Ez találta meg például, hogy a pénztár nem kért számlázási nevet és címet, ami a magyar számlázásnál utólag pótolhatatlan lett volna. Az AI nemcsak építeni tud, hanem szisztematikusan gyanakodni is, ha kifejezetten arra kéred.

A csapatmunka másik formája az éjszakai műszak lett. Egy hónapon át egy ütemezett feladat minden este hét után elindult, felépítette az előző este megvázolt leckét, kiadta a saját másolatából, és megírta a következő vázlatát. Reggel egy naplót találtam és egy kész leckét.

Egy harmadik tanulság a párhuzamos munkából, és ez alattomos. Egy lecke hat napot állt egy külön ágon, amíg átnézésre várt, és az alatt a hat nap alatt 147 mentés érkezett a mainre. Négy szabály változott meg közben, és egy takarítás kitörölte azt a két komponenst, amit a lecke használt. A beolvasztás mind a négyszer tiszta volt, ütközés nélkül, mert a git nem tud szabályról. A hibák egyike sem látszott ránézésre. Mind a négyet a repó saját kapui találták meg: a teszt, a fordítás, a mérők. Azóta szabály: egy hétnél régebbi ágon a munka első lépése a frissítés, aztán sorban minden kapu, még mielőtt bárki ránéz.

A karbantartás valósága, számokban

Most a rész, amit a demó-sztorik kihagynak.

Jason Lemkin, aki több mint tíz appot épített közel egymillió használattal, egy ponton 90 napra leállt, mert kiégett. A szavaival: „a vibe coding nem passzív." A húszperces prototípus a teljes munka nagyjából 5 százaléka. A tizedik napi bejegyzése: „már nincs rugó a lépteimben, ágyban maradok."

A kód ráadásul AI-sebességnél gyorsabban is romlik. Egy 211 millió sort néző elemzésben 2024 volt az első év, amikor a másolás-beillesztés meghaladta az átgondolt, újrahasznosított kódot. A közösség a harmadik hónapot nevezi meg töréspontként, amikor az új funkció elkezdi törni a régit. Külön iparág épült a takarításra: az olcsó építés drága takarítás lett, már óradíjas.

És egy szám, ami minden marketingesnek szól. Egy szigorú kutatásban a fejlesztők 20 százalékkal gyorsabbnak érezték magukat AI-val, miközben valójában 19 százalékkal lassabbak voltak. A percepció és a valóság közti rés ellen egyetlen dolog véd: a mérés.

Mit tettem én ez ellen? A 87 nap alatt három teljes átvilágítási kört és tucatnyi célzott auditot futtattam. Az indulási hajrában egyetlen hét alatt a teszt-készlet 148-ról 372-re nőtt, mára 1055 fut, plusz 42 külön állítás az adatbázis jogosultságairól. Tizenegy gépi őr és kilenc mérő fut folyamatosan. Két komolyabb üzemeltetési incidensem volt, a júliusi baleset és az augusztusi takarítás, és mindkettőből őr lett. Nulla összeomlás. Nem azért, mert okosabb vagyok. Azért, mert a fegyelmet kiszerveztem gépre.

Egy rezsi-tanulság idekívánkozik. Az automata ellenőrzés a felhőben fut, és annak is van ára: egy teljes dia-mérés 36 perc gépidő, és amikor minden felküldésre lefutott, négy nap alatt elfogyott a havi 2000 ingyenes perc. Aznap kártyát kellett megadnom és költségkeretet állítanom. A javítás nem a mérés gyengítése lett, hanem az ütemezés: a teljes kör napi egyszer fut, hajnalban, az utolsó nap lecke-érintő változásaira szűrve, a gyors ellenőrzés pedig marad minden felküldésen. A lefedettség maradt, csak az ismétlés esett ki.

A mérő is vak lehet

Ez a szakasz a nyolcadik hét után született, és a cikk legfontosabb kiegészítése.

Az első mérők a dia alapállapotát mérték. Amit egy kattintás fed fel (egy eredmény-panel, egy kinyíló magyarázat), azt nem. Egy nap egy új dia-típusnál mind az öt akkori mérő zöld volt, és a felfedés mégis levágta a saját magyarázó dobozát a vászon aljáról. Csak a manuális kattintás találta meg. A tanulság nem az lett, hogy kattintsak többet. Az lett, hogy a mérők kapjanak egy állapot-járót: egy közös részt, ami a vászon minden gombját és opcióját végigkattintja, és minden állapot után mér. Ma minden mérő az interakció utáni állapotokat is nézi.

Aztán jött a tanulság, ami a marketingeseknek szól. Egy kiadásban hét stílus-hiba ment ki egyszerre: nyers elem a családi recept helyett, keskenyebb panel a doboz fölött, gomb a rossz helyen, üres félvászon a záró dián, csupa nagybetűs és zsúfolt mock, egy narrátor-mondat, ami olyat ígért, amit a felület nem mutatott, és egy kártya, ami a szomszédjához képest fél centit lejjebb állt. Egyik sem működési hiba. Mind átment minden kapun. A gépi mérők ugyanis mind a vászonhoz mérnek. Azt, hogy egy dia úgy néz-e ki, mint a szomszédja, csak az összehasonlítás látja. Ebből négy szabály lett, nem fegyelem: új dia előtt egy kép a legközelebbi rokonával egymás mellett, hat pont a képen; három új mérő (igazítás, üres félvászon, nagybetű), mind az interakció utáni állapotokra is; új komponens a testvére másolatából indul, nem nulláról; és a javítás egy körben fut az egész dián, nem kritikánként egyesével.

És egy harmadik kör, ami azt mutatja, mit tud a gép, ha jól kérdezed. Egy kontraszt-audit minden látható szövegelem három pontján megnézte a valódi hátteret (rajzolt alakzat, félig átlátszó réteg, kép-pixel, textúra), alapállapotban és hat kattintás után. 1311 dia-állapot, 4189 lelet, 47 hiba-család. A javítás 23 stíluslapot érintett, és egy ellenőrző mérésen 498 hibás elemből 61 maradt, azok is egy-egy diás ritka esetek. Ezt szemmel senki nem csinálta volna végig. A gép igen, mert pontosan azt kérdeztem tőle, ami mérhető.

A remény is itt van, ugyanattól a Lemkintől, a vibe coding 125. napján, még a kiégése előtt: „az ügynök ma már tényleg a csapatom része, nem eszköz." Folyamattal működik.

A fordulat: a szűk keresztmetszet nem a kód

Itt jön a sorozat csattanója.

Július 28-án kidobtam a teljes naptári ütemtervemet. Nem a kód késett. A tananyag. A kód-írás gyors volt, a tartalom-gyártás a lassú. A rögzített munkaszabályom azóta: a javaslat arra menjen, ami a gyártást gyorsítja, ne arra, ami a teendő-listát rövidíti.

Ez egybevág a téma egyik legtöbbet idézett fejlesztői írásával, aminek a címe önmagában tézis: „a kódírás sosem volt a szűk keresztmetszet." Egy tartalom-üzletben az alkalmazás csak az állvány. A termék a tartalom-gyártósor.

Mit jelent gyártósort építeni tartalomra? Nálam ezt: forrás-kutatási szabály (emlékezetből definíciót írni tilos, mindig eredeti forrásból dolgozz), sablon-katalógus a leckékhez, monotónia-ellenőrző szabályok, és egy vak-teszt. Ez utóbbi a kedvencem: a saját szabálykönyvemből egy friss AI-ügynök úgy gyártott le egy leckét, hogy a mintát meg sem nézhette, és ahol eltért a mércétől, ott derült ki, mi hiányzik a szabálykönyvből. A szabálykönyv tesztje is teszt-vezérelt lett.

A gyártósor azóta tovább épült. Új lecke vázát ma egy parancs adja, a kurzus tematikájából és adatlapjából: a fejléc, a négy kötelező fázis, a szereplő és a forrás-jegyzék váza mind onnan származik, tehát az első kiírás már átmegy a kapukon. Sablont másolni tilos, mert a másolat a másolt lecke maradékait is hozza. A gyártás vége egy kötelező mérő-kör. És a design-rendszer teljes leírása, a tokenek, a receptek, a kivételek leltára, a forrásból generálódik minden fordításnál, nincs kézzel karbantartott másolata, tehát nem tud elavulni.

Az elv egy mondatban: minden döntésed, amit egyszer már meghoztál, váljon szabállyá, hogy ne kelljen még egyszer meghoznod.

És most a marketinges fordítás, ami miatt ez az egész cikk létezik. Ez pontosan a brief-kultúra. Kiderült, hogy a hatékony AI-munka előre megírt, részletes specifikációt kíván, ami a régi, alapos tervezés visszatérése. Ebben a marketinges eleve előnyben van, mert egész karrierjében ezt csinálta: briefet írt. Brief nélkül a legjobb kreatív is szemetet gyárt, és pontosan ez igaz az AI-ra is. A jó brief az új kód.

Amit bármelyik marketing-csapatba átvinnék

Öt elv, ami nem csak kódra igaz:

1. Kérés helyett kapu. Amit fontos betartani, azt automatizáld, ne az emlékezetre bízd.
2. A fegyelem nem skálázódik, a szerkezet igen.
3. Minden döntést szabályozz, különben újra meghozod.
4. Párhuzamos munka csak felosztott felelősséggel megy.
5. A szűk keresztmetszetet keresd, ne a látványos részt gyorsítsd.
6. Amit a gép nem mér, azt nézd egymás mellett. A mérő a vászonhoz mér, az egységet csak az összehasonlítás látja.

A sorozat egyetlen mondatban

Három részen át egyetlen állítást bontottam ki. Az AI leviszi az építés árát, ezt mutatta az első rész. A biztonság nem tudás, hanem folyamat, ezt a második. És a folyamat gépesíthető, ezt a harmadik. Ami a végén megkülönböztet, az nem a kód-tudás, hanem a folyamat-tudás. Az pedig tanulható, és pont a marketinges rendelkezik a felével már ma is.

A fogalom megalkotója, Andrej Karpathy szerint a felügyelet nélküli vibe coding már a múlté; ő agentic engineeringnek hívja, ami jön helyette: nem a jó mondat, hanem a jó munkarend megtervezése. A mondat, amit magáévá tett, és ami az egész sorozatot lezárja: a gondolkodásodat kiszervezheted, a megértésedet nem.

Ha kíváncsi vagy, mi épült ebből a folyamatból: a kurzusok között ingyenes próbalecke vár, a Nagy Marketingteszten pedig 60 kérdésen felmérheted, hol tartasz a szakmában. Ez a cikksorozat maga az őszinte válasz arra, hogyan készült az egész.

Felhasznált források

Lemkin, J. (2025). @Replit goes rogue during a code freeze and shutdown and deletes our entire database. X.

Sharwood, S. (2025). Vibe coding service Replit deleted user's production database, faked data, told fibs galore. The Register.

kstenerud (2026). Comment on "Claude Code Cheat Sheet". Hacker News.

Batur, M. (2026). Claude Code Hooks: The Complete Developer Guide with Production-Ready Examples. TECHSY.

Anthropic (2026). Automate actions with hooks. Claude Code Docs.

Anthropic (2026). Run parallel sessions with worktrees. Claude Code Docs.

Lemkin, J. (2026). I Vibe Coded 10+ Apps Used Almost a Million Times. Then I Had To Stop for 90 Days. SaaStr.

Lemkin, J. (2025). The Complete Guide to Vibe Coding Without a Developer: The 14 Key Lessons to Learn Before You Start. SaaStr.

Lemkin, J. (2025). Vibe Coding Day 10: So I'm up, I'm thinking about vibe coding, but I'm not starting today. X.

GitClear (2025). AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones. GitClear.

AgentKit (2026). Your Vibe-Coded App Works. The Problem Is What Happens at Month Three. DEV Community.

Mishra, S. (2025). Vibe Coding Gives Rise to a New Job: Vibe Code Cleanup Specialist. Indeed.

Becker, J., Rush, N., Barnes, B., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.

GitHub (2026). GitHub Actions billing. GitHub Docs.

Lemkin, J. (2025). 125 Days, 750,000 Uses, One Realization: Some of Our AI Agents Are Now Truly Part of the Team. SaaStr.

Tavares, P. (2025). Writing Code Was Never The Bottleneck. ordep.dev.

Karpathy, A. (2026). Sequoia Ascent 2026 summary. karpathy.bearblog.dev.

Karpathy, A. (2026). A lot of people quote tweeted this as 1 year anniversary of vibe coding. X.