AI-val gyorsabban termelünk kódot. De ki fogja átnézni?

Egy platform engineer tavaly még napi két-három pull requestet nézett át egy közepes magyar csapatnál. Idén tízet. A változások egy része ezer sor körüli, néhol ott a ticketen kívüli, „amúgy is itt jártam” módosítás. A CI néha alig bírja, a review-sor folyamatosan tele, és a kódbázis lassan olyan, mintha többen írták volna, mint ahányan valójában dolgoznak rajta. A csapat nem lett kétszer akkora. A coding agent viszont megérkezett.

Könnyű ezt egyéni panaszként elintézni. Pedig nem az. A GitHub 2025-ös Octoverse-jelentése szerint a platformon havonta átlagosan 43,2 millió pull request olvad be - ami 23%-os éves növekedés -, és 2025-ben közel egymilliárd commit született. Csak a Copilot kódoló ügynöke öt hónap alatt több mint egymillió PR-t nyitott. A „PR-gyár” érzete tehát nem hangulat, hanem egy globális volumenrobbanás helyi lecsapódása. A kérdés, amit ez a cikk feltesz, ennyi: ha a kódírás öt-tízszer gyorsabb lett, ki fogja öt-tízszer gyorsabban átnézni, megérteni és vállalni, amit legenerálunk?

Érdemes tisztázni, mi a coding agent, mert a köznyelvben összemosódik a régi autocomplete-tel. A mai agent már nem csak sort egészít ki: tervet készít, több fájlt módosít, tesztet ír, pull requestet nyit, alügynököket indít, és előre beállított ellenőrzéseket - hookokat - futtat. Ez minőségileg más, mint két éve volt.

Ettől viszont nem lett autonóm szenior mérnök. Sokkal pontosabb úgy gondolni rá, mint egy gyors, olcsó és fáradhatatlan junior-rendszerre: rengeteget termel, gyakran használhatót, de a kontextust nem érti úgy, mint aki a rendszert évek óta építi, és a felelősséget sem tudja viselni. Akkor hasznos, ha van fölötte mérnöki kontroll - specifikáció, határok, review. Magára hagyva pont azt csinálja, amit egy felügyelet nélküli junior: sokat, gyorsan, és néha magabiztosan rossz irányba. A magabiztosság itt a kockázat: az agent ritkán jelzi, ha bizonytalan, és olyan kódot is meggyőzően ír, ami szintaktikailag hibátlan, de a rendszer logikájába nem illik. Ezt jellemzően csak az veszi észre, aki a rendszert valóban érti.

Az AI-használat kérdése eldőlt. A DORA 2025-ös, közel ötezer szakembert megkérdező kutatása szerint a fejlesztők 90%-a használ AI-t, ami egy év alatt tizennégy százalékpontos ugrás. A JetBrains huszonnégyezres felmérésében 85% rendszeresen használja, és 62% legalább egy kódoló asszisztensre vagy ügynökre támaszkodik. A Stack Overflow szerint 84% használ vagy tervez használni AI-eszközt, az új GitHub-fejlesztőknek pedig 80%-a már az első héten elkezdi. Itt nincs több vita: a kérdés már nem az, hogy használjuk-e, hanem az, milyen szervezeti kontroll mellett.

Mert a használat mellett egy másik szám is makacsul tartja magát - a bizalomé, ami csökken. A Stack Overflow-nál a fejlesztők 46%-a kifejezetten nem bízik az AI-kimenet pontosságában; egy éve ez még 31% volt, és mindössze 3% bízik benne erősen. A Sonar 2026-os, több mint ezer fős kutatásában a fejlesztők 96%-a nem bízik teljesen abban, hogy az AI-kód funkcionálisan helyes. Ez a kettősség - magas használat, alacsony bizalom - a 2025-ös év legbeszédesebb mintázata, és nem technofóbia: egy determinista gondolkodású szakma józan reakciója egy nemdeterminista eszközre. A fejlesztők ráadásul nagyrészt hasznosnak is érzik az AI-t; a Sonar szerint 82% egyetért, hogy gyorsítja a kódolást, a JetBrains szerint 90% legalább heti egy órát spórol vele. Ezek valós érzetek - és pontosan itt kezdődik a félreértés.

A baj abból fakad, hogy a kódírás sebességét összekeverjük a szoftverszállítás sebességével. Pedig négy különböző dolog ez, amit a hétköznapi beszéd egybemos: hogy milyen gyorsan keletkezik a kód, hogy mennyire érzi gyorsabbnak magát a fejlesztő, hogy mennyi idő alatt jut el egy igény a felhasználóig, és hogy mennyire tartható karban, amit építettünk. Az AI az első kettőt szinte mindig javítja. A harmadikat és a negyediket nem garantálja. A felbontás lényege egy költség-aszimmetria: a generálás olcsó lett, a megértés nem. Egy ezer soros, géppel írt PR átolvasása, fejben tartása és felelős jóváhagyása ugyanannyi - vagy több - kognitív munkát kíván, mint korábban; csak ma nem feltétlenül az végzi, aki a kódot „írta”, hanem a reviewer.

