Az AI kódreview ma a szűk keresztmetszet: egy ügynök által írt PR-ek hulláma

Az AI-generált pull requestek olcsók előállítani, drágák review-zni, és ez az egyensúlytalanság a softwarefejlesztés szűk keresztmetszetét a kódírásról a kódolvasásra tolta el. Az ügynök által írt PR-ek nagyobbak, hosszabb ideig várnak egy reviewerre, és ritkábban mergelnek, mint a kézzel írt PR-ek. Több ügynök csak hosszabbítja a sort.

Ez a cikk megnézi, mit mutatnak az adatok, miért lett a review a szűk keresztmetszet, és mit érdemes változtatni: PR méretkeretek, stacked pull requestek, AI kódreview első körként, ügynökök, amelyek a saját review-kommentjeikre válaszolnak, és egyértelmű szabály a felelősségre. A végén egy csapat által átvehető szabályzatminta.

Mit mondanak az adatok az AI-generált pull requestekről?

Két nagy adathalmaz egyezik: az AI-támogatott pull requestek nagyobbak, és több közülük review nélkül marad, vagy soha nem mergel. Az egyéni teljesítmény nő, a csapatszintű átadás nem követi.

A LinearB 8,1 millió pull request elemzése (2026. május) 4 800 csapaton, 42 országban a legrészletesebb. A Faros AI AI Productivity Paradox jelentése (2025. július), amely több mint 10 000 fejlesztővel, 1 255 csapaton alapult, egy évvel korábban ugyanazt a képet találta.

Ezeket jeleknek olvasd, nem törvényeknek. Mindkettő a saját ügyfeleiről szóló gyártói tanulmány, és az „AI-assisted” besorolást minden kutatás másképpen kezeli. Egy részlet azonban kiemelkedik a LinearB számai közül: ha egy reviewer tényleg nekilát egy AI-generált PR-hez, a review nem lassabb. Az robban fel, ami előtte van: a várakozás, amíg valaki fel nem veszi. A reviewerek kerülik a nagy, ismeretlen diffeket.

Miért lett a kódreview a szűk keresztmetszet

A review azért szűk keresztmetszet, mert egy diff előállítása most percekbe telik, annak megértése viszont egy embertől továbbra is ugyanannyi figyelmet kíván, mint mindig. Minden sor, amelyet egy ügynök ír, egy sor, amelyet valakinek el kell olvasnia, és az olvasási idő a mérettel és az ismeretlenséggel nő.

A Google engineering practices egy változás célméretét ott húzza meg, ahol „100 sor általában ésszerű méret egy CL-hez, az 1000 sor pedig általában túl nagy”, és egy mondatban megadja az okot: „Könnyebb egy reviewernek többször öt percet találni kis CL-k átnézésére, mint egy 30 perces blokkot fenntartani egy nagy CL átnézésére.” Egy ügynök, amely tíz perc alatt egy 600 soros PR-t állít elő, most egy 30 perces blokkot foglalt el valaki más napjából.

PR méretkeretek és stacked pull requestek

A leghatékonyabb javítás az, ha az ügynökök kisebb pull requesteket gyártanak, és egy túl nagy változást stackelnek. A méret az az egyetlen változó, amelyet teljesen te tartasz kézben, mert az ügynök pontosan olyan finoman bontja a munkát, amilyen finoman megkéred.

A méretkeret egy sor az ügynök szabályaiban plusz egy CI ellenőrzés: például minden olyan PR, amely néhány száz módosított sor feletti, elbukik vagy címkét kap, a lockfile-okat és a generált kódot kivéve. A Google útmutatója felsorolja a működő felbontási stratégiákat: egymásra épülő függő változások, felbontás olyan fájlok szerint, amelyekhez különböző reviewerek kellenek, vízszintes bontás réteg szerint vagy függőleges feature szerint, és a refaktorok „külön CL-ben, a feature-változásoktól vagy hibajavításoktól elválasztva”.

