Agentic Coding - az AI, mint programozó

Az AI (pontosabban az LLM-ek) igen gyorsan fejlődnek az utóbbi időben, már elkerülni is nehéz őket a mindennapokban - a Google keresőjében, a levelezőnkben, a böngészőnkben, a mobilunkon, a közösségi médiában, mindenhova beintegrálták, és szembe jön, ha szeretnénk, ha nem. Egy ideje már azt is nagyon mondogatják, hogy a programozókat is ki fogja váltani, és megjelent a vibe coding kifejezés is, ami arra utal, hogy a fejlesztők már csak a hangulatot (vibe) adják meg, az AI pedig megírja a kódot.

Én kb. a kezdetektől (amikor megkaptam a béta Copilot-ot, eléggé az elején) használom, főként, mint okos(abb) kódkiegészítőt, illetve újabban néha meg-megkérdeztem olyan témákban, amikhez ritkán kell nyúlnom, és nem pontosan emlékszem a részletekre, de komplett programokat, vagy nagyobb kódrészleteket soha nem generáltam vele. Kb. idén év elejéig a vibe codingot is főként egy játéknak tekintettem, és hát a legtöbb történet, amivel a közösségi médiában találkoztam, az is inkább vicces, vagy érdekes volt, mint komoly - pl. hogy valaki mindenféle programozási ismeret nélkül, csak úgy “vibe”-olva, az AI segítségével csinált egy komplett szolgáltatást, és máris pénzt keres vele, aztán pár nap múlva jelentkezett, hogy feltörték a szolgáltatását, és fogalma sincs, mit csináljon, hiszen ügyfelei is vannak, honnan kaphatna segítséget, …

Aztán úgy idén év eleje óta olyan olyan szakemberek is pozitívan nyilatkoztak a témáról, akiknek adok a véleményére (pl. Armin Ronacher), és a redditen is előkerültek számomra is hihető történetek, úgyhogy tavasz végén úgy gondoltam, hogy belevágok egy kísérletbe, és vájb kódolok egy egyszerűbb webalkalmazást. Amit csak lehet, az AI agentekre bízok, én csak akkor nyúlok a kódhoz, ha valamiért nagyon muszáj.

TL;DR: Az elején szkeptikus voltam, de mostanra lett egy új barátom, Klód, aki esténként, amíg a kertben mókolunk, vagy hosszú unalmas meetingek alatt szépen fejlesztgeti nekem a live-tracker projektemet.

A projekt⌗

Valami értelmes projektet szerettem volna csinálni, nem egy újabb TODO appot, és mivel sokat futok terepen, akár egyedül is hosszabbakat, szeretem, ha tudják az ismerősök, hogy épp merre járok. Ehhez eddig Garmin livetrack linkeket küldözgettem, de az picit körülményes, és amint vége a futásnak, már nem is elérhető, úgyhogy gondoltam, jó lenne valami ilyen live-tracker, amit később ki is lehet bővíteni, pl. egész csapat követésével - a hosszú váltók (pl. UB) során ez jó lehet olyanoknak is, akik az egész csapatot szeretnék egyben követni.

Az MVP egy sima egy felhasználós weboldal lett volna, ami engem tud követni, de aztán ennél jóval messzebbre jutottunk:

• több felhasználó (de regisztráció nincs), profil szerkesztés
• valós idejű helymegosztás
• livetrack session-ök elnevezése, visszanézhetősége
• felhasználók utolsó publikus helyeinek térképes megjelenítése a főoldalon
• mobil barát felület
• dark mode

Hogy tudjam is trekkelni a helyzetemet, az egyik Garmin adatmezőmet kiegészítettem ilyen képességgel. Ehhez is próbáltam AI segítségét kérni, de akkor még csak Geminit használtam, ami nem boldogult jól az - egyébként valóban egzotikus, és keveset használt - Garmin Monkey-C nyelvvel, úgyhogy azt inkább magam írtam meg. Az azóta szerzett tapasztalatokkal majd újra nekiveselkedek, úgyis kell egy általánosabb verzió is.

(itt elérhető, de egyelőre elég kísérleti, és csak drágább órákon működik)

A tech stack⌗

