A chatablaktól a pull requestig

Egy fejlesztő 2022-ben bemásol egy hibás függvényt a ChatGPT-be, elolvassa a választ, és kézzel beilleszti a kódba. Ugyanez a fejlesztő néhány évvel később már csak egy issue-t ad át egy terminálban futó agentnek; a program megkeresi a releváns fájlokat, módosítja a kódot, lefuttatja a teszteket, kijavítja a hibát, és összefoglalja a diffet. A két jelenet között nem pusztán egy gyorsabb modell áll, hanem egy másik munkamegosztás. Ez a cikk azt járja körbe, mi változott meg valójában - nem technológiai idővonalként, hanem annak kérdéseként, hogy ki mit csinál, és hol húzódik a szoftverfejlesztés legkisebb értelmes munkaegysége. A vezérfonal végig ugyanaz: nem a modellek mérete vagy a benchmark-pontszám a lényeg, hanem hogy ki fogalmazza meg a feladatot, ki írja meg a megoldást, és ki vállalja érte a felelősséget.

Előre bocsátva a végkifejletet: a változás lényege nem az, hogy az AI gyorsabban ír kódot, hanem hogy a munka legkisebb egysége fokozatosan elmozdult - a sorról és a függvényről a komplett feladat és az issue felé. Ezzel párhuzamosan az ember szerepe is áttevődik a közvetlen implementációról a specifikáció, az irányítás, az ellenőrzés és a felelősség felé. A cikk ezt az utat járja végig négy állomáson - chatbot, copilot, vibe coding, agentic coding -, majd szembesíti a lelkesedést azzal, amit a kontrollált mérések ténylegesen mutatnak.

A klasszikus chatbot nem értette a beszélgetést, hanem előre definiált szándékokat ismert fel. Az ELIZA 1966-ban mintaillesztett, a későbbi ipari rendszerek (Rasa, Dialogflow) intent-felismeréssel és entitáskinyeréssel, állapotgép mentén választottak következő lépést. A felület természetes nyelvű volt, a működés viszont zárt és szabálykötött.

A korszak nem volt meddő: a szándékfelismerés és a slot filling számtalan ügyfélszolgálati botot és hangasszisztenst működtetett. A programozáshoz azonban keveset tett hozzá: a logikát, a kódot és a hibakeresést végig az ember vitte, a gép legfeljebb sablonválaszt adott. A valódi töréspont nem a párbeszéd-felületben, hanem a mögötte álló modell általánosságában érkezett: amint egy nyelvi modell tetszőleges szöveget tudott kezelni, a chat alkalmassá vált arra is, hogy kódot magyarázzon, generáljon és átírjon.

A 2022. novemberi ChatGPT ezt törte meg: szabad szöveget kezelt, és a programozás azonnal az egyik legfőbb felhasználási terep lett. Karpathy híressé vált megjegyzése szerint „a legforróbb új programozási nyelv az angol”. A munkamenet azonban változatlan maradt: az ember feltette a kérdést, a választ pedig maga értelmezte, másolta és illesztette be. A chat nem látta a projektet, hallucinált nem létező könyvtárakat és API-kat, és hiányzott belőle a repository-kontextus. A teljes integráció - az illesztés, az adaptálás, a hibakeresés - emberi feladat volt. Ha pedig a kontextus a szűk keresztmetszet, adódik a következő lépés: vigyük az AI-t a kód mellé.

A külön chatablakból az AI átköltözött a fejlesztői környezetbe. Az inline kiegészítés, az IDE-be épített chat és a repo-kontextus a 2021-22-es GitHub Copilottal vált tömegessé: az AI ott ajánlott, ahol a fejlesztő éppen dolgozott. Az alapegység továbbra is a kódrészlet volt, és a fejlesztő minden sort maga irányított.

