AI-asszisztált fejlesztés. Az ötlépéses munkamódszer

A kiindulás

Két minta, amit újra és újra látok

Amikor fejlesztőkkel dolgozom együtt az AI bevezetésén, két viselkedés tér vissza minden alkalommal. Az egyik a bemásol és reménykedik. A fejlesztő fog egy feladatot, beírja egy chat ablakba, megkapja a kimenetet, beilleszti a kódbázisba, és bízik benne, hogy működik. Ez lassú, és a hibák csak később derülnek ki, jellemzően akkor, amikor már drága javítani rajtuk.

A másik minta strukturált. Az AI itt is dolgozik, de nem egyetlen mindentudó dobozként. Több eszköz veszi át egymástól a munkát, mindegyik egy jól körülhatárolt szakaszban, és a fejlesztő végig látja, mi történik. Ezt a második módszert olyan csapatoknál láttam kialakulni, ahol a fejlesztők komolyan veszik, hogy az AI-ból akkor lesz sebesség, ha rend van körülötte. Ahol bevezettük, ott a csapat érezhetően gyorsabban szállít, és kevesebb hibát is enged tovább.

A gondolat

Az AI a gyártósor egy állomása, nem az egész üzem

Az egész módszer egyetlen elven áll. Az AI végezze a monoton, strukturális munkát, a fejlesztő pedig arra figyeljen, ami valódi ítéletet kíván, az architektúrára, a minőségre és a döntésekre. Ez nem arról szól, hogy az AI leváltja a fejlesztőt, hanem arról, hogy felszabadítja a figyelmét az értékes munkára.

Amikor egy eszköz mindent csinálhat, valójában semmiért nem felel. Amikor viszont minden eszköznek pontosan egy szerepe van, a hibák ott bukkannak fel, ahol még olcsó megállítani őket. A rendszer öt eszközből és hat konfigurációs fájlból áll, és a legfontosabb része nem az, amit az AI csinálhat, hanem az, amit nem.

1. eszköz

Claude Code, a strukturálás

Az első állomás az Anthropic parancssori eszköze, a Claude Code. A lényege, hogy az egész projektkönyvtárat látja, nem csak egy megnyitott fájlt. Végigolvassa a kódbázist, keres benne, és a teljes kontextus alapján generál.

Ebben a rendszerben egyetlen dolga van. Megkapja a feature leírását emberi nyelven, és felépíti a vázat, a fájlokat, az interfészeket, a függvényszignatúrákat, az adatfolyam csontozatát. A cél nem a kész kód, hanem az üres lap paralízisének megtörése és egy körülbelül 70 százalékos megvalósítás, amiből már egyértelmű, merre kell tovább menni.

Azért működik jól, mert a Claude Code nem a levegőből talál ki API-kat. A projektben lévő valódi email szolgáltatásra hivatkozik, mert elolvasta a forrását. A maradék 30 százalékot pedig szándékosan hagyja másra. Ott nő meg a hibázás esélye, ott lesz bonyolultabb a kód, és ott egy másik eszköz jóval jobb, mert valós időben lehet korrigálni.

2. eszköz

Cursor, a finomítás

A második állomás a Cursor, egy Visual Studio Code alapú szerkesztő beépített AI-val. Egyetlen dologban tér el a legtöbb kódgeneráló eszköztől. A kódot valós időben írja, szó szerint látni, ahogy betűről betűre megjelenik a képernyőn.

Itt finomodik a Claude Code 70 százalékos váza. A fejlesztő szeme előtt bővül, javul, egészül ki. Három módban dolgozik, apró egysoros kiegészítésekkel, nagyobb átírásokkal, és beszélgetéssel az adott fájlról. Ez a rendszer legokosabb része, mert a hibás irány valós időben látszik, és azonnal megállítható.

