Code review in het AI-tijdperk — wie keurt er nog na als AI de code schrijft?

In mijn vorige post (AI173) noemde ik verificatie als de derde nieuwe bottleneck zodra code bijna gratis wordt, met een toezegging: “die behandel ik in deel vier.” Hier komt die belofte ingelost. Eerst de conclusie: als ik medio 2026 terugkijk, is de grootste variabele die AI-codingtools opleveren niet het aantal licenties, niet het aantal seats en niet de modelscores — het is de reviewbandbreedte.

Eind 2025 analyseerde CodeRabbit 470 opensource-pullrequests op GitHub. De conclusie: code die met AI tot stand kwam, bevatte 1,7× meer defecten dan code die uitsluitend door mensen was geschreven (gemiddeld 10,83 versus 6,45 per PR, zonder correctie voor bestandsgrootte of complexiteit). Voor specifieke subcategorieën van beveiligingslekken liep de multiplier uiteen van 1,57 tot 2,74: XSS 2,74×, onjuist wachtwoordbeheer 1,88×, onveilige directe objectreferenties (IDOR) 1,91×, onveilige deserialisatie 1,82×. Op het vlak van logica en correctheid ging het om 1,75×, leesbaarheid 3×+, formattering 2,66× en foutafhandeling bijna 2×.

Apiiro vulde dat beeld in september 2025 aan met een scan van codeopslagplaatsen bij Fortune 50-bedrijven (data van december 2024 tot juni 2025). Het maandelijkse aantal securitybevindingen schoot daar van circa 1.000 naar meer dan 10.000 – een vertienvoudiging. Bevindingen rond privilege-escalatie stegen met 322% in absolute aantallen; genormaliseerd naar hoeveelheid code komt dat neer op ruwweg 60–80%. Ontwerpfouten op architectuurniveau namen met 153% toe. In dezelfde periode daalden syntaxisfouten met 76% en logische bugs met 60%.

Die combinatie van deze twee datasets vertelt hetzelfde verhaal, en dat is in een sterk gereguleerde context extra relevant: een groot deel van die 322% stijging in privilege-escalatiekwetsbaarheden van Apiiro valt precies op de grens van autorisaties — en die grens raakt in de financiële sector en bij telecomoperators direct aan klanttegoeden en klantdata. AI-gegenereerde code werkt steeds vaker, maar het aandeel bugs en kwetsbaarheden neemt evenredig toe, en juist de gevaarlijke categorieën groeien in stilte. (Toelichting op de bron: het CodeRabbit-rapport weerspiegelt het standpunt van de leverancier; de Apiiro-cijfers komen van een onafhankelijke securityvendor. De richting van de conclusies komt overeen, maar bij de interpretatie moet je rekening houden met de normalisatiemethode.)

Wanneer je dit feit naar de praktijk van een onderneming vertaalt, levert het twee contra-intuïtieve inzichten op — en elk van die twee staat haaks op het verhaal dat de tooling die je inkoopt je wil vertellen.

1. Twee contra-intuïtieve inzichten

Inzicht 1: De rol van de developer verschuift van “iemand die code schrijft” naar “iemand die code beoordeelt”, en beoordelen is vermoeiender dan schrijven.

JetBrains publiceerde in januari 2026 een enquête onder meer dan 10.000 ontwikkelaars in 8 talen, waaruit bleek dat 90% minstens één AI-tool gebruikt. Een nog opvallender cijfer komt uit een Pragmatic Engineer-enquête van februari 2026: 56% van de senior engineers gaf aan dat 70% of meer van hun engineeringwerk afhankelijk is van AI-tools (zelfrapportage van zwaargebruikers, niet uitgedrukt in regels code). Het gaat dus niet om af en toe een paar regels door AI laten schrijven; AI is de standaardwerkwijze geworden.

De arbeidsverhoudingen zijn opnieuw ingedeeld: het schrijven van code is nu het domein van AI, en ontwikkelaars besteden meer tijd aan lezen en beoordelen — aan review. Het lezen van andermans code is inherent moeilijker en trager dan het zelf schrijven. Het lezen van onbekende, door AI gegenereerde code en daar vervolgens een oordeel over vellen binnen compliancegrenzen en bedrijfsregels legt een merkbaar hogere cognitieve last op dan het schrijven van je eigen code. Dit is de kern van de aanhoudende klacht onder ontwikkelaars in 2025–2026 dat “AI me vermoeider maakt” — en het sluit aan bij de omgekeerde conclusie van METR (februari 2026). De eerdere bevinding dat senior ontwikkelaars door AI 19% werden vertraagd, werd in een nieuwe steekproef deels teruggedraaid; nieuwkomers noteerden nog steeds -4%. Het eindoordeel luidt dat de reviewbandbreedte krapper is dan de productiebandbreedte.

Tegenintuïtie 2: hoe krachtiger de AI-tools, hoe minder organisaties extra tools nodig hebben — en hoe meer ze governance nodig hebben.

Leer AI Langzaam 173 — Wanneer AI de flessenhals verplaatst naar het code review-team

De 1,7× meer defecten van CodeRabbit en de 322% toename van privilege-escalation-bevindingen van Apiiro lijken op het eerste gezicht AI-mislukkingen. Bekeken door de lens van de Theory of Constraints (TOC) zijn ze echter een onvermijdelijk gevolg van een groeiend gat: de productie van je tools stijgt, je reviewcapaciteit niet. Het output van een systeem wordt bepaald door de smalste schakel. AI heeft het “schrijven” verbreed; de smalste schakel is nu “reviewen.” Als de bandbreedte van die review niet meegroeit, schrijft AI steeds sneller code terwijl de organisatie stilletjes een steeds gevaarlijker schuld opbouwt. Dit is de analyse van AI173 — automatisering vernietigt knelpunten niet, het verplaatst ze.

Van één knelpunt naar meerdere, dynamische knelpunten

Deze stelling op AI-coding toepassen vergt een aanvulling: softwareontwikkeling is geen lineaire pipeline met één bottleneck, maar een set parallelle knelpunten die continu verschuiven. TOC werkt prima in een klassieke productielijn. In een AI-coding-context met meerdere parallelle bottlenecks is de smalste schakel weliswaar verschoven van “schrijven” naar “reviewen”, maar binnen dat reviewen splitsen zich drie onafhankelijke knelpunten af — verificatie, governance en compliance-review — die elk hun eigen wachtrij vormen.

Traditionele pipeline	AI-coding context
Eén knelpunt, stabiel	Meerdere knelpunten, dynamisch
Oorzaak → gevolg is lineair	Feedbackloops en koppelingen
Doorbraak op één plek	Doorbraak nodig op elke bottleneck

Drie knelpunten binnen “reviewen”

Verificatie: bevestigen dat de code doet wat hij belooft, en niets wat hij niet belooft.
Governance: keuzes over wie wat mag mergen, onder welke voorwaarden, met welke documentatie.
Compliance-review: voldoen aan wet- en regelgeving — denk aan GDPR voor EU-context, NIS2 voor vitale sectoren, de Japanse 個人情報保護法 (Personal Information Protection Act) voor de Japanse markt, of SOC 2 / HIPAA voor de Verenigde Staten.

De verborgen kosten van ongebruikte productiecapaciteit

Een organisatie die investeert in AI-coding tools zonder de reviewzijde te versterken, koopt geen productiviteit — die koopt illusies. De ongebruikte productiecapaciteit van AI wordt omgezet in ongeteste, ongereviewde code die stilletjes wacht tot het uitrolt. In een telecomomgeving (AT&T, Deutsche Telekom, Telefónica) kan dat een firmware-update voor een basisstation zijn die de reviewslag niet haalt. In een bankcontext (een Tier-1-speler in Frankfurt of Madrid) kan het een kredietbeslissingsmodule zijn die net buiten de grenzen van DORA valt. De bottleneck verplaatsen betekent niet dat het werk verdwijnt; het werk hoopt zich op waar je niet kijkt.

Wat de Change Advisory Board (Change Advisory Board (CAB)) hiermee te maken heeft

De Change Advisory Board is van oudsher de instantie die wijzigingen beoordeelt op risico, impact en compliance. In een AI-coding-context is de Change Advisory Board (CAB) geen optionele poort meer; hij wordt de expliciete eigenaar van de bottleneck. Vragen die de Change Advisory Board (CAB) nu moet beantwoorden:

Is de AI-gegenereerde code geverifieerd door een tweede paar ogen — mens of machine?
Zijn de merge-rechten afgestemd op het risicoprofiel van de wijziging?
Is de audit-trail compleet genoeg voor een toezichthouder?

Een “ja” op deze drie is geen detail meer; het is de bandbreedte die bepaalt hoe snel je organisatie kan bewegen.

Wat je als CIO kunt doen

Meet de drie review-bandbreedtes apart. Aggregate metrics verbergen het knelpunt.
Investeer in tooling die review versnelt zonder de drempel te verlagen. AI voor de review, niet alleen voor de code.
Maak de Change Advisory Board (CAB) tot strategisch orgaan, niet tot ceremonieel gatekeeper.
Accepteer dat AI geen bottleneck oplost — het creëert een nieuwe. De vraag is alleen of jij die het eerst ziet, of je auditor.

Bronnen en verder lezen

CodeRabbit — productrapport en benchmarkcijfers (1,7× defecten)
Apiiro — privilege-escalation findings 2024–2025 (322%)
Theory of Constraints — Goldratt, The Goal
ISO/IEC 42001 — AI-managementsysteemnorm

De praktische implicatie van deze wetmatigheid werkt op twee niveaus. Het eerste niveau: vóór je autonome agents inzet, installeer eerst de vier remmen — verplichte menselijke code review, geautomatiseerd testen (AI-code moet gewoon draaien), security scanning (volgens dezelfde standaard als door mensen geschreven code), en canary releases (AI-wijzigingen eerst op kleine schaal uitrollen). PR’s van AI mogen niet zonder review. Dit is de minimale drempel om van “AI schrijft code” naar “AI schrijft code + de organisatie kan het opvangen” te komen — ontbreekt er één, dan is het een kwestie van tijd voor het misgaat.

Carlini documenteerde in januari–februari 2026 een vaak aangehaald voorbeeld: een Anthropic-onderzoeker liet 16 Claude Opus 4.6-agents parallel twee weken draaien, goed voor circa 2.000 sessies en zo’n $20.000 aan API-kosten, en bouwde vanuit het niets een Rust-gebaseerde C-compiler van 100.000 regels die Linux 6.9 kan compileren en 99% van de GCC torture tests doorstaat. Belangrijk om te benadrukken: dit was een gecontroleerd experiment in een afgebakend domein; Carlini heeft de code niet naar productie gebracht. Het is nuttig als “extreme casus zonder review”, maar als blauwdruk voor “morgen autonome agents in productie” overschat het de herhaalbaarheid. In een organisatie zonder code review, zonder geautomatiseerde tests, zonder security scanning en zonder canary releases loopt het vroeg of laat uit de hand.

De verborgen laag: AI-code-review draait niet om bugs, maar om architectuur, compliance en bedrijfslogica

De kernvraag bij review is niet “zit er een bug in deze code?”, maar “past deze code in dit bestand, in dit project, binnen deze compliancegrens?” Daar schuilt het grootste misverstand voor engineers die hun hele carrière met klassieke code-review hebben gewerkt. In het verleden checkte je of een stuk code fout was. In het AI-tijdperk check je of het überhaupt op deze plek thuishoort.

Neem de cijfers: CodeRabbit rapporteert 1,82–2,74× meer gedetecteerde beveiligingslekken, Apiiro 322% meer escalatie-vulnerabilities. Het patroon is steeds hetzelfde: de AI schreef geen onjuiste code, maar code op de verkeerde plek, met de verkeerde permissies, met de verkeerde standaardconfiguratie. Dit soort problemen los je niet op in de IDE; ze worden pas zichtbaar aan de reviewtafel — als je ze tenminste herkent.

In de praktijk werkt het zo: de branch protection- en CODEOWNERS-regels van GitHub/GitLab worden rood gemarkeerd voor elke wijziging die raakt aan schema, auth, billing of een compliancegrens. Zulke wijzigingen routeren naar een verplichte dubbele sign-off — in de financiële sector en bij telecomoperators doorgaans geen volledige review, maar een backup veto met spot-checks die schalen met het risiconiveau (laag risico, lage sample; hoog risico, hoge sample).

De discussie die je écht aan tafel moet voeren draait om drie zaken:

Architectuurbeslissingen (ADR’s — Architecture Decision Records)
Security- en compliancebasislijnen
Bedrijfsregelcorrectheid — doet de code wat hij hoort te doen voor het domein?

Dat is waar de reviewtijd naartoe moet in het AI-tijdperk.

Plaats je deze twee contra-intuïtieve inzichten naast elkaar, dan wordt het beeld scherp: in het AI-tijdperk moet een bedrijf drie dingen aanpassen in code review — haal de R&D-directeur in het reviewproces, leg compliance- en architectuurbaselines vast in de PR-routering, en rapporteer governance-KPI’s zoals het faalpercentage aan de directie. Die drie sluiten direct aan op de “drie verdedigingslinies van modelgovernance” (business, IT, compliance/audit) zoals vereist door de Chinese Commercial Bank Internet Loan Management Measures — voor toezichthouders een bekend raamwerk. Hieronder werk ik het in vier lagen uit.

2. Waarom “nu”: het mechanisme achter verificatie als nieuwe bottleneck

Ik kom nu terug op de belofte uit §3 van AI173 (“komt in §4”). Wat het venster rond medio 2026 bijzonder maakt: autonome agents (Claude Code, Codex) gaan van “pilots” naar “default”; organisaties die hun review-upgrade niet vóór H2 op orde hebben, krijgen de problemen geconcentreerd in de Q4-piekverkoop / eindejaar-code-freeze / reguliere toezichtmomenten. Eerst waarom “verificatie” binnen die nieuwe bottleneck het meest onderschat wordt, daarna plaats ik het samen met de andere twee nieuwe bottlenecks (de juiste vraag stellen, systeemintegratie) op één figuur.

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI-codegeneratievolume 6× Reviewbandbreedte 1,3×

Gap = risico-opbouw (defecten +1,7×, beveiligingslekken +1,82–2,74×, privilege-escalatie +322%)
Verhoudingen zijn richtinggevend; gebaseerd op JetBrains 2026.1-onderzoek, CodeRabbit 2025.12-rapport, Apiiro 2025.9-rapport

De onderschatte kern: de meeste discussies over AI-coding vatten “validatie” standaard op als CI/CD, unit tests draaien en lint passeren. Dat is de wereld van internetproducten: code wordt naar de cloud gedeployed, unit tests zijn groen, CI slaagt, merge naar productie. Die flow werkt in het tempo van internetproducten, maar gaat niet op voor telecom, financiële dienstverlening, maakindustrie of e-commerce: in die sectoren betekent “validatie” algorithmic filing (algoritmeregistratie bij de toezichthouder), graded security assessment (verplichte cybersecurity-audit, vergelijkbaar met NIS2/GDPR), cross-border data transfer assessment (data-exporttoets onder China’s Cybersecurity Law / Data Security Law), Change Advisory Board-goedkeuring, reconciliation-audit en regulatorische rapportage — allemaal niets met code te maken, maar elk goed voor enkele weken doorlooptijd. AI173 gaf hier al een schema (codeersnelheid stijgt, het knelpak zit in validatie), dat herhalen we niet. Waar het om gaat is de open vraag die het achterliet: hoeveel validatiestappen moet door AI geschreven code doorlopen voor het productie haalt?

Zeven stappen als minimum: geautomatiseerd testen + code review + security scanning + architectuur-/ADR-review + business rule review + compliance-clearance + canary release. Elke stap kost bandbreedte. Die zeven opgeteld zijn de “andere kant” van het schema uit AI173 — wat AI versnelt is het segment met de laagste marginale kosten (GPU-uren, licentiekosten), terwijl validatie het segment met de hoogste institutionele kosten opslokt (toezicht, registratie, reconciliatie).

De tweede onderschatte wortel is het versmallen van “review” tot “code review”. De twee belangrijkste bronnen van code review — egoless programming uit Weinberg’s The Psychology of Computer Programming (1971, NASA/academische achtergrond) en Fagan Inspections uit IBM in 1976 — delen dezelfde veronderstelling: code wordt regel voor regel geschreven, de schrijver kent de code het best, en iemand anders leest hem daarna nog eens na om fouten te vinden. AI haalt die veronderstelling onderuit: code wordt in enkele seconden door een model uitgespuwd, de “schrijver” (het AI-systeem) draagt geen context over, en de “lezer” (de ontwikkelaar) krijgt iets te zien dat voor hem volledig vreemd is. De oude “foutenzoek”-aanname werkt niet meer. De nieuwe vraag die een review moet beantwoorden is — hoort deze code eigenlijk wel in dit bestand? Omzeilt hij bestaande architectuurbeslissingen? Valt hij binnen of buiten de compliancegrens? Worden de standaardinstellingen in productie een beveiligingslek?

