AI-ondersteunde code reviews: wat het nieuwste onderzoek zegt over GPT in pull requests

Bij ZEN houden we onderzoek in de gaten dat raakt aan hoe engineeringteams software bouwen, opleveren en onderhouden. Onlangs stuitten we op een nieuwe studie — “The Impact of Large Language Models (LLMs) on Code Review Process” (Antonio Collantea, Samuel Abedu, SayedHassan Khatoonabadi, Ahmad Abdellatif, Ebube Alor, Emad Shihaba) — waarin meer dan 25.000 GitHub pull requests zijn geanalyseerd om te zien hoe GPT-achtige modellen de snelheid en samenwerking bij code reviews beïnvloeden.

De bevindingen zijn veelbelovend én relevant voor moderne teams die cloud-native, agile of verspreid werken.

Hieronder onze samenvatting van het onderzoek — en wat teams er volgens ons uit kunnen halen.

De onderzoekers stelden een dataset samen van 25.473 pull requests uit 9.254 GitHub-repositories, waarvan er ongeveer 1.600 met hulp van GPT tot stand kwamen.

De opvallendste uitkomsten:

• Mediane doorlooptijd tot merge mét GPT-hulp: ~9 uur

• Mediane doorlooptijd zonder: ~23 uur
  Dat is grofweg 61% sneller.

De “in review”-fase verbeterde flink:

• met GPT-hulp: 1 uur

• zonder: 3 uur
  Een verbetering van ~66,7%.

Hier zit de grootste winst:

• mediane wachttijd met GPT-hulp: ~3 uur

• mediane wachttijd zonder: ~24 uur
  Een verbetering van 87,5%.

Het onderzoek deelde het GPT-gebruik in PR's als volgt in:

• 60% – verbeteringen (refactoren, hernoemen, foutafhandeling)

• 26% – bugfixes

• 12% – documentatie

Dat patroon laat zien hoe teams LLM's vanzelf inzetten: om kleine maar belangrijke verbeteringen te versnellen die reviewrondes vaak verstoppen.

Wat ons betreft illustreren deze uitkomsten iets wat we in de praktijk ook zien:

LLM's vervangen je reviewers niet — ze persen de wachttijd rondom reviews samen.

De grootste flessenhals in een PR-workflow is meestal niet kwaliteit of complexiteit, maar stilstand: wachten op feedback, wachten op wijzigingen, wachten tot iemand de volgende stap oppakt.

Door meteen suggesties en verbeteringen aan te dragen, verkort GPT die stilstand en blijft de boel in beweging. Voor moderne teams — zeker die met trunk-based development of een hoog leveringstempo — is dat betekenisvol.

Het onderzoek laat de grootste winst zien bij verbeteringen en bugfixes — niet bij grote features of architectuurbeslissingen.
Teams hebben er baat bij om GPT te gebruiken voor:

• code opschonen

• triviale reviewopmerkingen wegnemen

• betere naamgeving en documentatie

• een eerste opzet voor een fix of refactor

Zo houden je menselijke reviewers hun aandacht vrij voor ontwerp, architectuur en correctheid.

De auteurs merkten op dat PR's met GPT-hulp herkenbaar waren aan commitberichten, PR-beschrijvingen en het patroon van de wijzigingen.
Teams kunnen dat formaliseren door:

• een vinkje “LLM gebruikt?” toe te voegen

• richtlijnen op te stellen voor acceptabel gebruik

• vast te leggen wat je van reviewers verwacht

Dat neemt onduidelijkheid weg en bouwt vertrouwen op.

Het onderzoek gebruikte heldere maatstaven op PR-niveau (doorlooptijd tot merge, tijd tot eerste review, wachttijd). Dat kun je intern nadoen om te zien of LLM-hulp je workflow echt versnelt — of vooral ruis toevoegt.

Het onderzoek noemt de klassieke valkuilen van LLM-wijzigingen:

• context die verloren gaat

• code die verkeerd geïnterpreteerd wordt

• oppervlakkige fixes

• verkeerde refactors doordat het model tegen tokenlimieten aanloopt

Behandel LLM-output als het voorstel van een sterke maar onervaren engineer: bruikbaar, maar altijd kritisch nakijken.

De cijfers verbeterden dan wel spectaculair, maar de kwaliteit is in dit onderzoek niet beoordeeld.
Onze conclusie: LLM's versnellen het mechanische deel van een review, niet het oordeel.

Ontwerpkeuzes, securityvraagstukken, domeinlogica en architectonische afwegingen vragen nog altijd om ervaren engineers.

Het onderzoek is degelijk, en gelukkig ook eerlijk over zijn beperkingen:

• het gebruikt opensourceprojecten op GitHub — in bedrijfsomgevingen kan het anders lopen

• PR's met GPT-hulp zijn opgespoord met heuristieken, niet met harde logs

• die PR's neigen mogelijk naar eenvoudiger klussen

• alleen de doorlooptijd is onderzocht, niet de kwaliteit van de wijzigingen

Die kanttekeningen tellen mee als je de uitkomsten verantwoord wilt lezen.

Dit is een van de eerste grootschalige, kwantitatieve analyses van hoe LLM's je reviewproces beïnvloeden — en de uitkomsten stemmen hoopvol.

Onze conclusie als ZEN-team is simpel:

LLM's versnellen vooral de trage, stilstaande fases in je PR-workflow — niet door reviewers te vervangen, maar door de wrijving eromheen weg te nemen.

Wil je als team de developerervaring, je doorstroming en je leversnelheid verbeteren, dan is AI-ondersteund reviewen een veelbelovende richting — zolang je er stevig menselijk toezicht en verstandige afspraken naast zet.