AI-val készítettem egy terméket — hogyan fejlesszem anélkül, hogy elrontanám, ami már működik

Tudj meg többet a modellekkel való munkáról az Ailoot dokumentációjában.

Miért az indulás után kezdődik a legdrágább munka?#

Egy este alatt készítettél egy alkalmazást, közzétettél egy hivatkozást, és elküldted az ismerőseidnek. Működik. Aztán egy héttel később megjelenik az első valódi felhasználó, rosszul kattint valamire, és a funkciók fele leáll. Megkéred Claude-ot, hogy javítsa ki — egy dolgot rendbe tesz, egy másikat pedig elront. Ismerős?

És itt merül fel a fő kérdés: mit teszel a termék elindítása után, amikor az első működő prototípus feletti eufória már elmúlt, a terméket pedig valahogy továbbra is karban kell tartanod? Nevezhetnénk ezt felnőtteknek szóló vibe codingnak. Az építés izgalmas és gyors. A karbantartáshoz hideg fej kell: értened kell, min változtatsz, és ellenőrzés alatt kell tartanod a folyamatot. A legtöbben a második résznél buknak el, mert senki sem készíti fel őket erre.

Egy iparági kutatás több mint egymillió kódmódosítást elemzett 2444 csapattól, és kiszámolta, mire megy el valójában az AI-fejlesztésre fordított pénz. Íme a kép:

A „A vibe coding rejtett költsége” útmutató részletesebben ismerteti ezeket az adatokat. Ott az volt a kérdés, hogy miért fizetsz. Itt más a kérdés: minden dollárból 44 cent megy a hibák javítására — és ez az egész cikk arról szól, hogyan akadályozhatod meg, hogy ez az arány tovább nőjön. Az ezt kordában tartó munkát karbantartásnak nevezzük.

Az indulás után derül ki a különbség aközött, aki felnőttként vibe codingol, és aközött, aki csak egy neurális hálót felügyel. Az előbbinek fejlődik a kódbázisa, fejlesztéseket hajt végre, és közben semmi sem romlik el. Egy hónap múlva a második ember terméke már egy szivárgó tákolmány, amelyhez fél hozzányúlni. Mindjárt elmagyarázom, hogyan kerülhetsz az első csoportba.

Mi romlik el valójában: 5 katasztrófa az indulás után#

Ezek valódi, AI-val készült termékek nyilvános utólagos elemzései, számokkal és dátumokkal. Tekints rájuk aknamezőtérképként — minden akna már felrobbant valakinél, és ismert a módja, hogyan lehet elkerülni.

Mind az öt esetnek ugyanaz a kiváltó oka. Az AI alapértelmezés szerint arra törekszik, hogy a dolgok most működjenek, ne arra, hogy egy hónap múlva, terhelés alatt is biztonságosak legyenek. Ezt nem látod, amikor a saját számítógépeden fejlesztesz. Akkor válik nyilvánvalóvá, amikor megjelenik az első rossz szándékú idegen.

Nem az a probléma, ha a kódot nem kézzel írod — sokan dolgoznak így. Az a probléma, ha senki nem kérdezi meg: „Biztonságos az adatbázis?” Mindjárt mutatok egy promptot, amely felteszi helyetted ezt a kérdést.

Az első biztonsági háló a git és a „tegnapi állapot” visszaállítása#

Ha Claude elront valamit, kell egy gomb, amellyel „visszaállíthatod a tegnapi állapotot”. Technikailag ezt gitnek hívják, és egyszerűbb, mint amilyennek hangzik.

Három kifejezés, amelyet egy nem programozónak ismernie kell:

1. Tároló — a projektmappád a felhőben (általában a GitHubon). A teljes kódod másolata, amely nem csak a számítógépeden található meg.
2. Commit — egy visszatérési pont. Lényegében azt mondod a kódnak: „mentsd el ebben az állapotban”. Minden commit egy jelölőpont, ahová visszatérhetsz.
3. Deploy — áthelyezés. A kód helyben volt, a számítógépeden, és csak neked működött. A deploy egy külső szerverre küldi, ahol már mindenki számára működik.

Amíg vannak friss commitpontjaid, egyetlen mondattal visszaállíthatsz bármilyen elrontott dolgot. Szó szerint.

Elrontottam valamit—tegnap még minden működött, ma viszont már nem. Keresd meg a legutóbbi commitot, amelynél még minden rendben volt, mutasd meg, mi változott azóta, majd állítsd vissza a projektet arra az állapotra.