Az internetes beszélgetések alapján arra jutottam, hogy valami egyszerűbb (kezdőbarátabb) nyelvet válasszak, és minél kevesebb külső függőséggel induljak neki. A redditen a Python és (sima) JavaScript mellett a Go is többször felmerült, mint jó választás, mert relatíve egyszerű, de mégis rendesen típusos, így a backendhez azt választottam. Illetve nem akartam 0-ról indulni, így a PocketBase lett a backend, ami egy egyszerű, REST API-t is kínáló backend megoldás, és van hozzá egy elég jó admin felület is.

A frontendhez a sima HTML/CSS/JS mellett döntöttem (webkomponensekkel), és bár a typescript lenne az egyértelmű választás, ha én magam írnám a kódot, azt olvastam, hogy a komplexebb típusokba bele tudnak zavarodni az AI-k, úgyhogy maradtam a sima JavaScriptnél, ráadásul ezzel mindenféle build system nélkül is elindulhattam.

Backend: PocketBase (Go)

Frontend: HTML/CSS/JS (webkomponensek)

Agentic coding kísérlet⌗

25+ éve terminált használok mindenre, ezért adta magát, hogy terminálban futó megoldást válasszak - hiába van már évek óta Github Copilot előfizetésem, ami be tud épülni több IDE-be is, ezt nem használom ki teljesen. Amikor elkezdtem gondolkodni a kísérleten, akkor az internet népe épp migrált át a Cursor-ról Claude-ra, és már épp fizettem volna elő a Pro változatra, ahol elérhető a Claude Code terminálos agent, amikor a Google ingyenesen elérhetővé tette a Gemini CLI agentjét, úgyhogy inkább azt kezdtem el használni.

Első tapasztalatok⌗

Június 25-én jelentették be a Gemini CLI-t, estére kész volt az MVP.

Oké, a feladat nem volt azért szuper bonyolult, de tapasztalatom is szinte nulla volt az AI agentek ilyen jellegű használatában, és tényleg vállalható volt, amit csinált, pláne egy tech demónak.

✅ gyors demók összerakása proof-of-concept jelleggel

Lépjünk tovább⌗

A cél a technológia határait feszegetni, szóval nem állhattam meg itt, jött a több felhasználó támogatása.

És az első probléma. A tervet látszólag nagyon ügyesen lehozta Gemini, de a kivitelezés során bizony előjöttek problémák. A PocketBase nem egy nagyon elterjedt megoldás (de azért van 50k+ csillagja githubon), valószínűleg kevés kapcsolódó példakódon lett tanítva a modell, illetve a dokumentációt is hiába olvasgatta, elkezdett nem létező metódusokat hallucinálni, illetve ezek kitörlésével, majd újra visszaírásával loopba is került, kénytelen voltam segíteni neki. Ekkor még túl lelkes voltam, inkább megírtam a kérdéses két sort én, és mentünk tovább, de kb. ekkor nyúltam a kódhoz először és utoljára.

❌ kevésbé ismert technológiák esetén a modell hajlamos lehet hallucinálni, és loopba kerülni

A Garminos adatmezőm kibővítésénél lényegében Java (jellegű) kódot akart írni, ami ott nyilván nem működött, úgyhogy ott nem is erőltettem, inkább magam írtam meg.

Docker⌗

Mindenesetre kész lett valami használható, ki akartam rakni kvázi élesbe, hogy kipróbálhassam rendesen. A NAS-omon minden hasonló szolgáltatás dockerben fut, úgyhogy a következő lépés a dockerizáció lett.

És itt mutatkozott meg egy újabb előnye az AI agenteknek: kb. fél évente egyszer írok 0-ról dockerfile-t, és mindig elfelejtem a szintaxist, tehát keresgéléssel és dokumentáció olvasgatással kezdem a dolgot. Most ez kimaradt, Gemini fél pillanat alatt megírta nekem a dockerfile-t, lebuilde-elte, kipróbálta, megkért, hogy lépjek be (docker login), és fel is töltötte a DockerHub-ra.

✅ ritkán használt, de egyébkent egyszerű, jól dokumentált feladatoknál gyorsan tud segíteni

GPX upload mini tool⌗

Kész volt az API, a webes felület, és végül is az órámon is ott volt a trackelésre alkalmas adatmező, de épp nem volt kedvem elmenni futni, hogy legyen éles adat, és kellett valami, amivel fel tudok nagyobb útvonalat tölteni, hogy kipróbáljam a működést. Percek alatt született meg a gpxup nevű kis programocska, ami egy GPX fájlt feltölt az API-n keresztül.

