Az elmúlt időszak leginkább felkapott kifejezése a „vibe-coding”. Azt ígéri a felhasználóknak, hogy már nem is kell tudni programozni, mert elég az AI ügynöknek természetes nyelven, mintegy vele „beszélgetve” elmondani, hogy mit is szeretnénk, az ügynök pedig legyártja a kész, működőképes programot. Rövid Google keresés alapján százával találunk sikertörténeteket, amelyek arról szólnak, hogy emberek programozási tudás nélkül, pár óra alatt működőképes programot készítettek valamelyik kódoló ügynökkel és tarolnak a piacon. Az évek, vagy évtizedek óta a piacon dolgozó fejlesztők ugyanakkor gyanakodva figyelik ezt az új trendet, sokan a megélhetésüket féltik a kódoló ügynökök elterjedésétől.
Én mindig úgy gondoltam, hogy egy dologról akkor érdemes véleményt mondani, ha megismerjük azt, még ha nem is megyünk bele a legapróbb részletekbe. Nem árt, ha az ember tudja, hogy miről beszél.
Az első találkozás
Jó néhány éve használtam már fejlesztésre a Visual Studio programot, a kódok tárolására pedig sokakhoz hasonlóan a GitHub platformot használtam. Amikor 2021-ben a GitHub elindította a Copilot szolgáltatását, úgy hirdették, mint egy programozó társat, aki megérti az általam megírt kódot és segít azt jobbá tenni. Valamikor 2022-ben döntöttem úgy, hogy adok neki egy lehetőséget és kipróbálom. Bár a 10 dolláros havidíj nem volt eget rengető összeg, de az igazi lökést a 30 napos ingyenes próbaidőszak adta meg. Úgy gondoltam, itt tényleg nincs mit veszíteni.
Nos, ez a 30 nap elég gyorsan elszaladt és be kell vallanom, hogy a Copilot teljesen lenyűgözött. Először csak arra használtam, hogy mások által írt, általam nem teljesen átlátható kódok működését magyaráztattam el. Utána előszedtem olyan régi programjaimat, amikkel elakadtam, vagy amik rejtélyes hibákat produkáltak. És láss csodát, a kódok elemzése után olyan javaslatokat és új szempontokat tudott adni (konkrét kódrészletekkel), amikkel tovább tudtam lépni. De a legnagyobb „durranás” számomra az volt, amikor megtapasztaltam, hogy milyen jól át tudja venni az unalmas, vagy nem igazán szeretett feladatokat. Komplett teszteket ír annyi idő alatt, amennyi alatt én még azt sem igazán tudom átgondolni, hogy milyen eseteket is kéne tesztelni. Ráadásul olyan esetekre is ír tesztet, amikre én nem is gondoltam volna. Pár perc alatt legenerálja egy projekt gerincét, nekem már csak a „húst” kell rápakolni a gerincre. Ráadásul az automatikus kódkiegészítés is a kezem alá dolgozik. Csak elkezdek gépelni és adja a komplett javaslatokat a befejezésre. Ha tetszik, egy gombnyomás és már be is illeszti. Ha nem tetszik, csak gépelek tovább és kis idő múlva már egy módosított javaslatot kapok.
Az egy hónapos használat alatt valahogy úgy éreztem, hogy újra élvezem a programozást. Mintha két segítőt kaptam volna magam mellé. Egy gépelő „rabszolgát”, aki megírja helyettem a hosszú, unalmas és örökké ismétlődő részeket és egy mentort, aki mindig tovább tud lendíteni, amikor elakadok valamiben. A próbaidőszak végén úgy döntöttem, hogy nem mondom le az előfizetést, mert ennyit nekem megér. Természetesen nem volt hibátlan a működése, többször is javasolt olyan kódot, ami magában nem működött, mert hiányzott például egy segédfüggvény, amit „elfelejtett” megírni. De 1-2 finomítás után mindig lett valamilyen eredmény.
Természetesen a Copilot ezen verziója még nem volt a mai értelemben vett kódoló ügynök. Csak javaslatokat adott, de automatikusan nem végzett semmilyen módosítást a kódokon. Nem is hagytam volna, mert szeretem érteni azt, amit végül beépítek a programomba.
Az ügynök színre lép
A Copilot ügynök módja valamikor 2025 elején jelent meg. Ekkor jelent meg a Claude Code is, de voltak már a piacon más szereplők, például a Cursor, vagy a Replit. Az ígéret az volt, hogy ezek az ügynökök már teljesen önállóan, csupán a szöveges prompt alapján képesek komplett programot elkészíteni, melynek során nem csak megírják a kódot, hanem le is futtatják, a hibákat kijavítják és az egész folyamatot addig ismétlik, míg a végén egy hibátlanul működő programot kapunk. Elég szkeptikus voltam a dologgal kapcsolatban, mert bár egy ideje akkor már foglalkoztam az AI egyes területeivel, tanulmányoztam a nagy nyelvi modellek működését, de valahogy nem hittem az egészben. Persze a videó megosztók is gyorsan tele lettek olyan anyagokkal, amik azt bizonygatták, hogy ez a dolog működik, de bennem mindig maradt egy kis hiányérzet. Ugyanis minden ilyen videóban csak viszonylag egyszerű, 1-2 funkciót tartalmazó, amolyan hobbi programok elkészítését mutatták be. De mi a helyzet egy kicsit komolyabb alkalmazással? Ennek a bemutatására valamiért senki nem akart vállalkozni.
Ahogy telt az idő, folyamatosan fejlesztették a Copilot ügynök módját. Folyton jöttek a hírek, hogy milyen új funkciókat kapott, milyen nyelvi modellek érhetők el stb. Bennem pedig egyre erősebben motoszkált az, hogy ki kéne próbálni. Úgy gondoltam, mostanra már biztosan kinőtte a gyermekbetegségeit, javították a kezdeti hibákat. Augusztus közepén aztán vettem egy nagy levegőt és belevágtam.
A teszt
Az elképzelésem az volt, hogy egy nem túl bonyolult fitness alkalmazás elkészítésével teszem próbára a Copilot Agent módját. Mivel itt többféle modell közül is lehet választani, én a Claude Sonnet 4 mellett döntöttem, mert a vélemények szerint ez az egyik legjobb modell a kódoláshoz.
Azt már tudtam, hogy az ügynökök mögött különféle nagy nyelvi modellek dolgoznak, amik igénylik a minél részletesebb kontextust ahhoz, hogy pontos választ tudjanak adni. Ezért egy termékkövetelmény-dokumentummal (PRD) kezdtem. Ennek összeállításához már szintén igénybe vettem a Claude-ot. Egy 5-6 mondatból álló promptban leírtam az elképzelést és generáltattam vele egy PRD-t. 1-2 perc alatt megvolt az eredmény, amin azért még kellett finomítani és pontosítani. 3-4 iteráció után végül összeállt egy olyan anyag, amivel már el lehetett kezdeni a tesztelést. A dokumentum alapján a tervezett alkalmazás az alábbi funkciókra képes:
- felhasználók kezelése (ki/bejelentkezés, saját adatok kezelése)
- fizikai adatok (testsúly, has, comb, mellkas stb. méretek) rögzítése naponta
- admin felhasználó által előre rögzített és a felhasználó által rögzített saját tornagyakorlatok kezelése
- edzések összeállítása a gyakorlatokból, edzés adatok rögzítése (időtartam, elhasznált kalória stb.)
- első körben egy Blazor webes frontend készüljön, de később legyen lehetőség mobil alkalmazás kezelésére is
- az előző pont miatt API felület kialakítása JWT authentikációval
- PostgreSQL adatbázis
- .NET Core környezet, Entity Framework az adatbázis kezeléséhez
Készítettem egy új mappát a projektnek, elindítottam a VS Code szerkesztőt, a PRD-t becsatoltam a Copilotnak és kértem, hogy ez alapján készítse el az alkalmazást. Aztán hátra dőltem és vártam. Némi gondolkodás után beindult a gépezet. A chatablakban folyamatosan látszott, ahogy újabb és újabb fájlok születnek, ezek funkció szerint külön projektekbe szerveződnek. Az adatmodellek és az API elkészülése után a Copilot megállt és kérte, hogy adjam meg az adatbázis szerver hozzáférési adatait. Mikor ezek megadtam, tovább folytatódott a munka. Láttam, ahogy a Copilot elkészíti az adatbázist, lefordítja és futtatja az elkészült programot, felismeri és kijavítja a felmerülő hibákat. Ha a futtató környezet szempontjából kritikusabb részhez ért (például fájlrendszer módosítás), akkor megállt és engedélyt kért a tovább lépéshez. Végül 15-20 perc alatt elkészült az API felület működő adatbázissal és adatmodellekkel. Eddig le a kalappal!
Ekkor feltette a kérdést: „Folytassam a webes frontend felület elkészítésével?” Még szép, azért vagyunk itt!
Újabb 5-10 perc alatt elkészült a Blazor frontend. Az látszott, hogy a projekt lefordítható és futtatható, de vajon működik is? A Copilot jelezte, hogy elkészült, próbáljam ki a programot. És itt kezdődött egy 3 órás szenvedés.
Mivel az volt a célom, hogy leteszteljem az ügynök önálló működését, ezért úgy döntöttem, hogy nem fogok belejavítani a kódba, csak a prompton keresztül kommunikálom a tapasztalt problémákat.
Szóval a program elindult és a böngészőben megjelent a felület. Eléggé minimál dizájn, de nem is ez volt a fókuszban, hanem a működés. Elindítok egy regisztrációt, megadom az adatokat, de az elküldés után nem történik semmi változás. Az adatbázist ellenőrizve nem jött létre új felhasználó. Leírom a problémát az ügynöknek, gondolkodik, majd közli, hogy megtalálta és kijavította a hibát. Újabb próba, ugyanaz az eredmény. Probléma leírása, gondolkodás, javítás. Újabb próba, nem működik. Mivel egy kicsit gyanús volt a dolog, megnéztem a backend API konzolján az üzeneteket. Az látszott, hogy elmegy egy kérés az API felé, de rögtön vissza is dobja 404-es hibával. Szóval sikerült olyan frontend kódot legyártani, ami az általa gyártott API egy nem létező végpontját próbálja hívni! Kicsit értetlenkedve megírom a problémát a Copilot-nak. Gondolkodás, majd jóváhagyólag nyugtázza, hogy tényleg igazam van. Javítja a hibát, most már tudok regisztrálni. A felület szerint be vagyok jelentkezve, bár a felhasználói nevem nem jelenik meg a menüben. OK, ezen most lépjünk túl. Megnyitom a testadatok lapját és megpróbálok adatot rögzíteni. Nem sikerül, mert az elküldés után csak „pörög” a betöltést jelző ikon, de nem történik semmi. Újraindítom az alkalmazást és az előzőekből tanulva már figyelem a konzol ablakok üzeneteit. Ezek alapján az előző bejelentkezésből származó token még megvan, így beléptet az alkalmazás. Újabb próba egy adat rögzítésére, elküldés után a konzolon 401-es hibaüzenet érkezik (Unauthorized). Érdekes. Probléma leírása a Copliot-nak, gondolkodás, ötletek feldobása, javítás, újra próbálás. Nem működik. Végül 3 óra küzdelem, 15-20 javítás után feladtam, mert belefáradtam.
De miért nem működik?
Nem hagyott nyugodni a dolog, ezért 3 nappal később újra elővettem a programot azzal a céllal, hogy kiderítem, miért nem működik. A backend viszonylag egyértelmű, szokásos .NET Core web API. Ami kicsit furcsa volt, hogy a felhasználók kezelésére nem a Microsoft Identity Framework-öt használta, de egyébként minden rendeben lévőnek tűnt. A frontend komponensek szintén elég egyértelműek, HTML elemek némi C# kóddal fűszerezve. Ami feltűnt, hogy szinte az összes komponens be van ágyazva egy AuthComponent nevű komponensbe. Ennek annyi a feladata, hogy ellenőrizze a felhasználó bejelentkezett állapotát és ennek megfelelően vagy az adott komponenst, vagy a bejelentkezési felületet jelenítse meg. Ehhez egy AuthService nevű komponenst használ, ami a böngésző helyi tárolójából megpróbálja kiolvasni a JWT tokent és ez alapján beállítani a státuszt, illetve kiolvasni a felhasználói nevet a tokenből. Erre ráadásul egy külön TokenService komponenst használ.
Próbából elindítottam az alkalmazást és aktívvá tettem a frontend projekt konzolját. Megdöbbenve látom, hogy a felület megjelenítéséig legalább 10 alkalommal hívódik meg az AuthService azon metódusa, ami a felhasználó tokenjének ellenőrzését végzi. OK, erre majd alaposan rá kell nézni. Bejelentkezek a felületen, de a felhasználói név továbbra sem jelenik meg a menüben és adatot sem tudok rögzíteni, mert folyton 401-es hibát küld az API vissza. Kijelentkezni sem tudok. Hirtelen ötlet alapján elindítom a Postman-t és megpróbálom onnan elérni az API-t. A bejelentkezés működik és a visszakapott token alapján tudok adatot is küldeni az adatbázisba, mert innen nem kapok 401-es hibát. Érdekes.
A frontend kód alapos átnézésekor bizony elkerekedett a szemem. Az AuthComponent nevű komponensnek az lett volna a dolga, hogy az AuthService használatával ellenőrizze a felhasználó bejelentkezett állapotát és ennek megfelelően jelenítse meg a beágyazott komponenseket. Viszont a beágyazott komponensekbe külön is be volt injektálva az AuthService és mindegyik külön is ellenőrizte a bejelentkezett állapotot. Miért? Ráadásul, mivel ezek a komponensek induláskor egyszerre próbálták ellenőrizni a felhasználó állapotát, ezért az AuthService mindenféle trükkös lock megoldásokkal próbálta megakadályozni, hogy a komponensek egymással versenyezve állítgassák az állapotot. Pedig sokkal egyszerűbb lett volna, ha az AuthComponent egy paraméteren keresztül tette volna elérhetővé a felhasználó állapotát. Némi munkával „kigyomláltam” ezeket az anomáliákat, egyszerűsítettem pár helyen a kódot és újra elindítottam az alkalmazást. Örömmel láttam, hogy az AuthService már csak egyszer hívódik meg. Viszont az API továbbra is 401-es hibával küldi vissza a kapcsolódási próbálkozásokat.
Itt bizony eltelt vagy 2 óra, mire eredményre jutottam. Beleástam magam a JWT tokenek működésébe, hogyan kezeli a .NET Core a tokeneket, milyen adatot célszerű beletenni a tokenbe. Ezeket ki is próbáltam, eredmény nélkül. A végén már egyesével átmásoltam a Postman kérésekből a HTTP fejléceket a frontend kódba, de ez sem vezetett eredményre. Már éppen feladni készültem a dolgot, amikor az API projekt kódjában megakadt valamin a szemem. A CORS policy beállítások gyanúsak voltak, mert mintha nem szerepelt volna ott a frontend projekt futtatásakor használt URL. Leellenőriztem és tényleg! A frontend olyan URL-ről akart kapcsolódni, ami nem volt felvéve a CORS beállítások közé. Mikor ezt kijavítottam, elkezdett működni a dolog. Hogy ez a Copilot-nak hogyan nem tűnt fel, azt nem értem.
Már csak az maradt megoldatlan, hogy miért nem működik a kijelentkezés. Annyit sikerült kiderítenem, hogy a gombra kattintáskor nem hívja meg a NavMenu komponensben az eseménykezelőt. Amíg ennek az okát kerestem, azt vettem észre, hogy van néhány sor kód, amit a komponensen belül jobb lenne áthelyezni abba az eseménykezelőbe, ami a komponens inicializálása után fut le. Miután ezt megcsináltam, azt vettem észre, hogy ezek a kódok sem futnak le. Tehát a komponens inicializálása elakad valahol. Újabb nyomozás és dokumentáció olvasás után kiderült, hogy a komponens RenderMode paramétere nem volt jól beállítva. Miután ezt javítottam, hirtelen minden a helyére került. A felhasználó neve megjelent a menüben és a kijelentkezés is működött.
Ezután még találtam pár érdekes hibát. Például nem tudtam saját tornagyakorlatot rögzíteni az adatbázisban. Mint kiderült, a frontend felől küldött adat formátuma nem egyezett a backendben használt adatmodellel. Vagy például bizonyos frontend felületek csak félig készültek el. De ezekkel már nem foglalkoztam, mert úgy éreztem, hogy a kísérletből ennyi éppen elég volt.
Végkövetkeztetés
A kódoló ügynökök elég jó munkát tudnak végezni, ha egyszerű, jól körülírható feladatokról van szó. De attól még nagyon messze vannak, hogy akár csak egy közepesen bonyolult programot önállóan összerakjanak. A feladatok megoldásához fontos a részletes, jól definiált kontextus. A több részből álló, bonyolultabb programoknál viszont érdemes a feladatot kisebb egységekre bontani, azokat egyesével, több iterációban elkészíttetni, majd az így elkészült modulokat a kontextushoz hozzáadva továbblépni a következő részre.
Fontosnak tartom azt is, hogy a folyamatba mindig be kell építeni az emberi ellenőrzést. Ugyanis az ügynökök mögött működő nagy nyelvi modelleket nyilvánosan elérhető kódbázisokon tanították, ezek viszont sok esetben tartalmaznak nem optimalizált, tesztelésre szánt, vagy biztonsági rést tartalmazó kódokat. Így az ügynökök által generált kód is nagy eséllyel fog biztonsági hibát vagy nem optimális kódot tartalmazni, ami egy éles felhasználásra kiadott programnál további problémák forrása lehet.
Szóval véleményem szerint a kódoló ügynökök egy ideig még nem fogják elvenni a fejlesztők munkáját, azonban alaposan átalakítják azt. A junior fejlesztőknek nehezebb lesz belépni a szakmába, mert az általuk eddig végzett egyszerűbb, jellemzően jobban automatizálható kódolási feladatokat át tudják venni az ügynökök. A tapasztaltabb fejlesztők pedig többet fognak foglalkozni az ügynökök által generált kódok ellenőrzésével és javításával.