Két szabályt azonnal vezess be, még mielőtt mások meglátják a terméket:

• A tárolónak privátnak kell lennie. Ne legyen nyilvános. Különben bárki elolvashatja a kódodat és mindent, ami benne van.
• Tedd a titkokat tartalmazó fájlt a kizárási listára. A kulcsokat, jelszavakat és adatbázis-hozzáférési adatokat külön fájlban tárolod (általában .env), és ez a fájl sosem kerül be a tárolóba. Vedd fel a .env sort a .gitignore fájlba, így a titkok nálad maradnak.

A Claude Code-ban történő biztonságos visszaállításról külön útmutató szól: Módosítások visszaállítása a Claude Code-ban. Visszatérési pontok nélkül védőháló nélküli kötélen jársz, és előbb-utóbb leesel.

Mit állít vissza a /rewind, és mit nem?#

A Claude Code minden általa végzett módosítás előtt pillanatképet készít az állapotról. A /rewind parancs (vagy az Esc kétszeri megnyomása) visszaállítja a fájlokat és a beszélgetést egy kiválasztott pontra. Ez hasznos: ha öt perce rontottál el egy funkciót, visszatérhetsz az öt perccel ezelőtti állapothoz.

Van azonban egy csapda, amely miatt a kezdők adatokat veszítenek. A /rewind nem állít vissza mindent:

Az Anthropic világosan fogalmaz: a pillanatképek helyi „visszavonás” gombok, a git pedig állandó előzmény. A pillanatképek kiegészítik a verziókezelést, de nem helyettesítik.

A gyakorlati tanulság egy nem programozó számára: a /rewind megment attól, hogy „Claude épp most rontott el egy funkciót”. De ha sikerült törölnie egy adatbázissor-t vagy feltöltenie a kódot a felhőbe, csak a git és az adatbázis biztonsági mentése hozhatja vissza. Tartsd meg mindkét réteget: pillanatképek a gyors visszaállításhoz, commitok a projekt állandó előzményeihez.

Hogyan fejleszthetsz anélkül, hogy elrontanád, ami már működik?#

Minden második ember belekerül ebbe a körbe. Megkéred az AI-t, hogy javítson ki egy apró hibát. Ésszerű módosítást javasol. Ez a módosítás elront valami mást. Megkéred, hogy javítsa ki az új problémát, mire megjelenik még két hiba. És így tovább.

A kör azért alakul ki, mert a vibe coding nem determinisztikus. Ugyanaz a prompt két külön alkalommal más kódot ad. Így minden szerkesztés észrevétlenül eltolhatja a környező logikát: a kedvezményküszöb 10-ről 12 százalékra változik, vagy egy ellenőrzési szabály másképp kezd működni—anélkül, hogy bármit ellenőriznél vagy akár egyetlen figyelmeztetést kapnál. Ezt hívják logikai elcsúszásnak, és csendben éppen azokat a dolgokat károsítja, amelyek pénzt hoznak: az árakat, a hozzáférést és a fizetéseket.

Van egy szabály, amellyel megelőzhető az elcsúszás, és elég egyszerű ahhoz, hogy kitehesd a falra: ne commitolj olyan kódot, amelyet nem tudnál szó szerint elmagyarázni valaki másnak.

A gyakorlatban ez egy kész keretet jelent, amelyet a működő kód bármilyen módosítása előtt használhatsz. Arra készteti az AI-t, hogy kis lépésekben haladjon, és pontosan megmutassa, mi változott.

A kód módosítása előtt tedd a következőket:

Mentsd el a jelenlegi működő állapotot külön visszatérési pontként (commit).

Írd le pontosan, mit tervezel módosítani, és mely fájlokban.

A lehető legkisebb módosítást végezd el—csak azt, ami megoldja a feladatomat, semmi mást.

Mutasd meg, mi változott, és magyarázz el minden módosítást úgy, hogy én is el tudjam magyarázni valaki másnak.
Ne nyúlj az árazás, a hozzáférés vagy a fizetések logikájához, hacsak nem kértelek rá.

Egy másik, heteket megtakarító elv a feladat határainak fegyelmezett betartása. Egy fájó pont, egy módosítás, gyors megvalósítás. Ne kérd az AI-t, hogy egyetlen promptban írja újra a projekt felét. A profi fejlesztők néha egy egész Ubert kezdenek építeni, miközben csak egy gombra lett volna szükségük — és hónapokig elhúzzák a munkát. Neked erre nincs szükséged.