✅ kis toolok, script-ek gyors összedobása

Claude⌗

Mivel közben mindenhol azt olvastam, hogy hát lehet próbálkozni a többi agenttel is, megfelelően promptolva azok is egész jó eredményt tudnak elérni, DE pariban sincsenek Claude-dal, ezért úgy döntöttem, hogy csak befektetek egy Pro előfizetésbe, és kipróbálom azt is.

Mindenhol azt javasolják, hogy hiába olcsóbb az éves előfizetés, annyira gyorsan változnak a dolgok, hogy inkább havi díjasat vegyél, és ha kell, bármikor le tudod mondani és váltani az aktuális legjobb megoldásra.

Azt kell, hogy mondjam, hogy - az én workflow-mban - Claude teljesen más ligában játszik, mint minden más, amit eddig (a blogpost megírásáig) próbáltam. Jelenleg, ha programozásra szeretnél AI-t használni, akkor Claude Code. (A Pro előfizetés csak a Sonnet-4 modellt tartalmazza, a fejlettebb Opus-t nem, de még így is nagy különbséget éreztem a többi megoldáshoz képest.)

Elszabadultak a feature-ök, belépés, profil oldal, session oldal, dark mode, …

MCP szerverek⌗

Az MCP (Model Context Protocol) egy új szabvány, amellyel az AI modellek használni tudnak külső szolgáltatásokat (adatbázisokat, programokat, …). Eléggé egyszerű (lehet, hogy túlzottan is, majd az idő eldönti), és kb. minden támogatja. Pl. ennek a segítségével az agentek valódi böngészőt is tudnak használni, és meg tudják nézni, illetve debuggolni az általuk készített weboldalakat. ( playwright-mcp )

Amikor Claude a felhasználó avatárját az útvonala végére illesztette, akkor nem tetszett a marker alakja - hiába mondogattam neki, hogy fejre állított csepp alakot szeretnék, valami béna oválist használt (bár esés közben valóban inkább olyan alakúak a cseppek, de na). Már majdnem hozzányúltam én a kódhoz, amikor eszembe jutott, hogy kipróbálhatnám a Playwright MCP-t, és a segítségével sikerült emberi beavatkozás nélkül túljutni a problémán.

Durva refaktor⌗

Ezen a ponton volt egy használható webalkalmazásom, aminek lényegében a backendje egy darab main.go volt, a frontendje pedig néhány HTML és JS file. Hosszú távon ez nem fenntartható - pláne, ha később én is bele kell, hogy nyúljak - ezért úgy döntöttem, hogy megkérem Claude-ot, hogy refaktorálja a kódot.

Mivel sejtettem, hogy ez nagy falat lesz, először részletes tervet csináltattam Claude-dal (sonnet-4), azt átnézettem Gemini-jal (2.5-pro) és Copilottal (GPT-5) - akik hozzá is írtak ezt-azt -, majd a tervet Claude részletesen lebontotta kisebb feladatokra, és úgy indítottam neki, hogy minden nagyobb lépés után álljon meg, és várja meg, amíg átnézem, amit csinált. Ez a módszer nagyon szépen működött, a tervdokumentumokban (backend terv, frontend terv) szépen vezette, hogy hol jár, így másnap - vagy amikor kifogytam az 5 órás limitből - mindig ott tudtuk folytatni, ahol abbahagytuk.

A backend refactor 3 napig tartott, a frontend 2 napig (nem teljes napok, napi 3-4 óra aktív munka), minden lépés után átfutottam, amit csinált, kértem tőle módosításokat, ahol kellett, de összességében nagyon szépen dolgozott, és a végeredmény egy sokkal jobban strukturált, modulárisabb kód lett. A két PR rettenetes méretű lett, de a lelkesebbek átnézhetik, ha van kedvük:

• backend refactor PR ~15ezer+ sor
• frontend refactor PR ~28ezer+ sor

(A backend PR azért failelt el, mert gitguardian megtalálta a Claude-nak létrehozott tesztaccount jelszavát a commitok között. :D Ez természetesen csak az én fejlesztői környezetemben működik, úgyhogy nem kezdtem el miatta a git historyval mókolni.)