Ha a Cursor elkezd valami rosszat írni, öt másodpercen belül le lehet állítani és korrigálni. Amikor viszont a Claude Code 300 sort ad egyszerre, és csak utólag nézed át, sokkal több hiba csúszik át, és a javítás is hosszabb. Ezért van az eszközök között ez a sorrend. A nagy, strukturális munka az egyik helyen történik, a finom, ellenőrzött csiszolás a másikon.

3. eszköz

Gyors szűrés még a feltöltés előtt

A harmadik állomás egy gyors ellenőrzés, mielőtt bármi elhagyná a helyi gépet. A CodeRabbit egy AI alapú kódfelülvizsgáló, aminek van szerkesztőbővítménye. Mielőtt a fejlesztő egyetlen sort is a GitHub felé küldene, lefuttat egy helyi ellenőrzést. Keresi az ottfelejtett debug sorokat, a megmaradt jelölőket, a típushibákat, a hiányzó hibakezelést az aszinkron függvényekben, a túl hosszú függvényeket.

A logika egyszerű. Egy problémát olcsóbb itt megállítani, mint a felülvizsgálatnál. Ha a bővítmény elkap egy komoly hibát, két perc alatt javul. Ha ugyanaz a hiba a PR-ig jut, és egy kolléga veti fel, az egy egész kört jelent, megjegyzést, javítást, újbóli feltöltést, újbóli átnézést.

4. eszköz

Mély elemzés a megnyitott PR-en

A negyedik állomás ugyanaz a CodeRabbit, de GitHub alkalmazásként. Minden megnyitott PR-en magától lefut, és odaírja az észrevételeit. Mélyebbre ás, mint a szerkesztőbővítmény. Biztonsági réseket keres, gyanús adatbázis lekérdezési mintákat, tesztlefedettségi hiányokat, az architektúrával nem egyező megoldásokat, és összeveti az API kontraktust az alap ággal, hogy nincs-e törő változás.

Mivel automatikusan fut, a fejlesztőnek nem kell elindítania. Mire az ember reviewer nekiül, már ott egy kész elemzés, amit elolvashat. Így az emberi átnézés arra a részre koncentrálhat, ami valódi ítéletet kíván, az architektúrára és az üzleti logikára, nem az apró dolgokra. Egy jól beállított szabályfájllal ez az eszköz külön figyelmet fordíthat az érzékeny útvonalakra, például az autentikációs kódra, ahol egy hiba a legdrágább.

5. eszköz

Az ember mint végső kapuőr

Az ötödik állomás a staging környezet és a tesztcsomag, amit ember futtat és ember hagy jóvá. Az AI segít megírni a tesztek vázát, de a tényleges elvárásokat a fejlesztő fogalmazza meg. A CI minden PR-en lefuttatja a teszteket, az éles kiadás viszont mindig emberi döntés marad. A folyamat automatikusan csak a staging környezetbe tol ki.

Ennek egyszerű oka van. Az AI nem lát bele az üzleti kontextusba. Meg tudja írni, hogy egy teszt a felhasználó adatait várja vissza, de azt már nem tudja, hogy ez az elvárás helyes-e a cég szabályai szerint. A fejlesztő tudja, és ezért az övé az utolsó szó.

A rögzítés

Hat fájl, ami mindenkinél ugyanúgy állítja be az AI-t

A módszer attól válik megismételhetővé, hogy hat konfigurációs fájl rögzíti. Ezek nélkül minden fejlesztő a saját szokása szerint használná az eszközöket, és a rendszer szétesne. Nem mindegyiket írom le, de a lényegesek megmutatják, mire valók.

A CLAUDE.md a projekt gyökerében ül, és a Claude Code minden induláskor elolvassa. Ez mondja meg, hogy először a feladat terjedelmét értse meg, és csak utána generáljon, sose ugorjon azonnal implementálásba. Itt van a válaszonkénti sorlimit is, ami megakadályozza, hogy egyszerre 500 sor érkezzen. És itt van a talán legfontosabb biztonsági szabály. Ha az AI bizonytalan valamiben, kötelező megjelölnie, nem írhat magabiztosan olyat, amiről nem biztos. Ez az egyik legerősebb védelem a hallucinációk ellen.