Elk van die drie vragen vereist iemand die zowel de business, de architectuur als de regelgeving begrijpt; de tooling is slechts ondersteunend. Dat is de stap van een lint-gate in de CI/CD-pipeline naar een volwaardige engineering governance-praktijk.

III. Het drieledige beoordelingsmodel: AI-pre-review, menselijke gatekeeping en governance-regels

Laat ik bovenstaande analyse samenvatten in een uitvoerbare structuur. Het drieledige model is geen vervanging maar een stapeling — elke PR passeert gelijktijdig alle drie de lagen, en elke laag behandelt een eigen klasse problemen.

Laag 1 draait op seconde-tot-minuutniveau — elke regel AI-gegenereerde code gaat eerst door een tool. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot en Antigravity Review leveren binnen tientallen seconden tot enkele minuten na PR-aanmaak commentaar, met dekking voor lint, beveiligingslekken, duplicatie, naamgeving en dependency-risico’s. De kosten van deze laag zijn verwaarloosbaar (ongeacht het aantal PR’s blijft het een vast abonnement), de dekking is hoog (iedere PR passeert), en het vormt de bandbreedtebasis. Maar de blinde vlek is even duidelijk: deze laag kan geen architectuurafstemming, compliance-grenzen of businesscorrectheid garanderen. CodeRabbit rapporteert zelf dat het “de meeste expliciete problemen automatisch blokkeert”, maar de resterende impliciete risico’s — standaardconfiguraties, permissiegrenzen, uitzonderingspaden verstopt in details — vergen menselijke blik. Deze laag is de basis, niet het eindpunt.

Laag 2 draait op een tijdschaal van uren tot dagen — voor hoog-risico wijzigingen (wijzigingen aan kernmodules, databaseschema’s, authenticatie-, facturatie- of compliance-onderdelen) is handmatige spot-controle verplicht, uitgevoerd door een klein panel van architecten, business owners en security leads. Een aanzienlijk deel van de door CodeRabbit gemeten 1,82–2,74× toename in beveiligingslekken en de 322% stijging in privilege-escalation-kwetsbaarheden van Apiiro wordt pas door deze laag boven water gehaald: door AI gegenereerde code oogt correct en draait, maar de standaardinstellingen, autorisatiegrenzen en foutafhandelingspaden schuilen in de details. Voor middellage en lage risico’s volstaat steekproefsgewijze controle (een steekproefpercentage van 20-30% wordt aanbevolen op basis van ervaring met interne klanten, niet als industriestandaard) — niet elke PR hoeft integraal te worden bekeken. Dit is het proces waarin menselijke capaciteit verschuift van “alles reviewen” naar “de kritieke punten eruit pikken”. Het grootste valkuil in deze laag is graduele erosie: teams verlagen stilletjes de drempel voor “hoog risico” om AI-PR’s sneller door te krijgen. Die versoepeling voelt even prettig, maar bij het eerste incident blijkt de prijs verpletterend.

Langzaam AI leren 174 — De oranje laag waar AI niet bij kan

Laag 3 draait op een tijdschaal van dagen tot weken. Het gaat om wijzigingen die de grenzen van compliance raken: regelgevende rapportages, data-export buiten de jurisdictie, SLA-impact en architectuurwijzigingen die meerdere teams raken. Denk aan het Change Advisory Board, dossierbeoordelingen voor algoritmen, beveiligingsaudits (vergelijkbaar met ISO 27001 of SOC 2) en overleg met toezichthouders. Dit is precies het oranje blok in de AI173-figuur waar AI “niet doorheen duwt” — voor sterk gereguleerde sectoren is dit de duurste kostenpost.

De inzet van AI174 is helder: AI kan Laag 3 niet overnemen, maar als Laag 1 en 2 goed werken, kan het overgrote deel van de laagrisico-wijzigingen worden onderschept voordat ze Laag 3 bereiken — op basis van klantdata uit interne trainingen schatten we zo’n 80–90%. Alleen de resterende 10–20% hoog-risico wijzigingen belanden bij het Change Advisory Board (CAB). Daarmee verschuift de bandbreedte van het Change Advisory Board (CAB) van “alle wijzigingen in het hele bedrijf” naar alleen de wijzigingen die daadwerkelijk governance nodig hebben. Kortere wachttijden bij het Change Advisory Board (CAB), een sneller overall-leveringsritme — dat is het “bandbreedte-dividend van governance” dat bij het upgraden van reviews het vaakst onderschat wordt.

De compliance-handtekening van Laag 3 moet op papier staan. Elke PR die via de Laag 3-router wordt getriggerd, vereist een volledige audittrail — PR diff, reviewopmerkingen, dubbele ondertekening door zowel de business owner als de compliance owner, tijdstempels en een bijlage met het modelverificatierapport. Bewaartermijn: in de financiële sector vijf jaar, in de telecom drie jaar (ter referentie: China’s GDPR + UAVG §55, deDNB 通知〔2020〕24通知 en de algoritme-registratieregels van het Ministerie van Industrie en Informatietechnologie). Voor toezichthouders is dit hard bewijs, geen papieren compliance.

Drie lagen op elkaar gestapeld: triggervoorwaarden gecodeerd door risiconiveau, niet door regels code of PR‑omvang

In de praktijk mag de risico‑inschatting nooit leunen op een zelfevaluatie door de AI — een model heeft geen gevoel voor compliance en merkt niet dat het raken van een klant‑ID‑nummer een rode lijn is onder de GDPR + UAVG (Personal Information Protection Law, China’s equivalent van de GDPR). De bepaling moet dubbel worden vastgeklonken: de PR‑auteur vinkt in de PR‑template handmatig aan of het schema, auth, billing of een compliance‑grens wordt geraakt, en daarnaast legt een CODEOWNERS‑regel een tweede check op. Op basis van die vinkjes routeert de PR naar de juiste laag:

Laag risico → Laag 1, automatische merge. Voorwaarde: het pad staat op de whitelist en er is een fout‑circuitonderbreker. Veroorzaakt één willekeurige automatische merge binnen 30 dagen een productie‑incident, dan wordt de automatische route meteen gepauzeerd en valt de volledige stroom terug op handmatige review.
Middelgroot risico → Laag 2, spot‑check.
Hoog risico → Laag 3, governance‑traject.

Deze “risico‑adaptieve routering” is de hoogste volwassenheidsvorm van PR‑escalatie.

IV. Toolkeuze voor code review: CodeRabbit is niet het enige antwoord, maar wél de feitelijke basislijn

We vouwen het drie‑lagenmodel nu terug naar de tooling. Dit deel beperkt zich tot de keuze voor Laag 1 — Laag 2 en 3 zijn vooral een kwestie van organisatie en proces; wat een tool daar nog aan toevoegt is gering.

CodeRabbit is de onbetwiste koploper in de AI-code-reviewcategorie op GitHub Marketplace (Series B van US$ 550 miljoen in september 2025, ARR van US$ 40M tegen Q2 2026, volgens Sacra) — de tool zet een “AI-reviewer” midden in de PR-commentaarstroom. Elke opmerking bevat klikbare uitleg, fix-suggesties en een ernstniveau, en blinkt uit bij het blootleggen van blinde vlekken in unit-testdekking. De integratie met GitHub Actions is het diepst van allemaal, de prijs is getrapt per aantal PR’s, en de enterprise-editie voegt private modellen, allowlists en een interne kennisbank toe. De gerapporteerde cijfers van 1,7× meer bugs en 1,82–2,74× meer security-lekken komen uit CodeRabbits eigen publicatie. De kern van de aanpak: een “AI-reviewer” die direct in de PR-stroom meepraat, met uitleg, suggesties en ernstniveau — bijzonder effectief waar unit-tests tekortschieten.

GitHub Copilot Review is alleen logisch als je al op GitHub Enterprise zit en geen nieuwe leverancier wilt toevoegen. De regels zijn niet diepgaand te tunen, en dat is een harde beperking: op termijn loopt de regelbibliotheek onvermijdelijk achter op die van CodeRabbit.