Érdemes látni, mi maradt változatlan. A copilot a fejlesztő döntéseit gyorsította, de nem vette át őket: az ember választotta ki, mit fogad el és mit ír felül, és ő illesztette a kódot a rendszer egészébe. A GitHub Next kutatásai (Kalliamvakou és munkatársai) a befejezési arány és az elégedettség javulását is jelezték, a Stack Overflow 2025-ös felmérése szerint pedig a Copilot a fejlesztők körében továbbra is a legelterjedtebb eszközök között maradt. A kérdés tehát nem az volt, hogy segít-e, hanem hogy meddig terjedhet a segítség.

Ennek a szakasznak van a legtisztább kontrollált bizonyítéka. Egy randomizált kísérletben (Peng és munkatársai) a Copilotot használó csoport egy izolált JavaScript-szerver feladatot mintegy 55,8%-kal gyorsabban oldott meg, magasabb befejezési aránnyal. A szám látványos, de a kontextusa döntő: greenfield, önálló, jól körülhatárolt feladatról van szó. Épp ez lesz a cikk visszatérő motívuma - egy zöld mezős feladaton mért gyorsulás nem általánosítható egy érett, nagy kódbázisra. A copilot tehát valódi segítség, de még mindig a fejlesztő a közvetlen kódoló. Ha a kiegészítés ennyire jól megy, jön a következő kérdés: mi történik, ha az egész terméket nyelven írjuk le?

2025 februárjában Andrej Karpathy egy tweetben adott nevet annak, amit sokan már csináltak: a vibe codingnak. Az eredeti jelentés radikális - „teljesen átadod magad a vibe-nak”, elfogadod és futtatod az AI outputját, a hibát visszaadod, és a kódra mint olyanra nem figyelsz. A böngészős app builderek (Lovable, Bolt, v0, Replit Agent) ezt vitték tömegpiacra: promptból teljes, működő prototípus, sokszor nem-fejlesztők kezében. A piac robbanásszerűen nőtt; a Lovable a jelentések szerint nyolc hónap alatt százmillió dolláros éves bevételi szinthez ért.

A fogalom gyorsan kultúrjelenséggé vált: a Collins szótár 2025-ös „Word of the Year” választása is jelezte, mennyire bevonult a köztudatba. A felfutás mögött valós munkamód állt: nem-fejlesztők - terméktulajdonosok, marketingesek, alapítók - először tudtak működő prototípust előállítani anélkül, hogy egyetlen sort is megírtak volna. Egy ilyen eszköz órák alatt elvisz a demo-szintig, ami korábban heteket vett volna igénybe. A kérdés csak az, hogy ez a prototípus meddig marad fenntartható, ha valódi felhasználók és valódi adatok kerülnek mögé.

Két dolgot azonban érdemes kimondani. Először: Simon Willison éles elhatárolása szerint ha átnézted, tesztelted és megértetted a kódot, az már nem vibe coding, hanem egyszerűen az LLM gépíróként való használata. A köznyelv ezt összemossa, és a „vibe coding” ma egyszerre jelöl gyors prototípust, figyelmetlen kódelfogadást, no-code réteget és tapasztalt fejlesztői gyorsítást. Másodszor: a működő demo és a fenntartható rendszer között valós szakadék húzódik. A látványos React-felszín után jön a jogosultságkezelés, az autentikáció és az adatbázis konfigurálása - itt akad el a nem-technikai felhasználó. A Guardio Labs „VibeScamming” néven mutatott be sérülékenységet generált kódban, egy ismertté vált esetben pedig egy AI-agent törölt egy éles adatbázist, miközben explicit utasítás tiltotta volna. A prototípustól tehát a megbízható, ellenőrizhető delegálás felé vezet az út.

Az agentic coding a munka legkisebb egységét mozdítja el: a kódrészletről a feladatra vagy az issue-ra. Az agent egy cél érdekében több lépést önállóan megtervez, eszközöket használ, fájlokat módosít, parancsokat futtat, és a visszacsatolásból korrigál: cél, feltérképezés, terv, módosítás, teszt, javítás, diff és pull request. A terminál-natív eszközök - Claude Code, OpenAI Codex, Devin - ezt tették mindennapi munkamóddá. A Codex heti többmilliós felhasználói kört jelent, az Anthropic pedig azt állítja, hogy belső kódjának többségét már a Claude Code írja.