A stacked pull requestek ezt gyakorlattá teszik. A GitHub 2026. június 30-án public preview-ba tette a stacked PR-eket: „egy rendezett sor pull requestekből, amelyek a változásod külön fókuszált rétegeit reprezentálják”, ahol minden PR az alatta lévőre céloz. A reviewerek egy stack térképet látnak, és rétegről rétegre egy diffet review-znak. A legfelső kész PR mergelésekor az és minden alatta lévő, még nem mergelt réteg egyetlen műveletben kerül be; egy alsó réteg mergelésekor a felsők nyitva maradnak, és automatikusan rebase-elődnek. A CLI bővítményként érkezik, és a GitHub egy gh-stack skillt említ a kódoló ügynökökhöz:

gh extension install github/gh-stack

Az ügynökök számára a stackelés megváltoztatja az utasítást: „implementáld a feature-t” helyett „implementáld a feature-t stackként: előbb a séma, aztán a service, aztán a UI, mindegyik egy PR, mindegyik önmagában zöld”. Így könnyebben review-zható és könnyebben visszavonható.

AI review első körként, emberek a szándékra

Az első kört bízd egy AI reviewerre és a determinisztikus ellenőrzésekre, hogy az emberi reviewer csak a szándékra, a designra és a kockázatra fordítsa a figyelmét. Ne az AI kör váltsa fel az emberit.

A toolok mindkét használatot támogatják, tehát a döntés a tiéd. A GitHub Copilot code review dokumentációja szerint a review-k automatikusan, ruleseteken keresztül indíthatók, alapértelmezés szerint a Copilot jóváhagyási értékelése nem számít bele a kötelező jóváhagyásokba, és ha a „Copilot approvals” be van kapcsolva, „beadhat egy jóváhagyó review-t, amely teljesíti a repository kötelező jóváhagyási szabályát”. Ugyanez az oldal figyelmeztet: „A Copilot nem garantálja, hogy minden problémát vagy hibát megtalál egy pull requestben.” Az én javaslatom: kapcsold ki az AI jóváhagyásokat mindennél, ami produkcióba megy.

Az első kör akkor működik a legjobban, ha rétegezett: először determinisztikus szenzorok (tesztek, típusok, linterek, mutációs tesztelés a diffen, ahogy a harness engineering leírja), aztán egy AI review a szemantikai problémákra, végül az ember. Amikor egy ember megnyitja a PR-t, a megmaradt kérdések ezek legyenek: „ez a megfelelő változás?” és „mit törhet el ez?”, nem pedig „lefuttattad a teszteket?”.

A hurok lezárása: ügynökök, amelyek a review-kommentekre válaszolnak

Ha egy ember mégis kommentel, az ügynöknek, amely megírta a PR-t, kell elvégeznie a folytatást: minden kommentet javítani, a javítást bizonyítani, és válaszolni a szálon. A reviewer második köre így percekbe telik.

A review-kör skilljem így működik. A GitHub API-n keresztül összegyűjti a PR összes review-kommentjét, javítja őket, és minden szálat megjelöl: javítva, részben, nyitott vagy nem releváns. Újrafuttatja a teszteket és a statikus elemzést, és ismétli. Három eredménytelen kör után leáll, és átad nekem, mert egy negyedik kísérlet ugyanarra a kommentre ritkán lesz jobb. A végén minden szálra válaszol, megnevezve azt a commitot, amely megoldotta, hogy a reviewer minden választ egy konkrét diffhez tudjon ellenőrizni. A skill részletesebb leírása a kódoló ügynököm skilleinek munkafolyamatában van, a leállítási logika pedig általános minta, amelyet az ügynökhurok magyarázata tárgyal.