A CLAUDE.md sorolja fel azt is, hova tilos az AI-nak döntést engednie. Az adatbázis séma, az API kontraktus, az autentikáció, a titkosítás és a kiadás sorrendje mind emberi terület. Nem korlátozásból, hanem azért, mert ezeken a pontokon egy gépi hiba a legdrágább.

A .cursorrules a Cursor viselkedését állítja be. A legfontosabb korlát itt a Composer módra vonatkozó sorlimit, mert ez az a hely, ahol az eszköz egyszerre nagyon sok kódot tudna ontani. Egy másik szabály megköveteli, hogy a Cursor mindig olvassa el az egész fájlt, mielőtt hozzányúl. A kitalált hívások jó része abból ered, hogy az AI egy fájl töredékéből következtet az egészre.

Az AGENTS.md formalizálja a teljes csővezetéket. Leírja, melyik szakaszban mit tehet az AI, olvashat, létrehozhat, szerkeszthet, tesztet futtathat, PR-t nyithat. Egyetlen művelet viszont sehol nem szerepel a megengedettek között, a telepítés. Egyik szakaszban sem tolhat ki az AI éles környezetbe.

A felülvizsgálati checklist 24 pontja az emberi átnézést teszi következetessé. Külön blokk figyel a gépi kód tipikus hibáira, az ottfelejtett jelölőkre, a laza típusokra, a kitalált import útvonalakra. A biztonsági pontok a beégetett titkokat és a megkerült jogosultsági ellenőrzéseket keresik, mert ezek a leggyakoribb bajok az AI által generált kódban. A maradék két fájl a napi ritmust és a telepítést rögzíti, az egyik az eszközök helyes sorrendjét, a másik a körülbelül 45 perces beállítást.

A gyakorlatban

Egy budapesti fejlesztőcsapatnál mit változtatott

Egy budapesti SaaS céghez hívtak, ahol a fejlesztők már használtak AI-t, de kaotikusan. Volt, aki mindent a Claude Code-ra bízott, és utólag napokat töltött a hibák keresésével. Volt, aki csak a Cursort nyomta, és elvesztette a projektszintű rálátást. A felülvizsgálati körök elhúzódtak, mert a triviális hibák is a kollégákon csattantak.

Amikor felállítottuk náluk ezt a rendszert, nem új eszközt vezettünk be. Ugyanazokat használták, csak megszabott sorrendben és megszabott szereppel. A CLAUDE.md és a .cursorrules bekerült a repóba, a CodeRabbit ráült a PR-ekre, a checklist pedig a felülvizsgálat része lett. Két hét alatt a review átfutása a felére csökkent, mert a fejlesztők már nem a debug sorokkal foglalkoztak, hanem az architektúrával. Ami a legjobban meglepte őket, az volt, hogy nem lassabb lett a munka a sok szabálytól, hanem gyorsabb.

Az eredmény

Honnan jön a gyorsulás

A gyorsulás nem onnan jön, hogy az AI megírja a kódot. Onnan jön, hogy a fejlesztő nem áll tehetetlenül az üres lap előtt, mert a Claude Code ad egy kiindulópontot, amit könnyebb javítani, mint a semmiből indulni. Onnan jön, hogy a felülvizsgálat valós idejű folyamat, nem egy nagy kupac kód utólagos átnézése. Onnan jön, hogy az automata eszközök leszedik a triviális hibákat a reviewer válláról. És onnan jön, hogy a konfigurációs fájlok miatt mindenki ugyanúgy dolgozik, nem a saját fejlesztési kultúrája szerint.

A sebesség pedig nem megy a biztonság rovására, mert az emberi kapuk a helyükön maradnak. Az AI sosem dönt egyedül architektúráról, biztonságról vagy kiadásról. A gyorsulás abból fakad, hogy a figyelem oda kerül, ahol számít, és nem oda, ahol egy gép is elvégzi a munkát.