✅ komolyabb refactorálás, szigorú felügyelet és tesztelés mellett

Egyelőre itt jár a project, most gondoltam úgy, hogy megírom ezt a blogpostot, és egy kis szünetet tartok, aztán majd meglátom, merre tovább. Lassan lehet eléri azt a méretet is, amit már nehezebben kezel egyben Claude a 200k tokenes limitjével, de egyelőre ennek még nincs jele.

vibe tracker a githubon

Toolok, modellek⌗

Ahogy fentebb írtam, az, hogy éppen melyik modell vagy tool a legjobb, az függ attól is, hogy hogyan használod, milyen feladatot szeretnél megoldani, illetve mire kipostolom ezt a cikket valószínűleg kijött 10 új.

Modellek⌗

Napi szinten jelennek meg újak, a képességeik/áruk/elérhetőségük eléggé változatos, itt lehet nézelődni.

Van, amelyiket csak saját felületen keresztül lehet használni, van, amit tudsz saját magad futtatni (ha van hozzá megfelelő vasad). Ráadásul rengeteg szempont alapján lehet őket értékelni, pl. mennyire jó terveket készít, mennyire generál jó kódot, tud-e toolokat használni (tesztelés, hibakeresés), mennyire követi, amit mondtál neki, mennyire tudja kezelni a hosszabb kontextust, és hát mennyibe kerül. Amelyik modell az egyik szempontból jó, az lehet, hogy egy másikból megbukik, nagyon számít, hogy mire és hogyan használod.

Saját tapasztalatok:

Gemini 2.5 pro és flash (Google)⌗

Gemini CLI-on keresztül használtam ingyenesen, a pro napi limitje egy idő után elfogy, de automatikusan vált a flash-re. Ismerkedni tökéletes, egyszerűbb programozási feladatokhoz se rossz, de azért sikerült loopba vinni, illetve hallucinált is. A cli-os változat előnye, hogy ha látom, hogy tévúton jár, akkor gyorsan meg tudom állítani, és irányba tudom terelni.

GPT-4.1 és GPT-5 (OpenAI)⌗

A Github Copiloton keresztül próbáltam ki őket (a GPT-5 igen friss, a projekt futása közben jelent meg), és opencode segítségével tudtam őket terminálban használni. A ChatGPT felületéről sokaknak ismerős lehet, de nekem vegyesek a tapasztalataim velük, plána a GPT-5 volt hajlamos elkalandozni, és olyan dolgokat csinálni, amiket senki nem kért tőle. A GPT-4.1-nél ez kevésbé tűnt fel, de túl sokat egyikkel sem próbálkoztam, mert a Claude sokkal jobbnak tűnt.

Claude Sonnet-4 (Anthropic)⌗

A legjobb, amit próbáltam, fentebb olvashatóak a tapasztalataim. Mind a tervezésben, mind a kódolásban, mind a refaktorálásban nagyon jól teljesített, sőt, ha belefutott olyan dologba, amit ott hirtelen nem tudott megoldani - vagy úgy érezte, hogy nagyobb effort lenne, mint amire én a kérésem alapján számítok - akkor jelezte, és javasolt alternatív megoldásokat. Ez utóbbit más modelleknél nem tapasztaltam.

A refactor közben volt egy pont, ahol kifutottam a Claude limitéből, és úgy gondoltam, hogy akkor az elkészült részhez csináltatok a friss GPT-5-tel unit teszteket. Szinte sikerült, két függvény rendes teszteléséhez a pocketbase is kellett volna, kimockolni az egészet értelmetlen lett volna, úgyhogy ő úgy oldotta meg, hogy kitörölt dolgokat az implementációból, és a tesztelhető részeket meghagyta. :D

Claude ezzel szemben csak közölte, hogy ahhoz a két függvényhez nem ír unit tesztet, hanem majd érdemes integrációs teszteket írni hozzájuk.

Agentek⌗

Agentekből is rengeteg féle van, a weboldalakat, ahol beszélgetni lehet az LLM-ekkel kb. mindenki ismeri, de vannak kifejezetten programozásra kihegyezett megoldások is:

• parancssoros (CLI/TUI) toolok
  • a modelleket kiadó cégek sajátjai (Gemini CLI, Claude code, OpenAI codex, …)
  • függetlenek, de viszonteladók (Cursor cli)
  • teljesen függetlenek (opencode, crush, …)