Minden, amit leírok, egyetlen dologra épül: a kontextus kezelésére. Ahhoz, hogy az AI ne rontsa el a szomszédos logikát, emlékeznie kell a projekt szabályaira.

Hogyan ellenőrizd a módosítást közzététel előtt?#

A „nálam működik a számítógépen” és az „mindenkinél működik” között van egy köztes lépés, amelyet a kezdők kihagynak: a tesztpéldány. Ez az éles környezet külön pillanatképe, amelyen ellenőrizheted a módosítást, mielőtt valódi emberek látnák. A munkamenet így néz ki:

1. Készítsd el és ellenőrizd magad a módosítást (fejlesztés).
2. Deployold stagingre—az éles környezet másolatára, valódi felhasználók nélkül.
3. Futtasd le a legfontosabb forgatókönyveket, és győződj meg róla, hogy semmi sem változott.
4. Csak ezután deployold éles környezetbe.

Ez azért fontos az indulás után, mert minden kiadás kockázattal jár. Egy kis kódmódosítás is elronthatja a fiókba való bejelentkezést. Egy hiányzó beállítás az egész terméket leállíthatja. A staging következmények nélkül felfedi ezeket a problémákat; éles környezetben ügyfeleket veszítesz.

Hogy ne kelljen minden alkalommal mindent kézzel ellenőrizned, adj az AI-nak egy promptot, amely összehasonlítja az új verzió viselkedését a régiével a kritikus területeken.

Hamarosan deployolok egy módosítást. Menj végig sorrendben a termék legfontosabb forgatókönyvein, és ellenőrizd, hogy mindegyik továbbra is a korábbiak szerint működik-e:

Új felhasználó regisztrációja és bejelentkezése.

Fizetés és a hozzáférés megadása fizetés után.

Hozzáférési jogosultságok—a normál felhasználó nem láthatja mások adatait vagy az adminisztrációs felületet.

Az üzleti logika fontos számai (árak, kedvezmények, korlátok) nem változtak.
Ha valami másképp működik, mint az előző verzióban, állj meg, és mutasd meg pontosan, mi változott.

Hol vannak a titkaid? A kezdők legnagyobb biztonsági rése#

Részletesen elmagyarázom a legnagyobb aknát, mert ez több terméket tesz tönkre, mint bármi más. Amikor az AI kódot ír, a legegyszerűbb oda tenni egy kulcsot, ahol azonnal működik—közvetlenül a böngészőben megnyíló oldal kódjába. Fejlesztés közben nem veszed észre a különbséget. De bárki elolvashat mindent, ami eljut a böngészőbe, ha megnyitja a fejlesztői eszközöket.

Az az alapító, akinek az ügyfeleit $87,500 összeggel terhelték meg, később azt mondta, egyetlen prompttal meg lehetett volna előzni. A terheléseket végül visszafordították, de a vissza nem téríthető díjak és az elveszett nyugalom megmaradtak. Íme az a prompt.

Ellenőrizd az egész projektet, és győződj meg róla, hogy egyetlen titkos kulcs sem kerül a böngészőbe:

Keresd meg az adatbázishoz, a fizetési rendszerhez és a külső szolgáltatásokhoz tartozó összes kulcsot.

Győződj meg róla, hogy mindegyiket kizárólag a szerveren, környezeti változókban tároljuk, nem pedig az oldal kódjában.

Ellenőrizd a projekt előzményeit—is bekerült korábban véletlenül valamelyik kulcs?
Mutasd meg az összes helyet, ahol titkokat találtál, és hogy mindegyikkel kapcsolatban mit kell tenni.

A következő közeli akna az, ha a hozzáférési jogosultságokat csak a böngésző oldalán ellenőrzik. Ha a termék az oldal kódjában dönti el, hogy „megjelenítse-e az adminisztrációs felületet”, bárki megkerülheti ezt a döntést. A hozzáférési jogosultságokat mindig a szerveren kell ellenőrizni. Az adatbázis csak azoknak adhat vissza adatokat, akik jogosultak rá—erre való a row-level security (RLS), amelyet minden táblán engedélyezni kell.

Mielőtt hozzáférést kezdesz árulni vagy másokat beengedsz, végezd el a termék általános biztonsági auditját.