Sourcery is dé krachtigste automatische reviewer in de Python-wereld: hij geeft direct refactoring-suggesties tijdens de PR-fase (niet alleen fouten opsporen, maar ook herschrijven) en is bijzonder effectief voor het aanvullen van type-annotaties en het opruimen van technical debt. Voor cross-language teams schiet hij tekort — TypeScript en Go worden net ondersteund, andere talen zijn karig bedeeld.

Cursor BugBot is sterk doordat hij de gesprekscontext in de Cursor-editor kan zien: alles wat je met de AI bespreekt, neemt hij mee, zodat hij de gegenereerde code gericht kan reviewen. Projecten die niet in Cursor draaien, kunnen er geen gebruik van maken.

Antigravity Review is de ingebouwde reviewfunctie van Google’s Antigravity-platform (gelanceerd november 2025), gebaseerd op het Gemini 3-model en de enterprise-compliance-laag van Google Cloud. De iteraties verlopen in de eerste helft van 2026 nog in hoog tempo, de regelbibliotheek is minder diep dan die van CodeRabbit, en de prijs- en deploymentmodellen voor enterprise-klanten worden nog steeds bijgesteld.

Bij de selectie van tools hanteer ik deze volgorde van dimensies: aanpasbaarheid van regels > kwaliteit van PR-commentaar > diepte van integratie > prijs. Een Layer 1-tool die je langdurig gebruikt, mag je niet opzadelen met een vast intern veiligheidsmodel—als de regels niet aanpasbaar zijn, zit je vast. PR-commentaar van slechte kwaliteit (een AI-reviewer die alleen zegt “dit ziet er niet goed uit” zonder uitleg of suggestie) is pure tijdverspilling voor ontwikkelaars. De diepte van integratie bepaalt hoe snel je ermee aan de slag kunt; prijs staat pas op de vierde plaats, wat niet betekent dat het onbelangrijk is—binnen dezelfde categorie schommelen de prijzen met minder dan 30%, en de verschillen in de eerste drie dimensies zijn groter.

Twee vuistregels bij de selectie:

Eén: in de kerndomeinen van financiën, overheid, defensie en telecom is private deployment of self-hosting het toegangsbewijs. Maar private deployment is niet het eindpunt—een review-tool moet je volledige codebase zien (de PR-diff plus de repository-geschiedenis), wat neerkomt op het overdragen van code aan een derde partij voor verwerking. Dat vereist een overeenkomst voor gegevensverwerking door derden (GDPR + UAVG §21 数据委托处理, verwerking van persoonsgegevens in opdracht), conform China’s Personal Information Protection Law (GDPR + UAVG). Alleen technische isolatie is niet voldoende. Voor Europese context: vergelijkbare verplichtingen vloeien voort uit de AVG/GDPR, met name artikel 28 (verwerkersovereenkomst), en voor kritieke infrastructuur uit NIS2; in de VS gelden voor delen van deze sector SOC 2 en HIPAA.

Twee: AI pre-review en menselijke review zijn geen “of-of”-keuze. Combinaties zoals CodeRabbit + GitHub Copilot Review, twee Layer 1-tools naast elkaar, zijn in grote organisaties de normaalste zaak van de wereld. Hun regelsystemen verschillen en de typen kwetsbaarheden die ze dekken, vullen elkaar aan; één enkele tool houdt altijd blinde vlekken.

Vijf. Implementatie in vier sectoren: hoe review-upgrades er per regelgevende context uitzien

Telecommunicatie — Upgraden van het reviewproces bij tarief- en facturatiewijzigingen. In een interne AI-retrospectief van een regionale operator kreeg ik een schema te zien: elke tariefwijziging moet elf checkpoints doorlopen van ontwikkeling tot productie. AI wist de programmeerfase van twee dagen terug te brengen tot een halve dag, maar de overige vijf stappen — de Change Advisory Board (Change Advisory Board (CAB)), algoritmeregistratie (verplicht voor facturatiemodellen), een Gelijkewaardigebeschermingstoets, data-export naar het buitenland (omdat er een niet-Chinese modelleverancier wordt gebruikt, verloopt die via de afzonderlijke negatieve lijst voor export uit de telecom- en IT-sector onder de Provisional Measures for Data Security in Industry and Information Technology; een standaard GDPR + UAVG-contract volstaat hier niet), en reconciliatie-audits — kosten elk dagen tot een maand. De algoritmeregistratie alleen al: van voorbereiding van de aanvraag tot reactie van het Ministerie van Industrie en Informatietechnologie (MIIT) duurt doorgaans vier tot zes maanden. Dat is de echte bottleneck. De totale doorlooptijd bewoog daardoor nauwelijks.

De richting voor de upgrade van het reviewproces is als volgt: de Layer 1-tool moet automatisch herkennen wanneer een wijziging raakt aan facturatie-, authenticatie- of compliancemodules, het risiconiveau omhoog schalen en de wijziging routeren naar een gezamenlijke goedkeuring van de business owner én de compliance owner (Layer 2). De Change Advisory Board (CAB) doet alleen nog een tweede review op wijzigingen die daadwerkelijk raken aan verplichte regulatorrapportages. De essentie van deze aanpak is dat de Change Advisory Board (CAB)-bandbreedte wordt teruggebracht van 5.000–8.000 wijzigingen per maand (alle wijzigingen, inclusief hotfixes) naar 100–200 wijzigingen per maand die werkelijk governance vereisen. Vóór de upgrade lag de bottleneck bij de Change Advisory Board (CAB); erna wordt de Change Advisory Board (CAB) juist de snelste schakel, omdat acht van de elf voorgaande stappen nu geautomatiseerd of via regelgebaseerde pre-checks worden afgehandeld.

Learn AI Slowly 199 — Modeluitleg is de echte blinde vlek in telecom

De meest onderschatte pijnpunt in telecom is niet het Change Advisory Board — het is modeluitleg (explainability). Billingmodellen moeten voor elk bedrag op de factuur kunnen aantonen welk tarief is toegepast, en zodra een AI-blackbox-model live staat, moet je bij klantklachten direct kunnen terugtraceren. De top drie onderwerpen bij ACM 利用者申立-consumentenklachten (nummerportering, factuurtransparantie en beheer van dienstonderbrekingen) vereisen een voorafgaande consumer protection review op groepsniveau vóór elke productlaunch. Geen Change Advisory Board (CAB) die dat vervangt.

Wat dit in de praktijk betekent

Billingdispuut bij een regionale carrier (China Mobile): een blackbox-model voor tiered billing classificeerde een klant onterecht in een duurder segment. Bij de klacht kon niemand uitleggen waarom. De casus escaleerde naar ACM 利用者申立 en werd uiteindelijk teruggetrokken na handmatige herberekening — met reputatieschade en een formele waarschuwing van de toezichthouder als gevolg.
Nummerportering in de EU (Deutsche Telekom / Telefónica): onder de Europese telecode (EU 2020/1070) heeft een klant recht op een heldere uitleg binnen een vastgestelde termijn. Een CoT-trace van het besluit (“waarom deze portering is vertraagd of geweigerd”) is geen luxe-artikel maar een harde compliance-eis.
Dienstonderbreking bij NTT / KDDI: na de grote storing bij KDDI in 2022 bleek dat geautomatiseerde rollback-beslissingen ondoorzichtig waren. Een vastgelegd CoT-pad had het forensisch onderzoek met weken kunnen verkorten.

Waarom een Change Advisory Board (CAB) hier niet volstaat

Een Change Advisory Board toetst of je iets mag releasen. Modeluitleg toetst waarom het model iets besliste. Dat zijn verschillende vragen, met verschillende eigenaren, en verschillende artefacten in het dossier. In de praktijk zie ik bij CIO’s van carriers (ETSI / GSMA-regio) dat deze twee stromen naast elkaar blijven lopen zonder dat iemand de brug slaat — tot de eerste ACM 利用者申立- of BEREC-escalatie.

Praktisch advies voor telecom-CIO’s

Eis per release een CoT-trace voor elk billing-, portering- en suspend/resume-besluit, opgeslagen in een auditeerbaar log (WORM-storage, minimaal 5 jaar conform de EU-retentieregels).
Splits de risk owner (Change Advisory Board (CAB)) van de explainability owner (een nieuwe rol, vergelijkbaar met een Model Risk Owner onder DORA / SR 11-7).
Koppel het AI-besluit aan de customer-facing rationale — één pipeline, twee uitgangen: intern (audit) en extern (klant).

