Over deel 1 en deel 2 van deze serie maakten we een team snel. Een gedeelde skill zodat iedereen endpoints op dezelfde manier schrijft. Een plugin zodat iedereen dezelfde subagents en hooks heeft. Tien developers, allemaal code in de juiste vorm producerend op AI-snelheid.

Dát is het onderwerp van deze post.

Toen code langzaam te schrijven was, hield review vanzelf gelijke tred — er was simpelweg niet zoveel van. Nu opent je team twee keer zoveel pull requests, elk groter, elk geschreven door een AI die erg goed is in code produceren die er goed uitziet. De bottleneck is verschoven. Het is niet langer de code schrijven. Het is hem vertrouwen.

En in die snelheid schuilt een stille faalmodus: de AI schrijft het, een mens klikt op approve, en niemand heeft het echt begrepen. Er staat een naam op de commit, maar het begrip dat die naam suggereert is er niet.

Het principe waar ik steeds op terugkom is simpel: AI is een hulpmiddel; de developer is verantwoordelijk. Het is het principe dat ik vastlegde in de AI-governanceregels voor mijn team, en het enige in deze serie waarover niet te onderhandelen valt. Snelle AI verandert dat niet — het maakt het alleen makkelijker om te doen alsof. Review-gates zijn hoe je stopt met doen alsof.

De nieuwe bottleneck is review, niet productie

Je lost dit niet op door harder te reviewen. Een mens die tien AI-geschreven PR’s per dag doorloopt, gaat ze afstempelen, want aandacht schaalt niet zoals generatie dat doet.

Dus bouw je twee gates, en je bent bewust over welke wat doet:

  • een geautomatiseerde gate die het mechanische, het repetitieve vangt — de dingen waar een machine echt beter in is, en
  • een menselijke gate voor het kleine aantal dingen dat een machine niet vertrouwd kan beoordelen.

Het doel is niet méér review. Het is elk soort review neerzetten waar het daadwerkelijk werkt.

Laag 1 — de geautomatiseerde gate

Het meeste hiervan bouwde je al in deel 2: de dotnet-reviewer-subagent in je team-plugin. Nu geef je hem een taak met tanden — hij reviewt de diff voordat de pull request wordt geopend.

Richt hem op de wijzigingen en laat hem de mechanische pass doen:

“Review de staged diff met de dotnet-reviewer-subagent. Noem alleen problemen waar je zeker van bent, meest ernstig eerst.”

Dit is de laag die betrouwbaar de blinde vlekken van de AI in C# vangt:

// Het soort ding dat de geautomatiseerde gate moet tegenhouden:

public async void ProcessTrip(Guid id)          // async void — exceptions verdwijnen
{
    var trips = await _db.Trips.ToListAsync();   // laadt elke trip om er één te vinden
    var trip = trips.First(t => t.Id == id);     // een N+1 die op schaal staat te wachten
    trip.Complete();                             // geen null-check, gooit een exception
}

Niets daarvan is subtiel, en precies daarom hoort het bij de machine. async void, een query die de hele tabel ophaalt, een ontbrekende guard — daar hoort een reviewer geen menselijke aandacht aan te besteden, en een AI-reviewer vangt ze elke keer zonder bij de negende PR van de dag verveeld te raken.

Zet hem ook in CI, zodat hij op elke PR draait en niet alleen als iemand eraan denkt het te vragen. Het punt van een geautomatiseerde gate is dat hij niet optioneel is.

Maar let op wat deze gate je niet kan vertellen: of het endpoint zou moeten bestaan, of het in deze service thuishoort, of het teruggeven van dat veld aan die aanroeper een datalek is. Hij controleert het hoe. Hij heeft geen mening over het of.

Laag 2 — de menselijke gate

Dit is de laag die je niet kunt delegeren, en waar de hele serie naartoe heeft gebouwd.

