AI-kód ellenőrzése: 7 lépés nem programozóknak 2026-ban

Az AI egy este alatt összerakott neked egy weboldalt vagy botot. Minden megnyílik, a gombok működnek, és úgy tűnik, minden rendben fut. Megmutatod a projektet másoknak, aztán egy nappal később kiderül, hogy a fizetési űrlap levonja a pénzt, de a rendelések soha nem érkeznek meg. Vagy hogy az ügyfelek telefonszámait tartalmazó adatbázis az egész internet számára hozzáférhető.

Én is így adtam ki az első projektjeimet: a működőnek tűnő dolgok meglepték a valódi felhasználókat. Most, mielőtt bárkinek bármit megmutatok, végigmegyek a projekten ugyanazzal az ellenőrzőlistával. Közben egyetlen sor kódot sem olvasok el — nem ezért jöttem ide, és valószínűleg te sem.

És ez nem paranoia. Az Anthropic 400 000 Claude Code-munkamenetet elemzett: hét hónap alatt a hibás kód javítására fordított munka aránya 33%-ról 19%-ra csökkent. Csökkent, de nem tűnt el. Minden ötödik munkamenet még mindig arról szól, hogy „javítsd meg, amit az AI elrontott”.

Maga a kódírás már nem szűk keresztmetszet. Most az számít, mennyire érted a feladatot, és mennyire tudod ellenőrizni az eredményt.

Az eszközök beállításáról további anyagok találhatók az Ailoot dokumentációjában.

Miért ellenőrizd az AI által generált kódot, ha már működik?#

Az AI olyan kódot ír, amely első pillantásra rendben lévőnek tűnik. Fut, megjelenik a képernyő, a bemutató pedig meggyőző. Az éles indítás viszont nem árulja el, hogy helyesen számolja-e a pénzt, kívülről hozzáférhető-e az adatbázisod, vagy minden összeomlik-e, amikor megérkezik a századik felhasználó.

A számok is ezt támasztják alá. A FrontierCode benchmark 2026 júniusában azt vizsgálta, mennyire áll készen az AI által generált kód a valódi munkára módosítások nélkül. Még a legjobb modellek legnehezebb feladatainál is csak körülbelül 13% volt ez az arány. Más szóval, komoly feladatoknál a legtöbb AI által generált kódot kézzel kell továbbfejleszteni, mielőtt megbízhatnál benne.

A jó hír, hogy bárki elvégezheti az ellenőrzést. Ezt állapította meg az Anthropic ugyanabból a 400 000 munkamenetből:

Az előnyöd bármelyik programozóval szemben, akit bevonsz, az, hogy te érted a feladatot. Az ellenőrzés is a megértésről szól; ehhez nem kell kódot olvasnod. Az alábbi ellenőrzéseket pontosan te is el tudod végezni, minden különösebb bonyodalom nélkül.

Mi romolhat el valójában az AI által generált kódban?#

Ellenőrzés előtt érdemes tudni, mit keresel. Az AI által generált kódnak öt tipikus problémája van, és mind az ötöt észreveheted kódolvasás nélkül, ha figyeled, hogyan viselkedik a projekt.

Következik a hét ellenőrzés, sorrendben. Az első a „nem működik” és a „nem megfelelően működik” problémákat fogja meg; a középsők a biztonsági résekkel és a kitalációkkal foglalkoznak; az utolsók pedig a publikálás előtti védelmet adják. Érdemes sorban végigmenni rajtuk: mindegyik a korábbi ellenőrzés sikeres elvégzésére épül.

1. ellenőrzés: Kérd meg az AI-t, hogy hétköznapi nyelven magyarázza el a kódját#

Te szavakkal írtad le a feladatot. Az AI kóddá fordította. A két lépés között elveszhet a jelentés: az AI másképp érthetett, a te nevedben dönthetett el dolgokat, vagy rövidíthetett az úton. A különbséget kódolvasás nélkül is észreveheted — csak kérd meg, hogy hétköznapi nyelven írja le, mit csinált.

Magyarázd el hétköznapi nyelven, kód nélkül, pontosan, mit csináltál az imént:

milyen feladatot old meg ez a kód

mi történik, amikor a felhasználó rákattint a gombra vagy elküldi az űrlapot

hol tárolódnak az adatok, és ki fér hozzájuk

mi romolhat el, és milyen helyzetben

Úgy fogalmazz, mintha valakinek magyaráznád el, aki még soha nem programozott. Ha valamiben nem vagy biztos, hogy helyes, mondd ki világosan.

