Code review: hoe programmeurs elkaars werk controleren

Bijgewerkt: 6 augustus 2026 · 5 min leestijd

Stel je voor: een journalist schrijft een artikel, maar voordat het gepubliceerd wordt, leest een collega het eerst kritisch door. Ziet die feitelijke fouten, onduidelijke zinnen of een betere manier om iets te zeggen? Dat is precies wat code review is, maar dan voor software. Een programmeur schrijft nieuwe code, en voordat die code wordt toegevoegd aan het echte programma, bekijkt een collega-ontwikkelaar die code zorgvuldig op fouten, onduidelijkheden en verbeterpunten.

Code review is inmiddels een van de meest verspreide gewoontes in softwareontwikkeling. Vrijwel elk serieus softwarebedrijf gebruikt het, van kleine start-ups tot techreuzen als Google en Microsoft. De laatste jaren komt daar een nieuwe laag bij: kunstmatige intelligentie die meekijkt en zelf suggesties doet, nog voordat een mens er ook maar naar heeft gekeken. Dat roept de vraag op hoever die AI-assistenten al zijn, en of ze de menselijke reviewer ooit kunnen vervangen.

Wat is het precies?

Het proces begint meestal zodra een programmeur een stuk nieuwe code af heeft, bijvoorbeeld een nieuwe functie voor een app of een reparatie van een bug (een fout in het programma). In plaats van die code direct aan het hoofdprogramma toe te voegen, dient de programmeur een zogeheten pull request in: een verzoek om de wijzigingen te mogen samenvoegen (“merge”) met de bestaande codebasis.

Die pull request wordt dan zichtbaar voor collega's, vaak via platforms als GitHub of GitLab. Die tonen precies welke regels code zijn toegevoegd, verwijderd of aangepast, meestal met groene en rode markeringen. Een of meerdere collega's lezen dit door en kunnen opmerkingen plaatsen bij specifieke regels: is deze naam van een variabele wel duidelijk? Is er rekening gehouden met een uitzonderingssituatie? Ontbreekt er een test?

Voordat een mens er zelfs maar aan toekomt, draaien vaak al geautomatiseerde controles. Linters zijn programma's die code scannen op stijlfouten en veelvoorkomende vergissingen, zoals een vergeten haakje of een ongebruikte variabele. Static analysis-tools gaan een stap verder: ze proberen zonder de code daadwerkelijk uit te voeren te ontdekken of er beveiligingsproblemen of logische fouten in zitten. Pas als deze geautomatiseerde checks slagen, komt de menselijke review meestal in beeld.

De nieuwste ontwikkeling zijn AI-gestuurde reviewassistenten. Deze tools, vaak gebaseerd op grote taalmodellen (dezelfde technologie achter chatbots als ChatGPT), lezen de voorgestelde codewijziging en genereren automatisch commentaar: ze wijzen op mogelijke bugs, stellen nettere alternatieven voor, of signaleren beveiligingsrisico's. Dat commentaar verschijnt vaak al binnen enkele seconden nadat de pull request is aangemaakt, nog voordat een collega heeft kunnen reageren.

Wat wil men ermee bereiken?

Het belangrijkste doel van code review is simpel: fouten vroeg opsporen. Een bug die tijdens de review wordt gevonden, kost meestal minuten om te herstellen. Diezelfde bug die pas na livegang door gebruikers wordt ontdekt, kan uren of dagen aan reparatiewerk kosten, en soms grote schade aanrichten, denk aan datalekken of uitval van diensten.

Daarnaast draait het om kennisdeling. In grote teams weet niet iedereen alles van elk onderdeel van de software. Door elkaars code te lezen, leren ontwikkelaars hoe andere delen van het systeem werken en blijven ze op de hoogte van conventies en afspraken binnen het team. Dit voorkomt ook dat kennis vastzit bij één persoon, wat een risico is als die persoon het bedrijf verlaat.

Een derde doel is consistentie: code die er overal ongeveer hetzelfde uitziet, is makkelijker te onderhouden. Ten slotte speelt beveiliging een steeds grotere rol. Reviewers controleren of gevoelige gegevens goed worden afgeschermd en of nieuwe code geen achterdeurtjes voor aanvallers opent, iets wat door de toename van cyberaanvallen alleen maar belangrijker is geworden.

Voorbeelden uit de praktijk