Kort gezegd: in telecom is uitlegbaarheid geen “nice to have” voor je AI-governance. Het is de facto een tweede Change Advisory Board (CAB), maar dan op beslisniveau.

Financiën — upgraden van de modelbeoordeling voor kredietrisicobeheer. In de kernsystemen van banken volgt de livegang van een risicomodel een strikt sequentieel pad: onafhankelijke validatie door de Modelvalidatie-eenheid (MVE) (Model Validation Unit) → goedkeuring door het Model Risk Comité → aanvraag van wettelijke registratie door de business → feedback van de toezichthouder → livegang pas na goedkeuring van de registratie. Deze vijf stappen kennen een vaste volgorde en kunnen niet parallel worden behandeld. AI-gestuurde codering kan het proces hier maar op een smal front versnellen (scriptgeneratie, code voor feature engineering, preprocessing-code), maar élke wijziging raakt aan de regelgevende grenzen — het aanpassen van labels valt bijvoorbeeld onder “een belangrijke modelwijziging vereist een nieuwe registratie” zoals vastgelegd in artikel 24 van de Commercial Bank Internet Loan Management Measures (《商业银行互联网贷款管理办法》) en in het CBIRC-document 2020 nr. 24. De gewenste beoordelingsupgrade ziet er als volgt uit: Layer 1 moet “wijzigingen in features, labels, drempelwaarden of modelgewichten” herkennen en deze forceren naar een hoog-risico route; Layer 2 vereist een dubbele handtekening van een kredietrisico-business lead én een data compliance lead, waarbij de Modelvalidatie-eenheid (MVE) onafhankelijk moet opereren van zowel de business als IT (harde eis in CBIRC-document 2020 nr. 24); Layer 3 doorloopt modelvalidatie, DNB 規制データ報告-rapportage, DNB 規制データ報告-rapportage, een GDPR + UAVG-toets (《个人信息保护法》, China’s Personal Information Protection Law) en een algoritmische fairness-review (variabelen als geslacht, leeftijd en regio zijn niet toegestaan).

Een pijnlijk voorbeeld uit de praktijk: een joint-stock bank rolde een AI-feature-engineeringtool uit en zag de doorlooptijd van modelvalidatie oplopen van 8 naar 12 weken. De Model Validation Unit (Modelvalidatie-eenheid (MVE)) moet elke door AI gegenereerde feature afzonderlijk controleren op PSI- en CSI-drift, en de samenwerking tussen Modelvalidatie-eenheid (MVE) en de data-compliance-afdeling verloopt stroef. De Modelvalidatie-eenheid (MVE) heeft de oorspronkelijke feature-distributies nodig, maar onder de GDPR + UAVG (Personal Information Protection Law) mag compliance de Modelvalidatie-eenheid (MVE) geen klantniveau-data laten inzien — alles moet via een smal pad van een model-validatiesandbox en geanonimiseerde geaggregeerde features lopen. Zorg eerst dat Layer 2 op orde is, praat dan pas over tooling. Hoe krachtig de tool ook is, zonder mensen die zowel de business als de regelgeving snappen om steekproefsgewijs te controleren, blijft escalatie naar een hoger reviewniveau een luchtkasteel.

Manufacturing — MES-proceswijzigingen verdienen een strenger reviewproces. De belofte van AI-gegenereerde code in de productie is groot (lijnintegratie, kwaliteitsinspectiemodellen, procesplanning), maar aanpassingen aan een MES raken al snel aan veiligheidsinterlocks. Eén gewijzigde procesparameter kan een complete productielijn platleggen. De productie-know-how gaat veel dieper dan het oppervlak suggereert: wijzigingen aan OEE (Algehele ApparatuurEffectiviteit)-interlocks (Overall Equipment Effectiveness), SPC (Statistische Procesbeheersing)-controlekaarten (Statistical Process Control), partijtracering, of terugstort- en bijstortlogistiek zijn allemaal hoog risico, en niet zomaar te beoordelen op basis van een “procesthreshold”. De aanpak voor een strenger reviewproces: in laag 1 moet elke wijziging die raakt aan veiligheidsinterlocks, OEE (Algehele ApparatuurEffectiviteit), SPC (Statistische Procesbeheersing) of partijtracering als hoogste risico worden gemarkeerd, en mag nooit automatisch worden samengevoegd; in laag 2 is een dubbele goedkeuring vereist van zowel een procestechnoloog als een safety engineer; in laag 3 volgt een pilot op één productielijn met kleine volumes voordat wordt opgeschaald, om te controleren op ongewenste neveneffecten op de veiligheidsinterlocks. De echte flessenhals in deze sector zit bij laag 2: ervaren procestechnologen zijn schaars, en hun agenda wordt opgeslokt door de dagelijkse productie. Een strenger reviewproces is in wezen een herallocatie van aandacht: van routinecontroles naar grondige beoordeling van de meest risicovolle PR’s.

E-commerce — upgrades in code review voor piekpromoties. In e-commerce levert AI-gebaseerd coderen de grootste productiviteitswinst op (frontendpagina’s, campagneregels, dashboards, aanbevelingslogica), maar codewijzigingen tijdens grote acties raken direct de transactie-, risico- en financiële reconciliatieketen — één fout kan al snel meer dan honderd miljoen euro schade veroorzaken. De aanpak voor review-upgrades: in Layer 1 moet alles wat raakt aan promotiemodules, coupons, flash sales of voorraad als hoogste risico worden gemarkeerd; Layer 2 vereist een dubbele goedkeuring van zowel de business owner als de risk owner; Layer 3 hanteert canary-releases plus end-to-end loadtests. Wat e-commerce bijzonder maakt, is het vensterkarakter van die piekperiodes: in de twee weken rondom de grootste acties van het jaar zijn de reviewstandaarden strenger dan normaal, terwijl de reviewcapaciteit juist het minst beschikbaar is door productiedruk. De bewezen aanpak in deze sector is “normaal soepel, in oorlogstijd streng”: een week vóór het piekvenster worden alle hoog-risico wijzigingen volledig gelockt en alleen bugfixes doorgelaten; de vrijgekomen reviewcapaciteit gaat vervolgens naar de opgebouwde backlog, zodat geen hoog-risico wijzigingen het piekvenster binnensluipen.

Zes. Lessen voor besluitvormers

Omgekeerde zelfdiagnose — stijgt of daalt het vertrouwen van je team in AI-output? Hoe wordt je AI-PR (persbericht, publicatie, etc.) gereviewd: 100% handmatige controle, steekproeven op basis van risico, of stiekem doorgelaten? Hoe vaak heeft je Layer 3-router de afgelopen zes maanden geactiveerd, hoeveel keer heeft dat problemen opgeleverd, en hoe vaak zijn er daadwerkelijk incidenten ontdekt? Als je bestuur deze drie cijfers niet kan opvragen, is je governance niet meer dan een wassen neepapier.

Vier sectoren bekeken, en het patroon is duidelijk: het opwaarderen van reviews draait niet om het kopen van tooling, maar om het herontwerpen van risicorouting. De Layer 2/3-routeringsvoorwaarden verschillen per sector (telecom: Change Advisory Board + algoritmeregistratie + modelverklaarbaarheid; financiële sector: onafhankelijke Model Validation Unit + modelverificatie + DNB 規制データ報告 + algoritmische fairness; maakindustrie: proefrun + canary release + OEE (Algehele ApparatuurEffectiviteit)/SPC (Statistische Procesbeheersing); e-commerce: piekverkeers-lock), maar de logica van de Layer 1-tooling is universeel: “herken hoog risico, label automatisch, routeer verplicht.” Eén of twee Layer 1-tools die je sectoroverschrijdend inzet, is prima; de processen eromheen moet je per sector opnieuw ontwerpen.

Inzicht één: het opwaarderen van code review is een upgrade van organisatievermogen, geen technische aanschaf. CodeRabbit Pro kost $24 per seat per maand (Pro Plus $48 per seat per maand, gefactureerd per ontwikkelaar die PRs aanmaakt); voor een team van 200 mensen komt dat neer op circa $58k per jaar, en een enterprise-licentie is daar nog eens drie tot vijf keer bovenop. Vergeleken met een R&D-budget van miljoenen is dat een fractie. Wat het echt kost, zit in het compleet maken van Laag 2 (menselijke capaciteit) en het herontwerpen van de processen in Laag 3. Dat koop je niet met budget; daarvoor moet een organisatie bereid zijn zich aan te passen, en moeten senior engineers bereid zijn tijd vrij te maken voor reviewwerk. Mensen die de review-upgrade niet van de grond krijgen, benaderen het vrijwel altijd als een IT-project: licentie aanschaffen, tool uitrollen, KPI’s vaststellen. Wie het wél voor elkaar krijgt, haalt de R&D-lead en de compliance-verantwoordelijke aan dezelfde tafel om samen de PR-routeringsregels te definiëren. Dit is een budgetsignaal dat governance verschuift van kostenpost naar bandbreedte-asset — en alleen dan vloeit het budget van “nog meer licenties kopen” naar “reviewbandbreedte bijplussen”.