Vizsgáld át a projektet támadóként, és keresd meg a biztonsági réseket:

Tárolunk titkos kulcsokat a böngészőbe kerülő kódban vagy a projekt előzményeiben?

A row-level security (RLS) engedélyezve van minden adatbázistáblán, és a hozzáférési jogosultságokat a szerveren ellenőrizzük, nem csak a böngészőben?

Be van állítva automatikus adatbázis-mentés, és ellenőriztem már, hogy vissza tudom állítani?

El van különítve az éles adatbázis attól a környezettől, amelyben az AI-ügynök fut?
Minden pontról mondd meg, hogy rendben van-e, vagy pontosan mit kell kijavítani.

Külön, teljes útmutató szól a vibe coding biztonságáról: Így biztosíts egy vibe codinggal készült alkalmazást. A szabály egyszerű: tekints mindent, amit az AI alapértelmezés szerint csinált, nem biztonságosnak, amíg az ellenkezőjéről meg nem győződtél.

Hol üzemeltesd a termékedet: tárhelylétra#

Nem kell rögtön saját szervert bérelned és kézzel beállítanod—kezdetben ez bonyolult feladat, és felemészti az idődet. Van egy létra, amelyen a termék növekedésével feljebb léphetsz:

1. Ingyenes tárhely (például Vercel)—saját használatra, tesztekhez és kisebb projektekhez. Akkor megfelelő, ha a platform elérhető a közönséged számára, és nem tárolsz személyes adatokat.
2. Egyparancsos deployt kínáló platform (Railway)—amikor már van backend és adatbázis. Egy paranccsal deployolhatsz, és nem kell szervert beállítanod. A belépési küszöb minimális.
3. Saját dedikált szerver—nagy terhelésnél, ha teljes irányításra van szükséged. Később válts erre, amikor eléred a platform korlátját.

Egy frissen indult termék nem programozó gazdájának a legegyszerűbb megoldás az egyparancsos deployt kínáló platform, kézi szerverbeállítás nélkül. Saját szerverre később térj át. Ha konkrét példával szeretnéd végigjárni ezt az utat, nézd meg az útmutatót arról, hogyan deployolj egy vibe codinggal készült projektet saját szerverre Coolify segítségével.

Mikor válaszd külön az alkalmazást, az adatbázist és a biztonsági mentéseket?#

Három dolgot nem szabad egy kosárba tenni: az alkalmazást, az adatbázist és a biztonsági mentéseket. Amíg kevés a felhasználó, minden együtt van, és ez rendben van. De egyértelmű jelzi, mikor kell szétválasztani őket.

• Helyezd az alkalmazást és az adatbázist külön gépre. A jel: csúcsterhelés alatt a CPU és a memória tartósan 70–80 százalék fölött van, a kérések lassulnak, az alkalmazás és az adatbázis pedig ugyanazokért az erőforrásokért verseng. A szétválasztás után az alkalmazás érintése nélkül erősítheted az adatbázist, és fordítva.
• Kövesd a 3-2-1 biztonságimentési szabályt. Az adatok három másolata, két különböző adathordozón, közülük egy külső helyszínen. Ez véd a hardverhibák és a zsarolóprogramok ellen. A lényeg, hogy a mentések automatikusan készüljenek.

A mentés gyakorisága attól függ, mennyibe kerül néhány órányi adat elvesztése. Ha egy online előfizetéses szolgáltatásnál egyórányi fizetési rekord elvesztése elfogadhatatlan, a mentési időköznek egy óránál rövidebbnek kell lennie, vagy igazolt tranzakciónapló és időpontra visszaállítás (PITR) szükséges. Az időközt a legnagyobb elviselhető adatvesztésből válaszd, és a szolgáltatás helyreállításának idejét külön teszteld. Egy blognál elég a napi mentés. A logika egyszerű: határozd meg, mennyi adat elvesztését engedheted meg magadnak, és ennek megfelelően állítsd be a mentéseket.

Segíts eldöntenem, eljött-e az ideje, hogy a termékem komolyabb infrastruktúrára kerüljön. Ellenőrizd és kérdezz rá mindegyik pontra:

Mennyire terhelt a CPU és a memória csúcsterheléskor—tartósan 70–80 százalék felett van a használat, vagy sem?

Az adatbázis és az alkalmazás ugyanazon a gépen van, vagy külön gépeken?

Be van állítva automatikus adatbázis-mentés, és teszteltem már a visszaállítást?