Ezt a szakadékot két kutatás mutatja meg a legélesebben, egymással szemben. Egy korai, izolált feladatra épülő GitHub-kísérletben a Copilotot használók 55,8%-kal gyorsabban végeztek - ez a „gyorsít” tábor emblematikus száma. A METR 2025-ös randomizált kontrollált kísérletében viszont tizenhat tapasztalt nyílt forrású fejlesztő dolgozott a saját, érett kódbázisain, és AI-val 19%-kal lassabban végeztek - miközben előzetesen 24% gyorsulást vártak, és utólag is 20%-ot éreztek. A két eredmény nem mond ellent egymásnak; különböző dolgot mér. A tanulság nem az, hogy „az AI gyorsít”, és nem is az, hogy „az AI lassít”, hanem az, hogy a hatás kontextusfüggő: izolált, jól körülhatárolt feladaton jellemzően gyorsít, nagy, jól ismert kódbázison, szigorú minőségi elvárás mellett viszont a takarítás költsége felfalhatja a generálás nyereségét. A METR kis mintás volt és korai modelleket használt, a szerzők maguk is pillanatfelvételnek nevezik - de épp a percepció és a valóság közötti rés a fontos: még a saját gyorsulásunkat is rosszul becsüljük.

Itthon ez a feszültség a fejlesztői fórumokon csapódik le a legélesebben. Fontos azonban tisztázni: ezek a threadek nem reprezentatív felmérések. Reprezentatív magyar adat az agentic coding hazai elterjedtségéről egyelőre alig van, ezért a fórumhangokat kvalitatív terepnaplóként kezelem, nem statisztikai bizonyítékként.

Jelzésként viszont pontosak, mert ugyanazok a figurák és ugyanaz a törésvonal tér vissza bennük. Ott a platform engineer, akire ráomlik a PR-volumen; a szenior reviewer, aki napokat tölt mások által generált, ránézésre rendben lévő, de gyengén megértett kód olvasásával; a termékmenedzser, aki látja, hogy az üzlet a mennyiséget díjazza; az infra engineer, akinek az AI valóban segít a scriptelésben, miközben mások elhamarkodott infra-módosításait takarítja; az AI-native fejlesztő, aki jól használja, mert tud specifikálni és ellenőrizni; és a vibe coder, aki bedob egy ticketet, és felpushol egy nagy PR-t. A konfliktus nem fejlesztők kontra menedzsment. A konfliktus a sebesség és a minőség, az üzleti nyomás és a mérnöki fegyelem, a látszólagos és a valódi haladás között feszül.

Van ennek egy kényelmetlen, szinte szociológiai rétege is. A precíz fejlesztő, aki valóban érti és validálja a munkát, lassabbnak látszik - mert tényleg lassabb annál, aki csak felpushol. A gyengébb fejlesztő AI-val ránézésre jobb outputot produkál. Nehezebb lett első ránézésre megmondani, ki ért hozzá valójában. Ez nemcsak minőségi, hanem bizalmi és státuszkérdés is egy csapaton belül.

Itt érdemes egy különbséget élesen meghúzni, mert a magyar vita nagy része feloldható vele. A fórumokon a legtöbben nem az AI-t támadják, hanem azt, amikor az AI-val megspórolják a gondolkodást.

Az egyik véglet a vibe coding: egy ticket, egy Figma-kép vagy egy laza ötlet bemásolása a modellbe, nagy scope, kevés megértés, nagy PR, ticketen kívüli módosítások, „zöld a teszt, mehet” hozzáállás és elkent felelősség. A másik az AI-assisted engineering: előzetes specifikáció és engineering design, kis scope, korlátozott agent-jogosultság, karbantartott kontextusfájlok (CLAUDE.md, AGENTS.md, ai-docs), lintet, tesztet, típus- és security-ellenőrzést futtató hookok, AI-review plusz emberi review, és egyértelmű emberi felelősség. Ugyanaz a modell, ugyanaz az eszköz - két gyökeresen különböző mérnöki kultúra.

Megnyugtató adat egyébként, hogy a Stack Overflow szerint a fejlesztők 72%-a a saját professzionális munkájában nem vibe-codol: a jelenség hangosabb, mint amilyen elterjedt.

Ha az adatokat egyetlen mondatba kellene sűríteni, az így szólna: a senioritás nem szűnik meg, hanem áthelyeződik. Egy 2026-os longitudinális vizsgálat szerint a fejlesztők 82%-a kevesebb időt tölt kódírással, és a munka súlypontja a létrehozás felől a validáció felé tolódik - a szerzők ezt supervisory engineering worknek, felügyeleti mérnöki munkának nevezik. A minta kicsi és önbevalláson alapul, de az irány egybevág a többi forrással.