Er is een handvol oordelen dat een mens moet vellen, juist omdat het de dingen zijn waar de AI het slechtst in is en waar de kosten het hoogst zijn als ze fout gaan:

  • Eigenaarschap. Begrijpt degene die dit merged het goed genoeg om het om 2 uur ’s nachts te fixen als het breekt? Als het eerlijke antwoord nee is, is het niet klaar — hoe groen de checks ook zijn.
  • Architectuur. De AI optimaliseert de wijziging die vóór hem ligt. Hij vertelt je niet dat dit de vierde net-iets-andere TripService is en dat het er één zou moeten zijn.
  • Security en data-intentie. “Geef de trip terug” en “geef de trip terug inclusief het thuisadres van de chauffeur aan een niet-geauthenticeerde aanroeper” zien er in een diff bijna identiek uit. Intentie zit niet in de syntax.
  • Domeincorrectheid. De code kan vlekkeloos zijn en tóch de verkeerde regel coderen, omdat de AI de requirement letterlijk nam en de requirement fout was.

De manier om deze gate eerlijk te houden is hem expliciet te maken in plaats van erop te hopen. Twee kleine artefacten doen het meeste werk.

Een CODEOWNERS-bestand, zodat de juiste mens verplicht is — niet gevraagd — bij de wijzigingen die ertoe doen:

# .github/CODEOWNERS
/src/Payments/    @acme/payments-leads
/src/Auth/        @acme/security
*.sql             @acme/data

En een pull-request-template die degene die merged vraagt om het begrip te claimen dat de AI niet kan:

## Checklist menselijke review
- [ ] Ik begrijp deze wijziging goed genoeg om hem in productie te debuggen.
- [ ] Ik heb gecheckt welke data dit blootstelt, en aan wie.
- [ ] Dit past in de bestaande architectuur (of de afwijking is bewust en
      hieronder toegelicht).
- [ ] De domeinregel hier is degene die we ook echt willen.

Die vinkjes zijn geen ceremonie. Ze zijn het verschil tussen een naam op een commit en een mens die erachter staat.

Waar dit gevaarlijk wordt

Eén eerlijke waarschuwing, want dit is de faalmodus waar ik me het meest zorgen over maak.

Een groene gate is geen begrip. Het echte risico van goede geautomatiseerde review is niet dat hij dingen mist — het is dat hij geruststelt. Een geslaagde dotnet-reviewer en een muur van groene vinkjes maken het veilig-voelend om te approven zonder te lezen. Dat is precies het moment waarop verantwoordelijkheid verdampt: iedereen nam aan dat de gate betekende dat iemand had gekeken, en niemand had gekeken.

De geautomatiseerde gate bestaat om menselijke aandacht vrij te maken voor de oordelen die alleen een mens kan vellen — niet om ze te vervangen. Als je review-gates ervoor zorgen dat mensen minder zorgvuldig lezen, heb je een snellere manier gebouwd om code te verschepen die niemand bezit. Let erop.

Probeer het deze week

Begin niet met tooling. Begin met een zin waar je team het over eens is:

Deze drie dingen controleert een mens altijd vóór merge — wat de AI of de CI ook zegt.

Schrijf jullie drie op. Eigenaarschap is er waarschijnlijk één. Kies de andere twee uit wat in jouw domein echt pijn doet. En dan — en pas dan — maak je er een PR-checklist en een CODEOWNERS-regel van, zodat ze verplicht zijn, niet onthouden.

Wat staat er op jouw lijst? Wat mag een AI nooit alleen afvinken? Ik lees jullie drie graag in de comments — dit is het deel dat elk team voor zichzelf moet beantwoorden, en de antwoorden zijn het delen waard.

Dat is de serie: een gedeelde skill, een team-plugin, en de review-gates die een mens verantwoordelijk houden voor wat al die snelheid produceert. Wil je Claude Code naar een heel .NET-team brengen en een tweede paar ogen op de aanpak — zonder de weg kwijt te raken? Plan een gesprek — dat is het soort ding dat ik graag doorpraat.