Google hanteert al sinds de jaren 2000 een strikte interne cultuur rond code review, vastgelegd in publiek toegankelijke richtlijnen. Bij Google mag praktisch geen enkele regel code het hoofdsysteem in zonder goedkeuring van minstens één andere ontwikkelaar, een praktijk die het bedrijf toeschrijft aan zijn vermogen om een enorme, decennia oude codebasis beheersbaar te houden.

De Linux-kernel, de kern van het besturingssysteem dat achter miljoenen servers en Android-telefoons draait, gebruikt een uniek reviewproces via e-maillijsten. Bijdragen worden publiekelijk besproken, en oprichter Linus Torvalds en een select groep “maintainers” beoordelen uiteindelijk of code wordt toegevoegd. Dit systeem bestaat al sinds de start van het project in 1991 en wordt nog altijd gebruikt, ook al experimenteert de gemeenschap inmiddels met moderne tools zoals GitLab voor bepaalde onderdelen.

GitHub, opgericht in 2008 en sinds 2018 onderdeel van Microsoft, populariseerde het pull request-model dat nu de industriestandaard is. Vrijwel elk modern open source-project, van kleine hobbyprojecten tot grote bedrijven, gebruikt deze werkwijze.

Sinds 2023 introduceerde GitHub AI-functies binnen zijn Copilot-product die automatisch commentaar geven op pull requests, nog voordat een mens meekijkt. Ook opkomende bedrijven als CodeRabbit (opgericht in 2023) bieden gespecialiseerde AI-reviewbots aan die zich volledig richten op het becommentariëren van pull requests. Amazon bracht met CodeGuru al in 2019 een dienst uit die met machine learning prestatieproblemen en beveiligingsrisico's in code opspoort.

Hoe ver is de techniek?

Menselijke code review is een volwassen, breed geaccepteerde praktijk; daar verandert weinig aan. De discussie zit vooral bij de AI-component. Onderzoek en ervaringen uit de praktijk laten zien dat AI-reviewtools nuttig zijn voor het opsporen van simpele fouten, stijlproblemen en bekende beveiligingszwaktes, maar nog moeite hebben met complexe, contextafhankelijke beoordelingen, zoals of een architecturale keuze wel logisch is binnen een groter systeem.

Een veelgehoord kritiekpunt is het aantal false positives: meldingen van “problemen” die bij nader inzien geen probleem zijn. Te veel van dit soort ruis kan ontwikkelaars juist minder alert maken, een fenomeen dat vergelijkbaar is met alarmmoeheid bij beveiligingssystemen. Bedrijven als GitHub en CodeRabbit werken continu aan het verbeteren van de nauwkeurigheid van hun modellen, maar onafhankelijke, grootschalige cijfers over hoe vaak AI-suggesties daadwerkelijk correct en nuttig zijn, zijn nog schaars.

De adoptie groeit niettemin snel: uit enquêtes van GitHub onder ontwikkelaars blijkt dat een meerderheid inmiddels weleens AI-hulpmiddelen gebruikt tijdens het programmeren, al is het gebruik specifiek voor code review nog relatief nieuw en minder wijdverspreid dan AI-hulp bij het schrijven van code zelf. De meeste experts zijn het erover eens dat AI-tools de menselijke reviewer voorlopig aanvullen in plaats van vervangen: ze vangen de voor de hand liggende fouten af, zodat mensen zich kunnen richten op de lastigere, contextrijke vragen.

Wie werken eraan?

Google en Microsoft (via GitHub) behoren tot de grootste spelers, zowel als gebruikers van uitgebreide interne reviewsystemen als als aanbieders van tools voor de rest van de wereld. Amazon ontwikkelt met CodeGuru eigen AI-gedreven reviewdiensten binnen zijn cloudplatform AWS. Meta (voorheen Facebook) bouwde intern het reviewsysteem Phabricator en publiceert regelmatig onderzoek over de effectiviteit van code review binnen grote teams.

Daarnaast is er een groeiend aantal gespecialiseerde bedrijven, zoals SonarSource (bekend van SonarQube, een veelgebruikte tool voor statische codeanalyse) en nieuwkomers als CodeRabbit en Codacy die zich volledig richten op geautomatiseerde codekwaliteit en review. Op academisch vlak doen onderzoeksgroepen aan universiteiten als Carnegie Mellon University en de TU Delft onderzoek naar hoe reviewprocessen effectiever gemaakt kunnen worden en hoe AI daarbij het beste kan worden ingezet.