Ha az AI első kör sok findingot termel, triázsold őket, mielőtt az ügynök javítani kezd. Egy tipizált osztályozó, amely minden findingot „most javítsd”, „backlog” vagy „ember kell” címkével jelöl, olcsóbb és következetesebb, mint egy általános modelltől megkérdezni, „mi számít”; ezt a megközelítést a tipizált döntések routingra és triázsra cikk ismerteti.

Mérleg: mibe kerülnek ezek a szabályok

Itt minden szabály valami mással vásárol review gyorsaságot, és néhány csapatnak nem is mindet kell bevezetnie. Tudd meg az árat, mielőtt megírod a szabályzatot.

• A méretkeretek többletköltséget jelentenek. Több PR több CI-futtatást és több kontextusváltást jelent. Egy egyszeri migrációhoz, amelyet egy codemod generált, egy nagy PR tiszta leírással könnyebben review-zható, mint húsz kicsi.
• A stackekhez eszközfegyelem kell. Az a stack, amelyet senki nem rebase-el, gyorsan elromlik. A GitHub stacked pull request funkciója 2026. szeptemberében public preview-ban van, szóval ellenőrizd, mit támogat a merge queue, mielőtt erre építenél.
• Az AI review zajt termel. Az a review bot, amely sok kevéssé értékes kommentet ír le, megtanítja az embereket figyelmen kívül hagyni. Hangold az utasításait addig, amíg a legtöbb komment változáshoz vezet, vagy kapcsold ki.
• Az emberi review nem skálázódik lineárisan. Ha az ügynökök megháromszorozzák a kimenetet, a reviewerek nem. Egy ponton a helyes válasz kevesebb PR: generálj kevesebbet, és az ügynök időt fordíts tesztekre és takarításra új feature-ök helyett.

Csapatszabályzat az ügynök által írt pull requestekhez

Az írott szabályzat megszünteti a találgatást mindkét oldalon: a reviewereknél és az ügynököknél. Tedd bele a contribution guide-ba és az ügynökök szabályfájljaiba, hogy ugyanazok a szabályok érvényesek, bárki vagy bármi nyitja is a PR-t.

1. Minden PR-nek van egy megnevezett emberi tulajdonosa. Aki az ügynökötől kérte a változást, felelős érte, ő review-zza először, és a merge után is ő vállal érte.
2. Méretkeret: a megállapított sorszám feletti PR-eket fel kell bontani vagy stackelni; a refaktorok saját PR-be kerülnek.
3. Bizonyíték a leírásban: mi futott, pontos eredményekkel, és mi nem futott, megmondva miért.
4. Először a determinisztikus gate: a tesztek, a típusok, a linterek és a diffen futtatott mutációs tesztelés zöldek kell legyen, mielőtt review-t kérsz.
5. Az AI review tanácsadó. Kommentel, nem ad kötelező jóváhagyást.
6. Az ügynök megválaszolja a kommentjeit, szálanként egy committal, és három eredménytelen kör után leáll.
7. Ember hagy jóvá mindent, ami nyilvános vagy visszafordíthatatlan: merge produkciós ágakba, migrációk, deployok.

Az a PR sablon, amelyet az ügynökeim kitöltenek, öt fix szakaszból áll:

## Ticket
Link to the issue. No ticket, no PR.

## Description
What changed and why, in two or three sentences.

## Testing
Commands run and exact results. Anything not run, and why.

## How to test
Steps a reviewer can follow to see the change working.

## Deployment notes
Migrations, config, feature flags, rollback. "None" if none.

Ha azon tanakodsz, hogyan férjenek be a kódoló ügynökök a csapatod review folyamatába, nézd meg az AI engineering oldalt.

Források

1. LinearB: What 8 million pull requests reveal about engineering productivity (2026. május)
2. Faros AI: The AI Productivity Paradox report (2025. július)
3. Google Engineering Practices: Small CLs
4. GitHub Changelog: Stacked pull requests are now in public preview (2026. július)
5. GitHub Docs: Copilot code review