Olvasd el a választ, és hasonlítsd össze azzal, amire gondoltál. Ha egyezik, lépj tovább. Ha az AI „mellébeszél”, összezavarodik a saját magyarázatában, vagy mást ír le, mint amit kértél, akkor nem érti teljesen, mit épített. Kérd meg, hogy pontosítás után dolgozza át, ne fogadd el feltétel nélkül a válaszát.

Egyébként ha az AI rendszeresen mást csinál, mint amit kértél, gyakran a feladat megfogalmazásával van gond, nem magával a modellel. Külön cikkben fejtettem ki, miért nem azt csinálja Claude, amit kértél.

Az AI kimenetének ellenőrzése a kontextusmérnökség része: te szabályozod, mit adsz bemenetként az AI-nak, és azt is, hogyan értékeled kimenetként az eredményt.

2. ellenőrzés: Menj végig a helyzeteken úgy, ahogyan egy valódi felhasználó tenné#

Az AI-bemutató mindig az ideális útvonalat követi: helyes adatok, egy kattintás, minden sikerül. A valódi felhasználók nem így viselkednek. Hibáznak, rossz helyre kattintanak, vagy emojit írnak a telefonszám mezőjébe. A te feladatod, hogy úgy haladj végig a projekten, ahogyan ők tennék.

1. Végezd el a fő folyamatot az elejétől a végéig

   Tedd azt, amiért a projekt létrejött: regisztrálj, adj le rendelést, küldj be egy kérelmet. Menj végig az egészen, ne állj meg félúton.

2. A fizetést külön és valódi módon ellenőrizd

   Ha a projekt fizetést fogad el, tesztmódban fizess ki magad egy minimális összeget. Győződj meg róla, hogy létrejött a rendelés, megváltozott az állapota, és e-mail érkezett neked és az ügyfélnek. Az a klasszikus csendes hiba, amikor a fizetés „átmegy”, de nem jön létre rendelés.

3. Szándékosan ronts el dolgokat

   Hagyj üresen mezőket. Számok helyére írj betűket. Kattints egymás után kétszer a „Küldés” gombra. Tölts fel rossz formátumú fájlt. Egy jó projekt udvariasan jelzi, hogy „ezt nem teheted meg”; egy rossz összeomlik vagy csendben elnyeli az adatokat.

4. Nyisd meg telefonon

   A felhasználóid fele telefonról érkezik majd. Ellenőrizd, hogy nem esett-e szét az elrendezés, és ugyanazok a gombok ott is működnek-e.

Add át az AI-nak egyetlen listában mindazt, amit találtál: „Ezek romlottak el ezekben a lépésekben; javítsd ki, és magyarázd el, miért történt.” Ne egyesével kezeld a problémákat — add át a teljes listát, hogy az AI átlássa az egészet, és kisebb eséllyel rontson el valamit, miközben egy másikat javít.

3. ellenőrzés: Kérdezd meg az AI-t a biztonságról — itt egy prompt#

A hibás gombot azonnal észreveszed. A biztonsági rést nem: a projekt úgy működik tovább, mintha minden rendben lenne, amíg valaki ki nem használja. A vibe codinggal készített projektek leggyakoribb problémái a közvetlenül a kódba írt titkos kulcsok, az internetnek kitett adatbázis és a rosszindulatú bemenetet elfogadó űrlapok. Az AI mindezt megtalálhatja, ha egyenesen rákérdezel.

Végezz biztonsági auditot ezen a projekten, és minden megállapítást magyarázz el hétköznapi nyelven, szakzsargon nélkül. Menj végig ezen a listán:

Ellenőrizd, hogy vannak-e közvetlenül a kódba írt titkos kulcsok, jelszavak vagy tokenek. Privát titkokat csak szerveren szabad használni, a helyi titokbeállítás, például .env legyen kizárva a Gitből. A .env és .gitignore nem akadályozza meg frontend/public változók böngészős buildbe kerülését. Nézd meg a kliensnek ténylegesen küldött JavaScriptet, source mapeket, HTML-t és hálózati válaszokat, és igazold a privát kulcsok hiányát.

Ellenőrizd, hogy az adatbázis elérhető-e az internet felől, és kik férnek hozzá.

Ellenőrizd, hogy a bevitt adatok feltörhetik-e az űrlapokat: például adatbázis-lekérdezésekbe injektált kóddal vagy a szövegmezőkbe beírt extra kóddal.

Mi történik, ha egy felhasználó rosszindulatú adatot küld be?

Ellenőrizd, hogy elérhetők-e jelszó nélkül belső oldalak vagy az adminisztrációs felület.