Les twee: vóór je autonome agents inzet, moet AI pre-review eerst op orde zijn. Dit is de andere kant van “remmen monteren vóór de motor”: autonome agents (zoals Claude Code, Codex) kunnen in één keer een dozijn bestanden aanpassen, een PR indienen en shell-commando’s draaien. Voordat die mogelijkheden live gaan, moet Layer 1 kunnen herkennen “welke module wordt geraakt, welke grens wordt overschreden” en het werk verplicht routeren naar de juiste laag. Als kwantitatieve maatstaf voor “op orde” geldt: Layer 1 automatische merge-doorlooptijd ≥ 95 %, Layer 2 steekproefdekking ≥ 20 %, en drie opeenvolgende maanden zonder P0-incidenten. Het voorbeeld van Carlini’s 100.000-regelige Rust-gebaseerde C-compiler is dichterbij dan je denkt — een autonome agent kan in twee weken een productierijp project opleveren, maar kan in een organisatie zonder review in twee weken ook 20.000 productierijpe risico’s opstapelen. Een beter vergelijkbaar branchevoorbeeld is de agent “Minions” van Stripe: circa 1.300 PR’s per week, volledig door AI geschreven code, uitsluitend menselijke review — dat is het kenmerk van dit model: AI produceert volledig automatisch, mensen kijken alleen mee. Dát is hoe een volwassen review-laag eruitziet.

Inzicht 3: zowel de “winst” als het “verlies” van review-upgrades moet je afzetten tegen de beschikbare bandbreedte. Laten we “reviewbandbreedte” opnieuw definiëren — het gaat niet alleen om de manuren aan de reviewtafel, maar om de totale organisatorische capaciteit om risico’s te herkennen, te routeren en af te handelen. In de rapportage van CodeRabbit betekent “de meeste zichtbare problemen automatisch tegenhouden” maar een deel van het verhaal; of je AI echt goed benut, hangt af van de vraag of de overgebleven impliciete risico’s (architectuuraansluiting, compliance-grenzen, businesscorrectheid) in Layer 2/3 voldoende menselijke aandacht krijgen.

De meest voorkomende valkuil bij review-upgrades is het automatisch laten mergen van AI-PR’s: om “de productiviteitswinst van AI beter te laten ogen” worden de regels van Layer 1 stilletjes versoepeld, Layer 2 teruggebracht tot een steekproef van 5%, en functioneert Layer 3 nog nauwelijks. De cijfers zien er op korte termijn mooi uit, maar het incidentpercentage stijgt op de lange termijn — AI schrijft snel + versoepelde review = schuld groeit evenredig. Het dubbele waarschuwingssignaal van CodeRabbit (1,7× meer defects) en Apiiro (322% meer privilege-escalaties) is de integrale prijs van dat soort versoepelingen, niet het falen van één specifieke plek. Reviewbandbreedte moet gelijke tred houden met het PR-volume; zodra de verhouding scheefloopt, verlies je de controle.

30-dagenimplementatiechecklist（met voldoende detail om te bepalen welke vergadering er maandag plaatsvindt en welk document wordt aangepast）：

Week 1: Breng de bestaande PR-routeringsregels in kaart en markeer wijzigingen aan de hand van vier categorieën: “schema/auth/billing/compliance”. Stel de baseline vast met het aantal Layer 3-triggers en de gemiddelde wachttijd in de wachtrij van de afgelopen 90 dagen.
Week 2: Kies één Layer 1-tool — CodeRabbit of GitHub Copilot Review — en selecteer op basis van de harde eis van “private deployment”. Configureer de regels en voeg aan het PR-sjabloon een handmatig in te vullen risiconiveau toe.
Week 3: Stel een lijst samen met de business owners en compliance-owners voor Layer 2, bepaal het steekproefpercentage voor spotchecks (advies: 20–30%) en vul het CODEOWNERS-bestand volledig in met de owner van elke module.
Week 4: Neem deze vijf KPI’s op in de wekelijkse PMO-rapportage: gemiddelde beoordelingstijd van PR’s, change failure rate, percentage gemiste defects na beoordeling, gemiddelde wachttijd in de wachtrij voor Layer 2/3 en aantal compliance-incidenten als gevolg van Layer 3-routeringstriggers. Stel daarnaast als toelatingscriteria voor autonome agents vast: een Layer 1-goedkeuringspercentage van ≥95%, een Layer 2-steekproefdekking van ≥20% en nul P0-incidenten gedurende drie opeenvolgende maanden.

Bijpassende metrics

Gemiddelde PR-reviewtijd, wijzigingsfoutenpercentage, aantal defecten dat door reviews glipt, gemiddelde wachttijd in Layer 2/3, aantal compliance-incidenten getriggerd door Layer 3-routing, en wachttijd voor modelverificatie. Aan het einde van AI173 stond al de observatie dat veel grote ondernemingen aan de top rapporteren over “AI-coding ROI” in termen van “hoeveel ontwikkelaars we bereiken” en “hoeveel seats we hebben gekocht” — precies de cijfers die de echte knelpunten verbergen. Als je deze指标 naar de board brengt — in plaats van seat counts en regels code — verschuift het budget van “nog meer licenties kopen” naar “reviewcapaciteit uitbreiden”.

Schaduw-AI in het gareel

Ook het beheer van schaduw-AI moet gelijke tred houden. Het 2025-rapport van UpGuard hanteert de definitie “wereldwijd gebruik van niet-goedgekeurde generatieve AI-tools door medewerkers” — en dat gaat verder dan alleen developers. Zo’n 80% van de medewerkers geeft toe AI-tools te gebruiken die niet door IT zijn goedgekeurd. Businessunits die ChatGPT inzetten om code te schrijven, IT volledig passerend — dat is op dit moment de grootste hoofdpijn voor compliance-verantwoordelijken. Volwassen governance zonder schaduw-AI-beleid is als het beheren van enkel de “aangemelde wapens”, terwijl de “niet-aangemelde wapens” buiten beeld blijven.

Niet van toepassing: als je team kleiner is dan 50 mensen, niet in een sterk gereguleerde sector zit, geen autonome agents gebruikt en minder dan 100 PR’s per maand verwerkt, geldt minstens 60% van de adviezen in dit artikel niet direct voor jou — ga dan niet het hele raamwerk afwerken, maar volstaat Layer 1 tooling plus gerichte spot-checks.

Volgende stap

Het volgende artikel (AI175) behandelt de toolinglaag: de strijd om AI-tools is in 2026 beslecht, maar of de winnaars ook echt bruikbaar zijn, is een tweede vraag. Het gaat om de twee kemphanen op de troon (Claude Code / Codex), om Copilot dat op zijn inkoopmomentum drijft, en om Antigravity dat nog maar net van start is — en om hoe “governance bepaalt wie wat mag gebruiken, en op welk niveau.” AI175 levert de structuur voor toolselectie; AI174 levert die voor review-upgrades. Samen geven ze je het totaalplaatje van “wat doet een organisatie zodra AI code schrijft.”

Na dit artikel kun je het best doorgaan met AI173 sectie 3 (de nieuwe knelpunten) en AI175 sectie X (de koppeling tussen governance- en toolkeuzes) — de drie kerninzichten zijn over die drie stukken verspreid.

Deze inzichten toepassen in jouw organisatie?

Leerzaam AI <001>

Zodra AI-codingtools de onderneming binnenkomen, draait het in de praktijk om een paar heel concrete vragen: kan de bestaande code review-flow het volume van AI-output überhaupt aan? Hoeveel moet de tweede laag (Layer 2) bemenst worden — uitgedrukt in PR-volume, aantal modules of FTE-aandeel? Moet het Change Advisory Board (CAB)- en registratiemechanisme in de derde laag (Layer 3) op de schop? En welke acceptatiecriteria hanteer je voor de pilot?