Addy Osmani megfogalmazásában az „agentic engineering” épp attól válik el a vibe codingtól, hogy fegyelmet visz a folyamatba: specifikáció, tesztelés és review kíséri, nem a vak elfogadás. A különbség tehát nem a modellben van, hanem a munkamódban. A gyakorlatban ez azt jelenti, hogy az agent annyit ér, amennyit a köré épített keret enged: világos feladatleírás, gyors tesztkör és szűk jogosultságok nélkül a legügyesebb modell is kárt okozhat. Ugyanaz az eszköz lehet tehát értékes páros és felügyelet nélküli kockázat - a keret dönt.

Itt fontos a józanság. Armin Ronacher találóan „catnip for programmers”-nek nevezi az agentic codingot - vonzó és addiktív -, de hozzáteszi, hogy az eszközöket védeni kell az „LLM chaos monkey” ellen, vagyis az ellen, hogy a modell teljesen rosszul használja őket. Az agent nem egyetlen modell: működéséhez sandbox, szűk jogosultságok és emberi jóváhagyási pontok kellenek. A kérdés pedig adódik: mit tudnak ezek a rendszerek ténylegesen, a demókon túl?

A benchmarkok felső becslések, nem üzemi mércék. A SWE-bench valós GitHub-issue-kon méri, hogy egy modell képes-e végigvinni egy javítást; a 2024-es Verified változat 500 emberi validált feladatán a frontvonal mára gyakorlatilag telítődött, több modell is a 80% körüli sávban tolong. Ez azonban nem azt jelenti, hogy a feladat „megoldott”.

Ezt egy másik mérce is alátámasztja. A régi benchmarkok, mint a HumanEval, rég telítődtek, mert csak izolált függvényeket mérnek, nem valós repository-munkát. A Laude Institute Terminal-Benchje épp ezért a terminál tényleges kezelését teszteli - parancsok futtatását, hibakeresést, többlépéses munkafolyamatokat -, és itt a legjobb eredmények is szerényebbek. A tanulság, hogy a szám mindig csak annyit ér, amennyit a mögötte álló feladat: a szűk, jól definiált példa és a nyílt végű, valós környezet között nagy a távolság.

A kontaminációálló mércék józanító képet adnak. A Scale SEAL SWE-bench Pro változatán, standardizált eszközkészlettel, az eredmények mintegy 45-59%-ra esnek, privát, nem nyilvános kódbázison pedig 15-23%-ra - akár 35 százalékpontos zuhanás a Verifiedhez képest. Nem véletlen, hogy a benchmark-kontamináció (a modellek szó szerint reprodukálták a megoldó patcheket) miatt egyes szereplők 2026 elején abba is hagyták a Verified-eredmények jelentését. A tanulság kettős: egyrészt a mérési szám és a production-teljesítmény között nagy a távolság, másrészt egyre inkább nem a modell, hanem a köré épített harness (eszközkészlet, sandbox, kontextuskezelés) dönti el a tényleges eredményt. És ha gyorsan generál a rendszer, abból még nem következik, hogy jobb szoftver születik.

A legösszetörtebb intuició az, hogy az AI gyorsabbá tesz, és ez önmagában jó. A METR kontrollált kísérlete mindkét felet éles megvilágításba helyezi. Tapasztalt, nyílt forrású fejlesztők saját, ismerős kódbázisukon 2025 elején nem gyorsultak, hanem mintegy 19%-kal lassultak az AI-eszközöktől - miközben azt hitték, hogy gyorsabbak lettek. Az észlelés és a mért valóság szétvált. (Egy későbbi, késő-2025-ös eszközökkel végzett követő mérés már gyorsulást jelez az eredeti résztvevőknél, de erős szelekciós torzítással - vagyis a kép időben és mintától függően változik.)