Van külön környezetmásolat (staging) a deploy előtti ellenőrzéshez?
Az eredmények alapján adj egyértelmű ajánlást: mi maradjon így, mit válasszak szét először, és miért.

Van egy külön kérdés is: menedzselt adatbázist vagy sajátot használj-e. Kis csapatnak a menedzselt szinte mindig jobb: a saját olcsóbb hardver szempontjából, de órákat emészt fel a karbantartása. Ha egyedül dolgozol, és a terméked nem infrastruktúra, ezek az órák többe kerülnek, mint a szerverárak közötti különbség.

Hogyan automatizáld a karbantartást?#

A kézi karbantartás fárasztó. Két módon tehermentesítheted magad: felügyelettel és egy járőröző ügynökkel.

A felügyelet két külön eszközt használ két külön feladatra:

1. „Elérhető az oldal?”—üzemidő-felügyeleti eszköz (például UptimeRobot). Néhány percenként pingeli a terméket, és riasztást küld, ha az leáll. Van ingyenes csomagja.
2. „Pontosan mi romlott el?”—hibakövető (például Sentry). Összegyűjti az alkalmazáson belüli hibákat, és megmutatja, hol és miért történt a hiba.

Az első azt jelzi, hogy leállt a termék. A második megmutatja, melyik funkció hibásodott meg és miért. Együtt arra a kérdésre adnak választ: „Megtudom a hibát, mielőtt egy ügyfél ír az ügyfélszolgálatnak?”

Az automatizálás második szintje egy járőröző ügynök. Képzelj el egy ingatlanközvetítő irodát: reggel hétkor egy AI-ügynök elolvassa a weboldal érdeklődőit, észreveszi, hogy nem működik a foglalási űrlap, megkeresi az okot a kódban, majd egy kész javítást hoz neked magyarázattal. Átnézed, és azt mondod, „igen”—a javítás deployolódik. A sorrend számít: először oldd meg a felhasználó problémáját (add meg a hozzáférést, kérj elnézést), majd vizsgáld ki az okot és a pénzügyeket.

Még egy szabály az AI éles adatbázishoz való hozzáféréséről: adj neki csak olvasási jogosultságú felhasználót, és rejtsd el a személyes adatokat egy köztes réteg mögé, hogy az ügynök a valódi név helyett csak a „nevet” lássa. Így akkor sem tudja fizikailag törölni vagy megrongálni az éles adatokat, ha hibázik. A fenti táblázatban szereplő eset, amelyben egy ügynök törölte az éles adatbázist, pontosan a korlátozás hiányáról szól. A Mi a teendő, ha az AI törölte az adatbázisodat útmutató azt magyarázza el, mit kell tenni, ha már bekövetkezett a katasztrófa.

Mikor kell leállítani egy terméket?#

A karbantartás leginkább alábecsült része az, hogy tudd, mikor kell abbahagyni. Akik sokat építenek, mind őriznek projekttemetőt: elkészítettek valamit, bütykölték, aztán magára hagyták. Ez normális, és nem kudarc. Az a kudarc, ha hónapokig cipelsz magaddal valamit, amit senki sem használ, csak azért, mert sajnálod rá az időt.

Döntési küszöbök:

1. Két hét—ennyi elég annak megállapításához, hogy működik-e az ötlet. Ha az első valódi felhasználók visszatérnek, folytasd. A csend is válasz.
2. Három hónap—a szigorú határ. Ha három hónap alatt nem futott fel, állítsd le. A vibe coding sebessége mellett hat hónapot tölteni egyetlen ötlet tesztelésével túl sok.

Egy projekt lezárása lelkileg nehéz, ezért döntésként kezeld, ne érzésként. Megválni egy olyan projekttől, amelybe befektettél, olyan, mint elbocsátani egy munkáját elvégezni képtelen alkalmazottat: kellemetlen, de többe kerül megtartani, mint elengedni.

A karbantartás olyan munka, amely életben tartja a terméket, és hasznossá teszi az emberek számára. Minden más—git, biztonsági mentések, felügyelet—csupán eszköz ahhoz, hogy eljuss odáig, amikor a termék nap mint nap neked dolgozik.

AI-val egy este alatt terméket építeni csak a munka fele. Életben és biztonságban tartani, miközben növekszik—ezt jelenti a felnőtteknek szóló vibe coding.

A következő lépésed: Ailoot.