Diagnostische ingang: begin met vijf cijfers uit je eigen team — gemiddelde doorlooptijd van een PR-review, failure rate van wijzigingen, defecten die door de review glippen, gemiddelde wachttijd in Layer 2/3, en het aantal compliance-events dat door Layer 3-routing wordt getriggerd. Als je een van die cijfers niet tevoorschijn kunt toveren, ben je nog niet klaar voor een AI pre-review-tool.

Op dit moment bieden wij drie samenwerkingsvormen:

Bedrijfstraining (Enterprise training): aan de hand van echte projecten uit jullie codebase werken we de落地 van het drielagenmodel voor AI-review uit. Daarbij behandelen we de selectie van een Layer 1-tool (zoals CodeRabbit of GitHub Copilot Review — beoordeeld op vier dimensies: private deployment, aanpasbaarheid van regels, integratiediepte en prijs), het herontwerp van de Layer 2/3-processen en de bijbehorende meetinstrumenten. De deliverables: ① een score van de huidige teamsituatie (verzadiging van reviewbandbreedte), ② een落地路线图 voor het drielagenmodel (3–6 maanden), ③ een beslisboom voor Layer 1-toolselectie, en ④ een eerste opzet van een metendashboard. Doorlooptijd: 3 dagen, circa ¥90.000.

Advies op maat: gericht op één concrete beslissing — bijvoorbeeld de evaluatie van de invoering van CodeRabbit, hoe een drie-lagen reviewmodel in een sterk gereguleerde omgeving landt (financiële sector: onafhankelijke Modelvalidatie-eenheid (MVE) + auditeerbare trace / telecom: algoritmeregister + ACM 利用者申立-klachtenroute), of hoe de huidige Change Advisory Board-cyclus opnieuw kan worden ingericht om AI-PR’s te routeren. Prijs per beslissingsvraag (adviesblokken van 5–15 uur), oplevering = besluitnotulen + implementatiechecklist + 1 week follow-up. ¥5K/uur.

1-op-1 coaching / private advisory board: voor VP’s, directeuren en senior engineers die “bereid zijn om serieus te investeren in hun groei” — u werkt al met AI-coding-tools en wilt het reviewframework, teamgovernance en de politiek tussen afdelingen zelf in uw eigen organisatie laten landen. 12 sessies / 6 maanden, prijs per thema, oplevering = coachingsnotulen + periodieke actie-evaluatie. ¥180K–360K.

Lezingen voor het management & keynotes in de branche: rond AI-review, organisatiegovernance, enterprise-AI-transformatie en de modernisering van software engineering. Halve dag / hele dag, afgestemd op de wensen van de organisator.

De artikelen bieden een algemeen kader. Concrete implementatie vraagt om een herontwerp op basis van de data-grenzen, toezichtsvereisten, engineering-volwassenheid en bestaande reviewprocessen van uw organisatie. Samenwerking kan worden aangevraagd via coach@iaiuse.com.

Verder lezen: “Jian Zhao Paai Methodologie v1.0” (慢慢学 AI 187), een systematische uiteenzetting van het 7-stappen framework voor AI-transformatie in het bedrijfsleven.

Over deze reeks

“Software-engineering in het AI-tijdperk” is een onderzoeksreeks gericht op CIO’s, CDO’s, CTO’s en digitaliseringsverantwoordelijken in telecom, financiële dienstverlening, maakindustrie en e-commerce. De reeks onderzoekt hoe AI-gestuurde programmeertools de softwarelevering, organisatiestructuur, governance en managementmetrieken beïnvloeden.

Achter dit kanaal schuilt een klein team — ikzelf en één of twee collega’s met wie ik al lange tijd samenwerk. We verdelen het werk: onderzoek naar AI-programmeertools, het uitpluizen van casuïstiek rond organisatie-governance, en coachingsgesprekken. De meeste projecten waarover we schrijven als “begeleid door ons”, hebben we gezamenlijk opgeleverd.

De reeks volgt continu academische papers, vendor-materiaal en brancherapporten. De onderzoeksdatabase telt inmiddels meer dan 200 stukken, waarbij we per kernclaim een bewijsniveau aangeven en zoveel mogelijk onderscheid maken tussen geverifieerde feiten, vendor-claims, branchebevindingen en eigen redeneringen.

Ik heb bijna 8 jaar ervaring in consulting en business-analyse voor grote ondernemingen, ben begonnen bij IBM en heb daar gewerkt aan projecten in telecom, verzekeringen en de maakindustrie. Daarna ben ik doorgegaan in de frontlinie van operatorproducten, internetproducten en AI-applicatieontwikkeling, met focus op requirements-analyse, productdesign en cross-functionele implementatie.

Referenties (per bron: herkomst + bewijsniveau + standpuntmarkering)