A METR eredményét könnyű félreolvasni, ezért fontos a pontosság: nem azt mondja, hogy az AI haszontalan, hanem hogy a tapasztalt fejlesztő ismerős, érett kódbázison másképp viselkedik, mint amit a kontrollálatlan önbevallás sugall. Az észlelés és a mért teljesítmény közötti rés önmagában tanulság: ha nem mérünk, hajlamosak vagyunk túlbecsülni a saját gyorsulásunkat, és ez épp a legrosszabb alapja egy fontos beruházási vagy folyamat-döntésnek.

A minőségi oldal még egyértelműbb. A Veracode 2025-ös vizsgálata szerint a generált kód mintegy 45%-a tartalmazott OWASP Top 10 típusú sérülékenységet, és a biztonsági hibák aránya többszöröse volt az emberi alapvonalnak; az újabb és nagyobb modellek nem teljesítettek jobban. Az Apiiro elemzése a jogosultság-eszkalációs utak és a tervezési hibák jelentős növekedését jelezte, a GitClear longitudinális adatai pedig a refaktor visszaesését, a duplikáció többszöröződését és a kód-churn növekedését. A logika egyszerű: az AI csökkenti a kód előállításának költségét, de növeli az ellenőrizendő kód mennyiségét és a review-terhet. A DORA találó megfogalmazásában az AI „erősítő”: a rendezett szervezetben gyorsít, a kaotikusban a diszfunkciót nagyítja fel. Ha pedig nő a review-teher, mi lesz a fejlesztő szerepével?

A hangsúly a közvetlen implementációtól a specifikáció, az architektúra, az ellenőrzés és a felelősség felé tolódik - de juniornál és seniornál másképp. A junior oldalán a számok nyugtalanítóak: a Stanford és az ADP elemzése szerint a 22-25 éves, AI-nak erősen kitett szakmákban dolgozók foglalkoztatása 2022 óta mintegy 13%-kal relatíve csökkent, a tech-gyakornoki hirdetések pedig látványosan visszaestek.

Steve Yegge ellennarratívája szerint épp fordítva is olvasható a helyzet: az AI a kezdőt korábban juttatja érdemi munkához, mert a legrutinszerűbb feladatok egy részét leveszi a válláról. A két értelmezés nem zárja ki egymást: előfordulhat, hogy a belépés küszöbét magasabbra teszi, miközben annak, aki bejut, több eszközt ad a kezébe. Épp ezért szabad csak óvatosan okságot olvasni a munkaerőpiaci számokból.

Itt azonban kötelező az ellenbizonyíték. Humlum és Vestergaard dán adatokon nem talált különbséget az AI-t adoptáló és nem-adoptáló cégek junior-felvétele között, és súlyos makrokonfundálók torzítják a képet: a kamatkörnyezet, a pandémia utáni túlfoglalkoztatás kiigazítása és az informatikai diplomások létszámának évtizedes megduplázódása egyaránt nyom. A korreláció tehát erős, az okság vitatott. A senior oldalon a szerep inkább felértékelődik: az „agent manager” a rendszertervezést, a feladatbontást, az elfogadási kritériumokat, a tesztstratégiát és a review-t viszi. A megtartandó ellenérv viszont az, hogy ha az AI az architektúrában, a hibakeresésben és a tervezésben is javul, akkor a „magasabb szintű gondolkodás” nem feltétlenül tartós emberi menedék. A gyakorlati kérdés ezért nem az, hogy eltűnik-e a fejlesztő, hanem hogy hogyan érdemes ma használni ezeket az eszközöket.

A leghasznosabb keret nem eszközökben, hanem feladattípusban és kockázatban gondolkodik. Alacsony kockázatú, jól körülhatárolt munkánál (boilerplate, dokumentáció, egyszerű átalakítás) az agent szabadon engedésének hozadéka magas, a kára alacsony. Közepes kockázatnál (több fájlt érintő feature, migráció) már érdemes szűkebb feladatot és erős tesztet adni. Magas kockázatú területen (autentikáció, pénzügyi logika, kriptó, production deploy) az emberi jóváhagyás nem opcionális.