• IDE kiegészítők (Github Copilot, Amazon CodeWhisperer, Tabnine, …)
• komplett IDE-k (Cursor, Replit, …)
• Copilot a Githubon (PR-ok generálása, kód review, issue-k kezelése, …)
• …

Az én workflowm⌗

Először is, mielőtt bármit csinálnék, létrehozok egy git/jj repót, és minden lépes után commitolok és pusholok. Az agentek is képesek git-et használni, de egy laza mozdulattal tudják megsemmisíteni az egész repository-t, és ha még push joguk is van, akkor egy apró hiba, és minden elveszik.

A legtöbb eszközben lehet külön programozó és tervező agentet konfigurálni (sőt, ezek általában alapból vannak is, és lehet még másokat is létrehozni), ezek az agentek akár különböző modelleket is használhatnak - pl. a Claude Max előfizetésében elérhető Opus modellt a tervező agent használja, a Sonnet-4-et pedig a programozó, állítólag így a leghatékonyabb a munka.

Én általában plan módban kezdek, és igyekszem úgy megfogalmazni a kérést, mintha egy ticketet fejtenék ki munkában, azaz hogy bármely kolléga el tudjon vele kezdeni foglalkozni mindenféle kérdés nélkül. Megkérem az agentet, hogy készítsen egy részletes tervet, hogyan oldaná meg a problémát. Ha úgy ítélem meg, a tervet még tovább finomítom (esetleg finomíttatom), és csak akkor indítom el az implementációs szakaszt, ha én magam is értem, hogy mit fog csinálni.

Egyelőre (?) nem bízok benne annyira, hogy review nélkül elfogadjam, amit csinál, úgyhogy minden nagyobb lépés után átnézem, amit csinált, ha kell, akkor kérek tőle módosításokat, futtattatok vele teszteket, és csak akkor lépek tovább, ha minden rendben van.

Összegzés⌗

Szkeptikus voltam, amikor kezdtem a kísérletet, de pozitívan csalódtam.

Az LLM alapú AI-kból nem hiszem, hogy valaha AGI lesz, és lehet, hogy lassan el is érik a technológia határait, de a jelenlegi képességeik is elég jók ahhoz, hogy a programozók hatékonyabbak legyenek, és gyorsabban tudjanak haladni a munkájukkal. A kódolás egy része (pl. boilerplate kódok, egyszerűbb funkciók) teljesen automatizálható, és a fejlesztők inkább a tervezésre, az összetettebb problémák megoldására koncentrálhatnak, amikben szintén tud segítséget nyújtani egy okosabb agent.

Elveszik-e a programozók munkáját? Nem hiszem, hiszen a szoftverfejlesztés egy komplex feladat, ahol a kódolás csak egy része a munkának. Kell melléjük a felügyelet, ráadásul a valódi árukat sem ismerjük még, egyelőre szerintem csak a beetetési időszak zajlik, és minden AI cég veszteséges.

Le tudnak-e cserélni egy junior programozót? Az adott pillanatban lehet, de amíg egy juniorban megvan a potenciál, hogy egyszer senior legyen, addig egy AI agent sosem lesz okosabb annál, mint amilyenre be van tanítva, és nem fog tudni fejlődni, tapasztalatot szerezni.

Le tudnak-e cserélni egy olyan programozót, aki kvázi ész (és visszakérdezés) nélkül implementálja a kiadott ticketeket? Igen, de nekik szerintem egyébként sem nagy a hozzáadott értékük. Aztán persze nyilván ők is meg fogják találni (esetleg már meg is találták) a helyüket, és bőszen másolják a ChatGPT böngészőablakba a ticket szövegét, illetve másolják vissza a generált kódot úgy, hogy fogalmuk nincs, mit írnak le. Sajnos napi szinten látok ilyet.

Egy biztos, az LLM-ek remek eszközök lehetnek a szoftverfejlesztők kezében, és még ha nem is fejlődnek tovább ebbe az irányba, akkor is meg fognak maradni. Amire számitok, azok a kisebb, specializáltabb modellek, amiket akár helyben is (saját gépen, akár telefonon) futtathatunk. Kíváncsi vagyok, jövő ilyenkor hol tartunk majd.