CodeRabbit State of AI vs Human Code Generation Report (17 dec 2025, eerstehands, standpunt van de leverancier): analyse van 470 open-source GitHub-PR’s (AI vs. menselijk, niet gekoppeld op bestandsgrootte/complexiteit). Totaal aantal defects 1,7× (gemiddeld 10,83 vs. 6,45 per PR); beveiligingslekken per subcategorie 1,57–2,74× — XSS 2,74×, onjuiste wachtwoordverwerking 1,88×, onveilige directe objectreferenties 1,91×, onveilige deserialisatie 1,82×; logic/correctness 1,75× (hoog 75%), code quality 1,64×, performance 1,42×, readability 3×+, formatting 2,66×, error handling ~2×, excessive I/O ~8×. Eigen onderzoek van CodeRabbit, standpunt van de leverancier, steekproef en methodologie zijn openbaar. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register, 17 dec 2025.
Apiiro 2025.9.4 (leverancierspositie): Repo-scans bij Fortune 50-bedrijven (dataperiode dec 2024 – jun 2025). Het aantal maandelijkse securitybevindingen in door AI gegenereerde code schoot omhoog van circa 1.000 naar ruim 10.000 (10× in absolute aantallen), met +322% op kwetsbaarheden die tot privilege-escalatie leiden (absolute aantallen) en +153% op ontwerpdefecten in de architectuurlaag; gecorrigeerd voor de toegenomen codevolumes komt de geschatte stijging uit op circa 60–80%. Syntaxisfouten daalden met 76%, logische bugs met 60%. Gerapporteerd door The Register, Cloud Security Alliance Labs en SiliconANGLE.
JetBrains AI Pulse Survey 2026.1 (eerste rang): 10.000+ professionele ontwikkelaars, 8 talen. 90% van de ontwikkelaars gebruikt minstens één AI-tool; 70% gebruikt er twee tot vier. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
Pragmatic Engineer Newsletter (feb. 2026, eerstehands): circa 906 respondenten, bereik van 150.000 lezers; 56% van de senior engineers zegt dat 70%+ van hun engineering-werk afhankelijk is van AI-tools (zelfrapportage van intensief gebruik, niet het aandeel coderegels); Claude Code is favoriet bij 46% (vs. Cursor 19%, Copilot 9%); bij bedrijven met minder dan 10.000 medewerkers kiest 75% Claude Code, bij bedrijven met meer dan 10.000 medewerkers kiest 56% Copilot. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (primair): Het Octoverse 2025-rapport meldt dat de Copilot coding agent in de vijf maanden tussen mei en september 2025 meer dan 1 miljoen PR’s heeft geauthored; van nieuwe ontwikkelaars gebruikt 80% Copilot binnen de eerste week. “De 40-60% PR-participatiegraad” betreft een brancheschatting, niet directe Octoverse-data. GitHub Engineering Blog, The New Stack.
Stripe Minions (2026.3, firsthand): De agents van Stripe, “Minions”, voegen wekelijks ongeveer 1.300 pull requests samen, zonder dat er code door mensen wordt geschreven (alleen menselijke review) — de kenmerken van dit model zijn volledig geautomatiseerde AI-output en een uitsluitend door mensen uitgevoerde review. 500+ MCP-tools, AWS EC2 DevBox en de branchstrategie van Block Goose. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / InfoQ, 20 maart 2026.
Anthropic Skills-systeem (jan. 2026, primaire bron, standpunt van de leverancier): Anthropic heeft het ontwerpdocument voor Skills openbaar gemaakt — de kern is modularisatie van taakcapaciteiten (modular folders that teach Claude specific tasks, opgebouwd volgens skill-bestanden + progressive context loading), en heeft niets te maken met PR-routing. De in de praktijk veel gebruikelijkere risicogebaseerde PR-routing wordt afgehandeld door de branch protection + CODEOWNERS-regels van GitHub/GitLab, die PR’s routeren op basis van pad en Codeowner. Bron: Anthropic Engineering Blog.
Carlini / Anthropic (jan.–feb. 2026, tier 1, primair onderzoek): Nicholas Carlini, onderzoeker bij Anthropic, liet 16 Claude Opus 4.6-agenten twee weken lang parallel draaien — goed voor circa 2.000 sessies en ongeveer $20.000 aan API-kosten — om volledig vanaf nul een 100.000 regels tellende Rust-gebaseerde C-compiler te schrijven die Linux 6.9 compileert (x86/ARM/RISC-V) en 99% van de GCC torture-tests doorstaat. Het betreft afgesloten domeinonderzoek dat niet naar productie is gebracht en geen review-mechanisme bevat. Verslaggeving door The Register (9 feb. 2026) en Ars Technica (feb. 2026).
METR 2026.2 vervolgonderzoek (eerste niveau, te verifiëren): een vroeg onderzoek onder 16 senior ontwikkelaars, 246 echte taken, met Cursor Pro + Claude 3.5/3.7 Sonnet, liet zien dat AI het werk 19% vertraagde (95% BI 2%–39%), terwijl de deelnemers zelf dachten dat ze 20% sneller waren gingen werken. Het vervolgonderzoek van 2026.2 laat een tegenstrijdig beeld zien (nieuwe deelnemers –4%, bij een deel van de senior ontwikkelaars een omgekeerd resultaat). De precieze duiding moet nog worden geverifieerd aan de hand van het oorspronkelijke METR-rapport. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / EY-case (firsthand, standpunt van de leverancier): EY rolde Microsoft 365 Copilot uit naar 150.000 medewerkers, met een productiviteitsstijging van 15% (omgerekend 14 uur per persoon per week, ingezet voor klantlevering en learning); de uitrol wordt vervolgens uitgebreid naar meer dan 400.000 medewerkers. In een financiële operations-scenario, gebouwd op Microsoft Power Platform + Copilot Studio, daalde de end-to-end lead time met 95% en de operationele kosten met 37% (alleen voor dit financiële operations-scenario, niet representatief voor de hele onderneming). Bron: Microsoft Customer Story 25760 / FY26 investorpagina.
Atos Agent 365-implementatie (juni 2026, primaire bron, standpunt van de leverancier): Atos heeft Microsoft 365 Copilot uitgerold onder 56.000 medewerkers in 54 landen en beheert 19.000 interne AI-agents via Agent 365. Volgens Atos zijn governance en beveiliging “de eerste horde voor agentic AI”. Microsoft News, 9 juni 2026 / CDO Magazine.
Autonome agentcapaciteiten van Anthropic Claude Code en OpenAI Codex (primaire bronnen, standpunten van de leveranciers): Claude Code kan zelfstandig wijzigingen aanbrengen in meer dan tien bestanden, shells uitvoeren, Git beheren en pull-aanvragen indienen. Codex kan meerdere subagents parallel laten werken in geïsoleerde kopieën en de resultaten vervolgens samenvoegen. Technische documentatie van Anthropic en OpenAI.
CodeRabbit bedrijfsfundamenten (2025–2026, tier 1): marktleider in de bovenste segmenten van AI-reviewtools op GitHub Marketplace; Series B-waardering van circa USD 550 miljoen in september 2025; ARR groeide in 2025–2026 bijna 10× naar circa USD 40 miljoen (Q2 2026, Sacra-data); Pro USD 24 per seat per maand, Pro Plus USD 48 per seat per maand (berekend op basis van ontwikkelaars die PR’s aanmaken). Multi-source: Sacra / Reuters / TechCrunch. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (first-party, leveranciersperspectief): officiële documentatie en productpagina’s van elke Layer 1-reviewtool, met vergelijkbare dekkingsdimensies, aanpasbare regels en integratiediepte. Antigravity GA op 18 november 2025, gerapporteerd door VentureBeat en PCMag.
Oorsprong van code review (primair): twee belangrijke bronstromen — ① Weinberg publiceerde in 1971 The Psychology of Computer Programming en introduceerde daar egoless programming (de auteur werkte zelf bij NASA Goddard Space Flight Center en gaf les aan de University of Nebraska; geen IBM-achtergrond); ② IBM Fagan Inspections, in 1976 systematisch uitgewerkt door Michael Fagan bij IBM (Fagan zelf was IBM-medewerker). Deze twee tradities zijn parallel geëvolueerd. Dit vormt het historische referentiekader wanneer we AI-gedreven review naast traditionele review plaatsen.
Financiële regelgeving als referentiepunt (primair): Artikel 24 van de Administrative Measures for Internet Loans by Commercial Banks (《商业银行互联网贷款管理办法》) en document 〔2020〕24 van de China Banking and Insurance Regulatory Commission (CBIRC), Risk Management of Internet Loan Business by Commercial Banks — model governance via drie verdedigingslinies (business, IT, compliance/audit), een onafhankelijke Model Validation Unit (Modelvalidatie-eenheid (MVE)), en herregistratie vereist bij materiele modelwijzigingen; DNB 規制データ報告 (Examination and Analysis System) wordt maandelijks gerapporteerd in batches, plus DNB 規制データ報告-verplichte rapportages; daarnaast toezicht door de People’s Bank of China op individuele kredietregistratie en een verplichte algoritmische-fairnessbeoordeling (variabelen zoals geslacht, leeftijd en geografische herkomst zijn aan beperkingen onderhevig).
Telecommunicatietoezicht — primair bronmateriaal: algoritmeregistratieprocedure van het Ministerie van Industrie en Informatietechnologie (dubbele toetsing voor tariferings- en financiële algoritmen); MLPS-beoordeling (Multi-Level Protection Scheme, 等级保护测评) — niveau 2: 30 werkdagen, niveau 3: 45 werkdagen; top 3 klachten bij ACM 利用者申立 (nummerportering, factuurbereikbaarheid, beheer van dienstonderbrekingen); negatieve lijst voor grensoverschrijdende datadoorvoer uit de Provisional Measures for Data Security Management in Industry and Information Technology.
GDPR + UAVG — uitbestede verwerking van persoonsgegevens (primair): artikel 21 juncto artikel 55 van de Wet Bescherming Persoonsgegevens (GDPR + UAVG) — verwerkersovereenkomst met derden + bewaartermijn voor de logboeken 3–5 jaar (afhankelijk van de sector).
Stack Overflow Developer Survey 2025 (primair): enquête onder 49.000+ ontwikkelaars. Het percentage ontwikkelaars dat de nauwkeurigheid van AI-output vertrouwt daalde van 40% in 2024 naar 29% in 2025 (–11 procentpunten); tegelijkertijd wantrouwt 46% van de ontwikkelaars AI-output actief (tegen 31% in 2024). De code churn steeg van 3,1% in 2020 naar 5,7% in 2024. https://survey.stackoverflow.co/2025/
Schaduw-AI (UpGuard 2025, niveau 2): 80% van alle werknemers wereldwijd gebruikt niet-goedgekeurde generatieve AI-tools (niet alleen ontwikkelaars), en 68% van de beveiligingsverantwoordelijken geeft toe dat er sprake is van ongeautoriseerde AI. Het opschalen van governance zonder gelijktijdige aanpak van schaduw-AI vormt een blinde vlek voor compliance. https://www.upguard.com/resources/the-state-of-shadow-ai
Eigen cases van de auteur (geanonimiseerd): ① AI-internal training bij een regionale telecomoperator (Q4 2024, 11 checkpoints, geanonimiseerd) ② Upgrade-discussie risicobeoordeling kredietverlening bij een joint-stock bank (H1 2025, geanonimiseerd) ③ Herontwerp van het wijzigingsbeoordelingsproces voor MES-proceschanges bij een grote fabrikant (H2 2025, geanonimiseerd) ④ Lock-scenario voor een groot e-commerceplatform tijdens piekpromotie (Double 11 2025, geanonimiseerd).
Toelichting bij anonimisering van cases: De in dit artikel genoemde cases uit de telecom-, financiële, productie- en e-commercesector zijn gebaseerd op de AI-internal training en observaties van digitale transformatieteams van de auteur in de telecomwereld. Alle cases zijn geanonimiseerd; de sectorspecifieke implementatieparagrafen betreffen typische-issuescenario-uitwerkingen en geen specifieke klantconsultancy-resultaten. Bij citaten dient de anonimisering expliciet vermeld te worden.