Minden pontnál mondd meg, hogy van-e probléma, adj egy egyértelmű példát a kockázatra, és magyarázd el, hogyan kell kijavítani. A legveszélyesebb problémával kezdd.

Azt is ellenőrizd, hogy a projekted nem tesz-e meg vakon mindent, amit kívülről kap. Ezt indirekt prompt injectionnek hívják: egy e-mailbe, megjegyzésbe vagy valaki más fájljába rejtett parancsot az AI-ügynököd feladatnak néz, és követ. Ha a projekt külső adatokat olvas, és azok alapján cselekszik, kérdezd meg az AI-tól, mi történne, ha ezek az adatok rejtett utasítást tartalmaznának.

Ez egy mély téma, amelyet egyetlen prompt nem fedhet le teljesen. Ha a projekt pénzt vagy ügyfelek személyes adatait kezeli, olvasd el a külön útmutatót a vibe coding biztonságáról.

4. ellenőrzés: Kitalált könyvtárakat vagy adatokat az AI?#

Az AI magabiztosan ír olyan dolgokat, amelyek nem léteznek. Hozzáadhat egy hihető nevű könyvtárat, amely valójában nem létezik. Tesztcélú helyőrzőket is hagyhat a projektben: egy „Example” nevű terméket, az example@example.com e-mail-címet vagy valódi tartalom helyetti kitöltőszöveget. Egy bemutatóban ezt könnyű nem észrevenni, de valódi felhasználók előtt kínos vagy hibás lesz.

Két lépésben szűrheted ki. Először kérdezz rá közvetlenül:

Nézd végig a projektet, és válaszolj őszintén:

Valóban létezik és megfelelően telepíthető minden külső eszköz és könyvtár, amit hozzáadtál? Kitaláltál bármit?

Maradtak tesztelési helyőrzők, példák vagy kitöltőszövegek valódi adatok helyén?

Valódiak a projektben található hivatkozások, címek és elérhetőségek, vagy csak helyőrzők?

Sorold fel, mit találtál, és javasold, mire cseréljem ezeket.

Másodszor egyszerűen futtasd a projektet, és nézd át. Egy kitalált könyvtár szinte mindig hibát okoz indításkor. A helyőrzőket pedig könnyű észrevenni: ha az oldal azt írja, hogy „1. termék”, még nem cserélted le őket.

A kitalált könyvtárak külön veszélyt jelentenek, mert a támadók szándékosan olyan nevű eszközöket regisztrálnak, amelyeket az AI szeret kitalálni. Ha telepítesz egy ilyet, valaki más kódja kerülhet a projektedbe. Ezért kell komolyan venned a kérdést, hogy „létezik-e egyáltalán ez a könyvtár?” — közvetlenül a projekted biztonságáról van szó.

5. ellenőrzés: Kérj meg egy második modellt, hogy ellenőrizze az elsőt#

Az AI-nak van egy kellemetlen tulajdonsága: egyetért. Kérdezd meg, hogy „minden rendben van itt?”, és meg fogja erősíteni, hogy minden rendben van, mert az elvárt válaszhoz igazodik. Ezt AI-szervilizmusnak hívják, és külön is írtam róla. Egy ilyen beszélgetőtárs elnéző lesz a saját munkájával.

A megoldás egyszerű: kérj második véleményt. Nyiss új munkamenetet, vagy használj másik modellt, és add oda neki a projektet a 3. ellenőrzésben szereplő prompttal, egy kiegészítéssel: „egy másik AI írta ezt a kódot; keresd meg a gyenge pontjait”. Az új modell nincs az előző beszélgetéshez kötve, ezért nagyobb eséllyel mutat rá a problémákra.

1. Nyiss tiszta munkamenetet, vagy használj másik modellt

   Használj egy második modellt, vagy ugyanazt egy új ablakban, korábbi feladatelőzmények nélkül.

2. Add át neki a projektet, és fogalmazd meg helyesen a feladatot

   Mondd ki világosan: „egy másik AI írta ezt a kódot; a feladatod az, hogy hibákat és kockázatokat találj, ne dicsérd”. Ez visszafogja a szervilizmust.

3. Hasonlítsd össze a két véleményt

   Ha mindkettő egyetért, valószínűleg igazuk van. Ha nem értenek egyet, vizsgáld meg azt a pontot — ott kezd érdekes lenni a dolog.

Pontosan ez történik most az iparágban: az AI ír, az AI ellenőriz, a végső döntés pedig az emberé marad. Nem bízhatod ezt a modellre — ez a te feladatod.

6. ellenőrzés: Hogyan állíthatod vissza, ha egy módosítás elront valamit?#

