Addy Osmani szerint az ügynök-alapú kódírás ma már rendkívül hatékony, és hónapról hónapra javul. Ennek következménye nem az, hogy a programozás megszűnt volna fontosnak lenni, hanem az, hogy a nehézség áttevődött: a kód megírásáról arra a lépésre, amikor egy embernek el kell döntenie, mennyire bízhat benne. Így a kódfelülvizsgálat lett a legnagyobb hatékonysági pont a szoftvermérnökségben.
Az, hogy mit jelent „jó felülvizsgálat”, nagyban függ a kontextustól: egy egyedül dolgozó fejlesztő, akinek nincs felhasználója, és egy olyan csapat, amely egy tízéves rendszert tart életben, teljesen más problémákat oldanak meg.
Mit mutat a 2026-os adathalmaz
Több, egymástól független forrás mérési adatai összhangban azt jelzik: az AI jelentősen megnöveli az outputot, de rontja a változtatások minőségét és az átláthatóságot, ezért a felülvizsgálati munka nő. Főbb, a cikkben szereplő eredmények:
-
Faros AI: 22 000 fejlesztőn, 4 000 csapaton mért adatok (2026 márciusi adat). Növekedések mellett a jelentés szerint:
- kódfordulás (code churn) +861%;
- incidents-to-PR arány +242,7%;
- fejlesztőnkénti hibaarány 9%-ról 54%-ra nőtt;
- medián felülvizsgálati idő +441,5%, a first review és átlagos review-idő is nagyjából megduplázódott;
- PR-ek, amelyeket review nélkül merge-ölnek, +31,3%.
-
CodeRabbit (2025 december): 470 open source PR vizsgálata, ebből 320 AI-koauthored és 150 emberi. AI-val készített változtatások körülbelül 1,7-szer több problémát hordoznak; logikai és helyességi gondok ≈+75%, biztonsági problémák 1,5–2× gyakoribbak, olvashatósági problémák több mint háromszorosak.
-
GitClear: 2025-ig gyűjtött produktivitási adatok. Napi AI-felhasználók körülbelül 4× nyers outputot termelnek nemfelhasználókhoz képest, de saját, egy évvel korábbi teljesítményükhöz viszonyítva a tényleges produktivitásnövekedés kb. 12% volt. Tehát nagy mennyiségű kód jön létre körülbelül egy tizeddel több leszállt értékért.
-
GitHub: Copilot review-k száma meghaladta a 60 milliót, kevesebb mint egy év alatt tízszeres növekedés; a platformon több mint minden ötödik review érint ügynököt.
Ezek az eredmények azt mutatják: a gépi sebességű kódtermelést emberi sebességű rendszerekre öntöttük, és a szűk keresztmetszet a verifikáció lett — a felülvizsgálat a hely, ahol a számla esedékes.
Mindenki más problémát old meg: a blast radius számít
Mennyi felülvizsgálat szükséges egy változtatáshoz, majdnem kizárólag a "blast radius"-tól függ: mi történik, ha elromlik? Három döntő változó határozza meg a pozíciódat:
- Blast radius: mi történik, ha hibázik — semmi, vagy felhasználók, pénz, PII veszélye?
- Mennyi ideig él a kód: egyszeri prototípus vagy éveken át karbantartott bázis?
- Hány embernek kell értenie: csak te, vagy egy csapat, amely osztozik a tulajdonlásban?
Ugyanaz a diff teljesen más követelményeket támaszt, attól függően, hol állsz ezen a spektrumban. Egyedül dolgozva megengedhetőbb a könnyített felülvizsgálat, ha valós tesztek és automatizáció védik a rendszert; éles, sokfelhasználós vállalati környezetben a felülvizsgálatnak egyszerre sok szerepet kell ellátnia, és a nagy mennyiségű ügynök-kimenet ezeket tördeli szét.
Mi lett a felülvizsgálat célja?
A felülvizsgálat eredetileg az szerző érvelésének ellenőrzésére épült: amikor egy ember ír kódot, a szándék és a döntések gyakran „ingyen” járnak vele. Az ügynökök viszont gyakran látható gondolatmenetet generálnak, de ez a gondolatmenet ritkán kerül rögzítésre vagy csatolásra a PR-hez, így a reviewernek újra kell rekonstruálnia az okokat.
Ennek a kulcsa egy eszközprobléma: ha az ügynök lementi a saját döntési naplóját (mit próbált csinálni, mit zárt ki), és azt a PR-hez fűzi, a rekonstruálási költség jelentősen csökken. Ez nem teszi feleslegessé az embert: a modellok jók hibák megtalálásában, de nem helyettesítik az emberi ítéletet arról, hogy egy változtatás helyes-e úgy általában.
Az eszközök erősek, de heterogének — érdemes többfélét futtatni
A jelenlegi AI-felülvizsgálók eredményesek, de eltérően jelzik a problémákat. Emiatt a gyakorlatban nem az a helyes stratégia, hogy egyetlen „legjobb” eszközt keresünk, hanem hogy legalább egy, de a magas kockázatnál két külön karakterű eszközt futtassunk. Néhány, a cikkben idézett pont:
- CodeRabbit: széles körben használt, a Martian benchmarkon (2026 jan–feb) jó F1 értéket mutat (kb. 49% precízió) és jó recall.
- Greptile: precíziót áldoz a recallért; egy benchmarkban ~82%-os hibadetektálást mutatott a CodeRabbit 44%-ával szemben, többlet false positive-tel.
- Anthropic’s Code Review: alacsony tévedési arányt jelent, és belső metrikájuk szerint PR-ek érdemi felülvizsgálatának arányát 16%-ról 54%-ra növelte.
Egy független mérés 146 valós PR-en és 679 talált hibán belül azt mutatta: a 617 különböző jelzett hely 93,4%-át pontosan egyetlen eszköz találta meg, csak ≈6%-át kettő, és egyetlen sort sem jelöltek mind a négy eszköz egyszerre. Ez azt erősíti, hogy heterogenitásra kell törekedni: különböző eszközök különböző osztályú hibákat találnak.
Kéne-e hagyni, hogy az AI többet felülvizsgáljon?
A gépek ma már gyakorlatilag többet „olvasnak” a kódból, mint mi. Az etikus és biztonságos választás az, hogy ezt tudatosan szabályozzuk. A cikk szerzője úgy fogalmaz, hogy a humán nem tűnik el, hanem feljebb lép a szinten: nem minden sort olvas át, hanem a rendszertervezési döntésekért, accountability-ért, a nagy blast radius kapukért és az emberi hiányosságok fedezéséért marad felelős.
A loop engineering (az ügynökök rendszerszintű vezérlése és bírása) automatikusan kialakít egy „bíró” szerepet, de ha zárt modellek egymásra hagyatkozva döntik el, hogy „rendben van”, akkor az együtt korrelált vakfoltok miatt hamis biztonságot hozhatunk létre. Tehát a modellokkal végzett ellenőrzés hasznos, de emberi döntés nélkül veszélyes.
Konkrét gyakorlati javaslatok
- Ne minden változtatást egyformán részletesen nézz át. Osszd be az emberi figyelmet ott, ahol a hiba költsége magas.
- Kockázati rétegzés (tier by risk) – ne a szerző határozza meg a review mélységét, hanem a blast radius.
- Gyorsan függeszd fel a potenciálisan nehéz PR-eket: egy „circuit breaker” előre jelezheti a magas karbantartási igényű PR-eket olcsó jelek alapján (fájlok típusa, patch mérete stb.).
- Emeld meg a felülvizsgálás minimális bizonyíték-szükségletét: kérjél intent leírást, elfogadható méretű diffet, érvényes tesztkimenetet és a tesztek futtatásának bizonyítékát.
- Tartsd kicsiben a PR-eket: a Faros adatai szerint az ügynök-PR-ek átlagosan 51%-kal nagyobbak, és a reviewer bevonódása erősen korrelál a merge-el.
- Teszteket nézd alaposabban, mint a kódot: az ügynök gyakori hibája, hogy a viselkedést „megjavítja” úgy, hogy a tesztet átírja az új, hibás viselkedéshez. A mutációs tesztelés itt különösen hasznos.
- Treat CI as a strict wall: figyeld a CI-gyengítéseket (eltávolított tesztek, skip-lint, csökkentett coverage threshold), és óvakodj a prompt injectiontől, amikor user input agent-híváson megy át.
- Egy ember legyen a merge tulajdonosa: az AI „looks good” egy érzékelő, nem ítélet.
Ha egyedül dolgozol és nincs felhasználód, a tiering, a teszt-diszciplináris szabályok és a CI nagyjából elég. Nagy szervezeteknél ezek az alap, és a triage/intake határ megadja, hogy a review folyamata skálázható maradjon.
Következtetés: a megértés maradt drága
A kódírás olcsóbb lett; a megértés nem változott. Azok a csapatok járnak jól, amelyek nem a legtöbb kód előállítására, hanem egy megbízható felülvizsgálati rendszer kiépítésére koncentrálnak. Az ügynökök átalakították a munkát: a bizonyítás (proving) lett a munka középpontja. Ahogy Simon Willison megfogalmazza, „a feladatod olyan kódot szállítani, amit bizonyítottan működik” — az ügynökök ezt nem változtatták meg, csak előtérbe helyezték.
Az új normában a legfontosabb készség nem az, hogy mennyi kódot gyártasz, hanem hogy mennyire tudsz megbízható, ember által értelmezhető igazolást adni arra, hogy a kód helyes és megfelel-e a célnak.
