Rachel Laycock betoogt dat het traditionele proces van code reviews via pull requests niet langer houdbaar is nu AI de hoeveelheid geproduceerde code enorm heeft verhoogd. In plaats van de review-stap simpelweg te automatiseren met AI, pleit zij voor een 'shift left'-benadering: het verplaatsen van kennisdeling, architecturale afstemming en mentoring naar een moment voordat de code wordt geschreven.
Door in te zetten op methoden zoals pair programming, mob programming, collectieve designsessies en trunk-based development, wordt het team gezamenlijk verantwoordelijk voor de oplossing. Menselijke reviews zouden volgens Laycock gereserveerd moeten worden voor uitzonderingen, zoals fundamentele architecturale wijzigingen of kritieke beveiligingsonderdelen. Het doel is om engineers te behouden die de systemen als geheel begrijpen, in plaats van een proces waarbij senior engineers een bottleneck worden in het inspecteren van oneindige hoeveelheden code-diffs.
Misschien zouden we niet al deze code moeten reviewen
Kort samengevat Misschien is het probleem niet dat AI de code review heeft kapotgemaakt, maar dat we code reviews hebben gebruikt om de verkeerde problemen op te lossen.
Ik zat onlangs in een panel met Brian Houck van DX tijdens Code Remix, georganiseerd door Moderne. Het was een van de interessantste panels die ik heb gedaan, grotendeels omdat we het oneens waren. Zoals mijn collega Martin Fowler zegt, zijn panels veel interessanter wanneer mensen het oneens zijn en beide partijen een goed argument hebben. Brian en ik hadden dat zeker.
Brian heeft sindsdien een doordacht stuk geschreven met de titel What are code reviews even for?. Hij is duidelijk gepassioneerd over zijn standpunt, en ik ben gepassioneerd genoeg over het mijne om deze reactie te schrijven. Om duidelijk te zijn: ik denk dat we grotendeels hetzelfde willen. Ik denk alleen niet dat code review de beste manier is om dat te bereiken. Brian is overigens erg vriendelijk en moedigde me aan om dit te schrijven. Maar ik zou liegen als ik zei dat ik niet wil dat jullie aan het eind denken dat ik gelijk heb :)
Waarover waren we het oneens?
AI produceert meer code dan mensen realistisch kunnen reviewen. Brian citeert enkele opvallende cijfers: bij Meta is het aantal significante regels code per door mensen ingediende diff in een jaar tijd naar verluidt met 106% gestegen, terwijl de eigen data van DX laat zien dat de mediane grootte van pull requests met 64% is toegenomen.
Zijn zorg, die ik deel, is dat het simpelweg automatiseren van de code review het risico met zich meebrengt dat we alle andere zaken verliezen waar we het voor gebruiken. Code review gaat niet alleen over het vinden van bugs. Het is de manier waarop teams kennis delen, junior engineers opleiden, collectief eigenaarschap opbouwen en architectonisch begrip verspreiden.
Mijn vraag is: waarom wachten we tot de code review om al deze dingen te doen?
Ik heb nooit echt gehouden van pull requests als het centrum van het softwareontwikkelingsproces. Niet omdat engineers niet naar elkaars code moeten kijken, maar omdat ik altijd moeite heb gehad met het idee dat we iets moeten bouwen, het moeten afronden, het moeten verpakken, het naar iemand anders moeten overdragen en dan pas het belangrijke gesprek moeten voeren over de vraag of we het juiste ding op de juiste manier hebben gebouwd.
En begin me niet eens over merge conflicts. Daar heb ik te veel uren van mijn leven aan verloren.
Verschuif de beoordeling naar links (Shift Left)
Een van de principes die ik vroeg leerde bij Thoughtworks was om feedbackloops te verkorten. Als feedback waardevol is, moet je deze niet verwijderen, maar dichter bij de beslissing brengen die het informeert.
Laten we kijken naar de zaken die we zeggen dat code review ons oplevert:
- Alternatieve oplossingen verkennen: Ik zou dat liever doen voordat er een oplossing wordt geïmplementeerd.
- Kennisoverdracht: Ga in pair programming. Naast iemand zitten, fysiek of virtueel, terwijl diegene door een probleem redeneert, leert je veel meer dan het achteraf lezen van de voltooide oplossing.
- Leren van ervaren engineers: Laat junior engineers samenwerken met ervaren engineers terwijl ze aan het nadenken zijn. Weer is pairing hier een voorbeeld, maar teams zouden ook collectieve designsessies kunnen houden met een whiteboard voordat ze iets schrijven (of een AI-agent instructies geven om iets te schrijven).
- Collectief eigenaarschap: Richt teams zo in dat mensen software daadwerkelijk collectief bouwen en beheren, in plaats van te vertrouwen op een pull request om iedereen te vertellen wat iemand anders al heeft gebouwd. Gebruik hiervoor opnieuw pairing, mob programming of team-designsessies rond een whiteboard.
- Architectonische afstemming: Ontwerp samen (ik zal mezelf niet herhalen over pairing en team-designsessies) en codeer vervolgens de belangrijke beperkingen als fitness functions.
- Oppervlakkige controles: Als we code reviewen op formatting, linting, bekende beveiligingsproblemen of zaken die deterministisch getest kunnen worden, automatiseer dit dan. We zouden in 2026 echt niet meer moeten discussiëren over witruimte.
Pair programming, trunk-based development, geautomatiseerd testen, statische analyse, fitness functions en security scanning verplaatsen de feedback naar een eerder stadium. Steeds vaker kunnen AI-agents deelnemen aan die loops door designs uit te dagen, aannames te testen en continu te verifiëren wat er wordt gebouwd. Maar het echte denkwerk komt van ervaren mensen, en als we willen dat die ervaring het hele team ten goede komt, moeten we ons veel eerder als één team gedragen dan pas bij de code review.
Reviewen op basis van uitzonderingen
Niets hiervan betekent dat er nooit meer code wordt gereviewd. Er zijn absoluut wijzigingen waarbij ik wil dat een andere ervaren mens meekijkt. Een voorbeeld hiervan is een fundamentele architectonische wijziging. Uitgaande van het feit dat we een designsessie hebben gehad met het bredere team, willen we de code wellicht als team reviewen om af te spreken dat het correct is geïmplementeerd, of om te bespreken of we nog iets willen wijzigen. Andere voorbeelden zijn wijzigingen die een gevoelige beveiligingsgrens overschrijden, wijzigingen met een enorme potentiële impact (blast radius), een onbekend deel van een kritisch systeem, of simpelweg iets waar het team zegt: "Ik heb hier geen vertrouwen in."
Dat zijn precies de plekken waar menselijk oordeel waardevol is, maar dat is heel anders dan het eisen dat een mens elke wijziging inspecteert omdat dat het ritueel is dat we historisch hebben gebruikt om vertrouwen te creëren.
En we weten nu dat het niet levensvatbaar is om dit pad te blijven volgen, wat verklaart waarom code review steeds als een probleem of blokkade naar voren komt. Als een agent tien keer zoveel code kan produceren, maar elke regel uiteindelijk in een wachtrij komt te staan voor een senior engineer om deze te inspecteren, hebben we geen tien keer zo effectieve engineering-organisatie gecreëerd, maar een enorme backlog en een nieuwe bottleneck.
Ik denk niet dat het antwoord een AI-agent is die zich voordoet als de menselijke reviewer, zodat we precies hetzelfde proces op hogere snelheid kunnen behouden. Dat is het automatiseren van het ritueel in plaats van het bevragen van waarom het ritueel bestaat.
Er is één ding in het argument van Brian waar ik me wel zorgen over maak. Hij spreekt over teams die cognitieve schuld en intent debt opbouwen: software groeit terwijl de mensen die er verantwoordelijk voor zijn steeds minder begrijpen waarom het werkt zoals het werkt. Ik denk dat dit een zeer reëel probleem is. Ik denk alleen niet dat verplichte pull requests een bijzonder sterke verdediging hiertegen zijn.
Als agents een aanzienlijk groter deel van de implementatie gaan produceren, moeten we veel bewuster zijn over het behouden van menselijk begrip door middel van collaboratief ontwerp, pairing, goede grenzen, uitvoerbare architectuur, gedeelde operationele verantwoordelijkheid en waarschijnlijk enkele praktijken die we nog moeten uitvinden.
We hebben engineers nodig die systemen begrijpen, niet diffs.
Misschien is dat wel wat AI aan het blootleggen is. We hebben jarenlang een buitengewoon aantal verantwoordelijkheden op de bescheiden code review geprojecteerd: kwaliteitscontrole, beveiligingscheck, architectuurreview, mentoringsmechanisme, systeem voor kennisdeling en eigendomsmodel.
Het werkte, op een bepaalde manier, zolang mensen code slechts in een bepaald tempo konden produceren. Die beperking verdwijnt nu. Dus misschien is de vraag niet hoe we de code sneller gereviewd krijgen. Misschien is de vraag waarom we überhaupt wachten tot de code review om alle belangrijke gesprekken te voeren.
Misschien zouden we niet al deze code moeten reviewen
Kort samengevat Misschien is het probleem niet dat AI de code review heeft kapotgemaakt, maar dat we code reviews hebben gebruikt om de verkeerde problemen op te lossen.
Ik zat onlangs in een panel met Brian Houck van DX tijdens Code Remix, georganiseerd door Moderne. Het was een van de interessantste panels die ik heb gedaan, grotendeels omdat we het oneens waren. Zoals mijn collega Martin Fowler zegt, zijn panels veel interessanter wanneer mensen het oneens zijn en beide partijen een goed argument hebben. Brian en ik hadden dat zeker.
Brian heeft sindsdien een doordacht stuk geschreven met de titel What are code reviews even for?. Hij is duidelijk gepassioneerd over zijn standpunt, en ik ben gepassioneerd genoeg over het mijne om deze reactie te schrijven. Om duidelijk te zijn: ik denk dat we grotendeels hetzelfde willen. Ik denk alleen niet dat code review de beste manier is om dat te bereiken. Brian is overigens erg vriendelijk en moedigde me aan om dit te schrijven. Maar ik zou liegen als ik zei dat ik niet wil dat jullie aan het eind denken dat ik gelijk heb :)
Waarover waren we het oneens?
AI produceert meer code dan mensen realistisch kunnen reviewen. Brian citeert enkele opvallende cijfers: bij Meta is het aantal significante regels code per door mensen ingediende diff in een jaar tijd naar verluidt met 106% gestegen, terwijl de eigen data van DX laat zien dat de mediane grootte van pull requests met 64% is toegenomen.
Zijn zorg, die ik deel, is dat het simpelweg automatiseren van de code review het risico met zich meebrengt dat we alle andere zaken verliezen waar we het voor gebruiken. Code review gaat niet alleen over het vinden van bugs. Het is de manier waarop teams kennis delen, junior engineers opleiden, collectief eigenaarschap opbouwen en architectonisch begrip verspreiden.
Mijn vraag is: waarom wachten we tot de code review om al deze dingen te doen?
Ik heb nooit echt gehouden van pull requests als het centrum van het softwareontwikkelingsproces. Niet omdat engineers niet naar elkaars code moeten kijken, maar omdat ik altijd moeite heb gehad met het idee dat we iets moeten bouwen, het moeten afronden, het moeten verpakken, het naar iemand anders moeten overdragen en dan pas het belangrijke gesprek moeten voeren over de vraag of we het juiste ding op de juiste manier hebben gebouwd.
En begin me niet eens over merge conflicts. Daar heb ik te veel uren van mijn leven aan verloren.
Verschuif de beoordeling naar links (Shift Left)
Een van de principes die ik vroeg leerde bij Thoughtworks was om feedbackloops te verkorten. Als feedback waardevol is, moet je deze niet verwijderen, maar dichter bij de beslissing brengen die het informeert.
Laten we kijken naar de zaken die we zeggen dat code review ons oplevert:
- Alternatieve oplossingen verkennen: Ik zou dat liever doen voordat er een oplossing wordt geïmplementeerd.
- Kennisoverdracht: Ga in pair programming. Naast iemand zitten, fysiek of virtueel, terwijl diegene door een probleem redeneert, leert je veel meer dan het achteraf lezen van de voltooide oplossing.
- Leren van ervaren engineers: Laat junior engineers samenwerken met ervaren engineers terwijl ze aan het nadenken zijn. Weer is pairing hier een voorbeeld, maar teams zouden ook collectieve designsessies kunnen houden met een whiteboard voordat ze iets schrijven (of een AI-agent instructies geven om iets te schrijven).
- Collectief eigenaarschap: Richt teams zo in dat mensen software daadwerkelijk collectief bouwen en beheren, in plaats van te vertrouwen op een pull request om iedereen te vertellen wat iemand anders al heeft gebouwd. Gebruik hiervoor opnieuw pairing, mob programming of team-designsessies rond een whiteboard.
- Architectonische afstemming: Ontwerp samen (ik zal mezelf niet herhalen over pairing en team-designsessies) en codeer vervolgens de belangrijke beperkingen als fitness functions.
- Oppervlakkige controles: Als we code reviewen op formatting, linting, bekende beveiligingsproblemen of zaken die deterministisch getest kunnen worden, automatiseer dit dan. We zouden in 2026 echt niet meer moeten discussiëren over witruimte.
Pair programming, trunk-based development, geautomatiseerd testen, statische analyse, fitness functions en security scanning verplaatsen de feedback naar een eerder stadium. Steeds vaker kunnen AI-agents deelnemen aan die loops door designs uit te dagen, aannames te testen en continu te verifiëren wat er wordt gebouwd. Maar het echte denkwerk komt van ervaren mensen, en als we willen dat die ervaring het hele team ten goede komt, moeten we ons veel eerder als één team gedragen dan pas bij de code review.
Reviewen op basis van uitzonderingen
Niets hiervan betekent dat er nooit meer code wordt gereviewd. Er zijn absoluut wijzigingen waarbij ik wil dat een andere ervaren mens meekijkt. Een voorbeeld hiervan is een fundamentele architectonische wijziging. Uitgaande van het feit dat we een designsessie hebben gehad met het bredere team, willen we de code wellicht als team reviewen om af te spreken dat het correct is geïmplementeerd, of om te bespreken of we nog iets willen wijzigen. Andere voorbeelden zijn wijzigingen die een gevoelige beveiligingsgrens overschrijden, wijzigingen met een enorme potentiële impact (blast radius), een onbekend deel van een kritisch systeem, of simpelweg iets waar het team zegt: "Ik heb hier geen vertrouwen in."
Dat zijn precies de plekken waar menselijk oordeel waardevol is, maar dat is heel anders dan het eisen dat een mens elke wijziging inspecteert omdat dat het ritueel is dat we historisch hebben gebruikt om vertrouwen te creëren.
En we weten nu dat het niet levensvatbaar is om dit pad te blijven volgen, wat verklaart waarom code review steeds als een probleem of blokkade naar voren komt. Als een agent tien keer zoveel code kan produceren, maar elke regel uiteindelijk in een wachtrij komt te staan voor een senior engineer om deze te inspecteren, hebben we geen tien keer zo effectieve engineering-organisatie gecreëerd, maar een enorme backlog en een nieuwe bottleneck.
Ik denk niet dat het antwoord een AI-agent is die zich voordoet als de menselijke reviewer, zodat we precies hetzelfde proces op hogere snelheid kunnen behouden. Dat is het automatiseren van het ritueel in plaats van het bevragen van waarom het ritueel bestaat.
Er is één ding in het argument van Brian waar ik me wel zorgen over maak. Hij spreekt over teams die cognitieve schuld en intent debt opbouwen: software groeit terwijl de mensen die er verantwoordelijk voor zijn steeds minder begrijpen waarom het werkt zoals het werkt. Ik denk dat dit een zeer reëel probleem is. Ik denk alleen niet dat verplichte pull requests een bijzonder sterke verdediging hiertegen zijn.
Als agents een aanzienlijk groter deel van de implementatie gaan produceren, moeten we veel bewuster zijn over het behouden van menselijk begrip door middel van collaboratief ontwerp, pairing, goede grenzen, uitvoerbare architectuur, gedeelde operationele verantwoordelijkheid en waarschijnlijk enkele praktijken die we nog moeten uitvinden.
We hebben engineers nodig die systemen begrijpen, niet diffs.
Misschien is dat wel wat AI aan het blootleggen is. We hebben jarenlang een buitengewoon aantal verantwoordelijkheden op de bescheiden code review geprojecteerd: kwaliteitscontrole, beveiligingscheck, architectuurreview, mentoringsmechanisme, systeem voor kennisdeling en eigendomsmodel.
Het werkte, op een bepaalde manier, zolang mensen code slechts in een bepaald tempo konden produceren. Die beperking verdwijnt nu. Dus misschien is de vraag niet hoe we de code sneller gereviewd krijgen. Misschien is de vraag waarom we überhaupt wachten tot de code review om alle belangrijke gesprekken te voeren.
Groetjes,