A jó szenior egyre kevésbé az, aki kézzel írja a legtöbb sort. Inkább az, aki specifikál, határokat húz, architektúrát véd, review-zik, validál, üzleti logikát fordít, security- és observability-szempontokat kér számon, és - talán a legfontosabb - eldönti, mit nem szabad az AI-ra bízni. A kézi kódolás presztízse csökkenhet, de a mérnöki ítélőképesség értéke nő. A jó munkamenet nem bonyolult: specifikáció, releváns kontextus, kis lépés, AI-implementáció, AI-review, emberi review, teszt, merge. Ebben a modellben az agent a gyors, de felügyelt junior - a végső döntés és a felelősség emberé marad. És épp ez a réteg az, ami nem automatizálódik el egyhamar: a modell és a rendszer közötti fordítás, az üzleti szándék lekódolása, és annak eldöntése, mit jelent egyáltalán, hogy valami „kész”.

Ezt óvatos hipotézisként mondom, nem ítéletként, mert reprezentatív magyar adat itt is hiányzik. Több strukturális ok miatt üthet ez nálunk élesebben.

Sok magyar csapatban eleve vékony a platform-, QA-, security- és architektúra-réteg, a szeniorok pedig már az AI előtt is túlterheltek voltak. Ha erre ráengedünk egy agentic coding munkamenetet megfelelő korlátok nélkül, az nem felszabadítja a szeniorokat, hanem review-pokollá teszi a napjaikat. A kisebb cégeknél gyakran hiányzik a formális engineering governance; a multiknál és a szolgáltatóközpontoknál viszont fragmentált a tulajdonlás, sok az approval-réteg és az offshore-nearshore interfész. A munkaerőpiaci bizonytalanságban ráadásul nehezebb visszadobni egy rossz PR-t vagy nemet mondani egy irreális határidőre. És itt válik kínosan láthatóvá valami, ami eddig is így volt: sok helyen a review volt a rejtett minőségbiztosítás - az a pont, ahol egy tapasztalt ember csendben kijavította, amit a folyamat elrontott. A kockázat ráadásul szegmensfüggő: egy korai fázisú startupnál a gyors iteráció valódi előny, és a slop ára alacsony, mert a kód úgyis gyorsan cserélődik; egy banki vagy adatnehéz rendszerben viszont ugyanaz a slop évekig élhet, és sokszor csak élesben, incidensként derül ki.

Kontextusjelzőként ide kívánkozik a Hays magyar munkaerőpiaci jelentése, amely a szenior szakemberek túlterhelését, kiégését és az ebből fakadó fluktuációt külön kockázatként nevezi meg, stagnáló IT-bérek mellett. Ez nem reprezentatív bizonyíték az agentic coding magyar hatására - de jól mutatja, hogy épp az a réteg kerül nyomás alá, amelyből amúgy is kevés van, és amelyet a legdrágább pótolni.

A megoldás nem AI-politikai, hanem engineering-politikai. És a kiindulópont a mérés: ha az AI-használatot a leírt kódsorokban, a PR-ok számában vagy a lezárt ticketekben mérjük, akkor olyan mutatókat figyelünk, amelyeket az AI-val triviálisan fel lehet fújni anélkül, hogy egyetlen valódi probléma is megoldódna.

Mit mérjen egy csapat a LOC és a PR-szám helyett?

Cycle time - az ötlettől a production deployig eltelt idő.

Change failure rate - a deployok hány százaléka okoz incidenst.

Escaped defects - a productionben kibukó hibák száma.

Review lead time és a review-terhelés reviewerenként.

A PR-méret eloszlása és a „túl nagy” PR-ok aránya.

Rework / churn rate - a frissen írt kód mekkora hányadát írják át rövid időn belül.

Incident count és MTTR (átlagos helyreállási idő).

Tesztlefedettség és annak változása az AI-bevezetés óta.

A security findingok száma és súlyossága.

Az out-of-scope (ticketen kívüli) változtatások aránya.

A logika egyszerű: a produktivitásnyereség egy részét vissza kell forgatni minőségbe és tesztlefedettségbe, és aki AI-val generál kódot, ugyanúgy felelős érte, mintha kézzel írta volna.

Az agentic coding nem azt a kérdést teszi fel, hogy kell-e még fejlesztő. Azt teszi fel, hogy volt-e valaha valódi mérnöki kultúra a kód körül.

A kódgenerálás drámaian olcsóbb lett. A megértés, a validáció, az architektúra, a security és a tulajdonlás nem. Ahol van specifikáció, review, teszt, ownership és mérési fegyelem, ott az AI gyorsító, amely felszabadítja a szeniorokat az ismétlődő munka alól. Ahol ezek hiányoznak, ott az AI nem oldja meg a problémát - csak gyorsabban termeli láthatóvá. A különbség nem a modellben van, hanem a szervezetben, amelyik használja. És ezt a különbséget, ha eddig el is lehetett fedni, mostantól egyre nehezebb lesz.