Az ellenőrzések gyakran módosításokhoz vezetnek, a módosítások pedig néha elrontják azt, ami korábban működött. Hogy ebből ne legyen katasztrófa, minden javítási kör előtt mentsd el a működő verziót gitben. Olyan ez, mint amikor elmented a játékot: ha elrontasz valamit, töltsd be az utolsó mentési pontot.

Ehhez nem kell kódot olvasnod. Csak kérd meg az AI-t: „mentsd el a jelenleg működő verziót gitben egy egyértelmű címkével, mielőtt bármit megváltoztatnál”. Ha pedig a módosítások után minden félresiklik: „állítsd vissza a projektet a korábban elmentett verzióra”.

Ha a git még ismeretlen terep számodra, két útmutatóm is van: hogyan állítsd vissza a módosításokat a Claude Code-ban, és mit tegyél, ha az AI törölte az adatbázisodat. A második arra az esetre szól, amikor már késő a visszaállításhoz, de még helyreállíthatod az adatokat.

7. ellenőrzés: Mit ellenőrizz utoljára a publikálás előtt?#

Az első hat ellenőrzés arról szól, mit csinál a kód. A hetedik azt vizsgálja, hogy a projekt készen áll-e arra, hogy emberek elé kerüljön. Itt botlanak meg leggyakrabban: a projekt működik, de elfelejtik a tesztkulcsot éles kulcsra váltani, így az első ügyfelek „álfizetést” teljesítenek.

1. Fizetés: tesztről élesre

   Ha fogadsz el fizetést, győződj meg arról, hogy a fizetési rendszer éles kulcsa van csatlakoztatva, nem a tesztkulcs. Végezzen egy valódi fizetést a minimális összeggel, majd térítsd vissza magadnak.

2. A titkok a megfelelő helyen vannak

   Kérdezd meg az AI-t: „A privát kulcsok csak szerveren használatosak, a .env pedig kizárt a Gitből? A tényleges böngészős buildben vagy bármely kliensválaszban van privát kulcs frontend/public változón vagy source mapen keresztül is?” A buildelt fájlokat és böngészős hálózati válaszokat ellenőrizd, ne csak a forrás .env-et. A Gitből kizárás nem tartja távol az értéket a frontendcsomagtól.

3. Készíts biztonsági mentést az adatokról

   Győződj meg arról, hogy valahová automatikusan mentődik az adatbázis. Ha a projekted a saját szervereden fut, a Coolify útmutatóban elmagyarázom, mit tegyél a publikáláshoz.

4. A publikált projekt a saját eszközödön kívül is működik

   Nyisd meg a projektet a telefonodon külső hivatkozással, ne csak a saját számítógépeden. Ami helyben működik, nem feltétlenül működik publikálás után is.

Menj végig mind a négy ponton, és nyugodtan megmutathatod a projektet másoknak. Ha valami nem stimmel, jobb most rászánni fél órát, mint később elégedetlen ügyfelekkel foglalkozni.

Mi van, ha az ellenőrzés túl sokáig tart — bízz meg egyszerűen az AI-ban?#

Értem a kísértést. Az ellenőrzés unalmasnak tűnik, és „nem ezért használok AI-t”. De az eredményért te felelsz, nem a modell. Az AI-nak nincs hírneve, és nem kell következményekkel szembenéznie: elkészítette a kódot, aztán megfeledkezett róla. Neked kell válaszolnod annak az ügyfélnek, akinek nem ment át a fizetése.

A Claude Code alkotója ennél tágabb nézőpontból közelíti meg a kérdést:

A kódírás már nem szűk keresztmetszet — az AI elintézi. Most máshol van az érték: a feladat megértésében és a kapott eredmény ellenőrzésében. Ez az erősséged — nálad jobban egyetlen külső fejlesztő sem tudja, mit kell kapnia az ügyfelednek.

Miért készség az ellenőrzés, és miért nem egyszeri feladat?#

Ez a hét ellenőrzés jelenti a különbséget aközött, hogy „elindítottam és reménykedem”, illetve hogy „elindítottam és tudom, hogy működik”. Menj végig rajtuk egyszer, és máris a legtöbb meglepetést kiszűröd, mielőtt az ügyfeleid találkoznának velük.

Innentől szokássá válik. Add meg az AI-nak a megfelelő kontextust bemenetként, és ellenőrizd az eredményt kimenetként; minden új projekt gyorsabban áll majd össze, mert nem kell mindent elölről kezdened.

További anyagokat az eszközhasználatról az Ailoot dokumentációjában találsz.