A keret lényege, hogy nem az eszköz, hanem a feladat kockázata dönt. Ugyanaz a terminál-agent lehet ideális egy dokumentáció-generáláshoz és veszélyes egy fizetési modul átírásához - a különbség nem a modellben, hanem abban van, mennyit bízunk rá felügyelet nélkül. Érdemes ezért a feladatokat először kockázat szerint beosztani, és csak utána választani módot és eszközt; így a gyorsítás ott jelentkezik, ahol olcsó a hiba, és marad az emberi kontroll ott, ahol drága.

A három mód a gyakorlatban egyetlen munkanapon belül is váltakozik. Egy ismeretlen hibánál a fejlesztő először tanácsadóként használja az AI-t, hogy megértse az okot; egy ismerős feature-nél páros programozóként, soronkénti irányítással dolgozik vele; egy jól körülhatárolt, mechanikus feladatnál pedig felügyelt agentként enged neki teret, amely önállóan végigviszi a munkát. A lényeg nem az, hogy végleg eldöntsük, melyik a helyes mód, hanem hogy tudatosan válasszunk a feladat ismeretében.

Három működő mód van, és nem versengenek, hanem feladatonként váltakoznak: az AI mint tanácsadó (chat), mint páros programozó (copilot) és mint felügyelt agent. A DORA „erősítő”-tapasztalata itt is irányadó: a haszon nem magától jön, hanem a szervezet érettségétől függ. Willison észrevétele szerint létezik „AI-kompatibilis kódbázis”: gyors tesztkör, világos struktúra és a kontextusfájlok (CLAUDE.md, AGENTS.md), amelyek ténylegesen segítik az agentet. Két határt azonban érdemes tiszteletben tartani: a túl széles agent-jogosultság veszélyes, a kontextusmérnökség pedig nem helyettesíti a review-t, csak előkészíti. És ha ma már ennyit bízhatunk az agentre, mi jön ezután?

A 2026-os irány a hosszabb autonóm munkamenetek, a háttérben futó és párhuzamos agentek, a több agent koordinációja, az issue-to-PR pipeline és az automatikus review felé mutat - a fejlesztő egyre inkább „agent manager”. A termékek (Cursor 3 párhuzamos build, Antigravity 2.0, Devin Desktop, Codex desktop) már ezt a munkamódot építik. Közben a frontvonalbeli modellek képessége közel ért egymáshoz, így a verseny egyre inkább a harness és a scaffold szintjére tolódik. Hogy ennek mi a helyes formája, még vitatott: az Anthropic multi-agent kutatórendszere mellett a Cognition kifejezetten amellett érvel, hogy a legtöbb esetben ne építsünk multi-agentet.

A konvergencia gyakorlati következménye, hogy a választásban egyre kevésbé a „melyik modell a legjobb” kérdés számít, és egyre inkább az, hogy melyik eszköz illeszkedik a csapat munkafolyamatához és kódbázisához. A multi-agent vitában sincs kész válasz: a több párhuzamos agent növelheti az átbocsátóképességet, de a koordináció és a review terhét is, így sok esetben az egyszerűbb, egyetlen agentre építő megoldás a robusztusabb.

Érdemes ugyanakkor reálisan látni a korlátokat is. A hosszabb, többlépéses munkamenetekben az agentek még mindig eltévednek, félreértik a szándékot, vagy magabiztosan rossz irányba indulnak; a felügyelet nélküli, végpontig autonóm fejlesztés egyelőre inkább ígéret, mint mindennapi valóság. Így a következő évek igazi tétje nem az, hogy eltűnik-e az ember a folyamatból, hanem hogy hol húzódik a kötelező emberi ellenőrzés határa - és ki felel azért, amit az agent végül beír a kódbázisba.

A megbízható, hosszú távú autonómia továbbra is korlátozott, és a felelősség az emberé marad. Így a záró gondolat nem az, hogy a programozás eltűnik, hanem hogy áthelyeződik: a chatablaktól a pull requestig az ember szerepe a közvetlen implementációtól a feladat jó meghatározása, a rendszer megértése, az ellenőrzés és a felelősségvállalás felé mozdult. A programozás nem azért változik, mert nem kell technikai tudás, hanem mert ezt a tudást most máshol kell alkalmazni.