Hoe werkt een AI-codereview door een council van agents?

Wat is een AI-codereview?

Een AI-codereview is een beoordeling van code door een taalmodel, dat zoekt naar fouten, beveiligingsrisico's en afwijkingen van de afspraken in een project. Dat kan een enkele wijziging zijn of een hele codebase.

Er zijn veel tools die dit in pull requests doen, van Copilot code review tot losse review-bots. Ze vinden veel, en hun makers zijn eerlijk over de grenzen. Volgens de documentatie van GitHub⁠↗ telt een review van Copilot standaard niet mee als vereiste goedkeuring, vindt Copilot niet gegarandeerd alle problemen en raadt GitHub aan de feedback aan te vullen met een menselijke review.

Eén model dat een diff naleest, heeft één blik op de code. Het mist dingen, en het kan niet goed wegen welke van zijn eigen opmerkingen ertoe doen. Een council zet daarom meerdere reviewers op dezelfde code en laat hun bevindingen toetsen.

Wat is een council van agents?

Een council is een groep AI-agents die hetzelfde werk vanuit verschillende posities beoordeelt, waarna de bevindingen worden gewogen. Het idee kreeg in het Engels de naam LLM council.

Andrej Karpathy publiceerde met llm-council⁠↗ een kleine webapp die dat laat zien. Meerdere modellen beantwoorden dezelfde vraag. Daarna beoordeelt elk model de antwoorden van de anderen zonder te weten van wie ze zijn, en rangschikt ze. Een voorzittend model voegt alles samen tot één antwoord. Karpathy noemt het zelf een weekendproject dat hij niet gaat onderhouden, maar het patroon is bruikbaar.

Voor codereview werkt een council iets anders. De reviewers beantwoorden niet allemaal dezelfde vraag, maar kijken elk vanuit een eigen specialisme naar dezelfde code: beveiliging, architectuur, de koppelingen met externe diensten. Bij Studio Northstar draait zo'n council binnen ARCS, ons agentic platform. Een gespecialiseerde council beoordeelt je code op beveiligingsrisico's, onderzoekt oudere software of controleert een oplevering ter voorbereiding op een audit.

Waarom meerdere reviewers beter werken dan één, en wanneer niet

Meerdere reviewers met elk een eigen focus vangen meer soorten fouten, en een reviewer die de code niet zelf schreef, deelt de blinde vlekken van de schrijver niet. Dat werkt alleen als de reviewers echt verschillend kijken en iemand hun bevindingen weegt.

Anthropic noemt dit patroon in Building effective agents⁠↗ als voorbeeld van parallel werken: meerdere prompts beoordelen dezelfde code op kwetsbaarheden en melden het als ze een probleem vinden. Onderzoek naar modellen als beoordelaar laat zien waarom de reviewer niet de maker mag zijn. Zheng e.a. beschrijven in Judging LLM-as-a-Judge⁠↗ (2023) onder meer een voorkeur voor de positie van een antwoord, voor langere antwoorden en voor eigen werk.

Een council helpt niet altijd:

• Bij kleine wijzigingen. Een tekstcorrectie of een hernoemde variabele heeft geen vijf reviewers nodig. Anthropic raadt aan de eenvoudigste oplossing te kiezen en pas complexiteit toe te voegen als dat aantoonbaar helpt.
• Als iedereen hetzelfde doet. Vijf keer dezelfde opdracht levert vooral vijf keer dezelfde bevindingen op.
• Zonder weging. Meer reviewers geven meer meldingen. Zonder toets krijg je een lange lijst waarin de echte problemen verdwijnen.

Hoe verloopt een council-review stap voor stap?

In vijf stappen: afbakenen, verdelen, los van elkaar beoordelen, toetsen en beslissen.

1. Doel en grenzen vastleggen. Wat moet de review opleveren, welke code valt erbinnen en welke risico's tellen het zwaarst.
2. Het werk verdelen. Elke reviewer krijgt een eigen specialisme, bijvoorbeeld beveiliging, architectuur of de koppelingen met externe diensten.
3. Los van elkaar beoordelen. De reviewers werken apart en lezen alleen; ze passen niets aan. Per bevinding leggen ze vast waar die zit en waarop die is gebaseerd.
4. Toetsen. Een onafhankelijke reviewer, een ander model of een aparte context die de bevindingen niet zelf maakte, controleert ze. Na een correctie volgt een nieuwe controle: bevinding, gerichte aanpassing, nieuwe controle.
5. Beslissen. Een mens bepaalt wat er met de bevindingen gebeurt.

Voorbeeld: de review van de Plens-app

Plens is onze app die zegt wanneer je het beste kunt vertrekken om droog te fietsen. Op 24 september deed Claude Code een onafhankelijke review van de app, met aparte agents die alleen mochten lezen: één voor externe verbindingen, één voor de webrepo en één voor code en UX. De eerste blokkerende bevinding was dat de hele app in één bestand van 317 regels zat, zonder deep links. Een link vanuit een melding kon dus nergens heen.

Het reviewdocument begint met een feitenbord: per omgeving wat er gelezen is, wat de stand was en welke toegang of welk bewijs ontbrak. Er staat ook bij wat het document niet bewijst, namelijk dat iets op een echt toestel werkt.

Daarna controleerde een aparte verifier met verse context de pull request met de eerste reparaties, vóór de merge. Die vond tien punten, waarvan één blokkerend. De code gebruikte een functie die niet bestaat in de versie van AbortSignal die React Native meelevert. Op een toestel faalde daardoor bijna elke leesaanroep, terwijl de tests op web en in Node niets merkten.

Wat vindt een council wel en niet?

Een council vindt wat in de code en de omgeving te zien is: logica die niet klopt, beveiligingsrisico's, ontbrekende foutafhandeling, afwijkingen van de architectuur. Wat buiten die context ligt, ziet hij niet zonder hulp: gedrag op een echt toestel, of de reden achter een keuze die nergens is opgeschreven.

Een melding is ook nog geen fout. Een reviewer kan een probleem zien dat er niet is, of een bewuste keuze aanzien voor een vergissing. Daarom toetst een tweede partij de bevindingen voordat ze in het rapport komen, en daarom staat bij elke bevinding de controle waarop die is gebaseerd. Wie het rapport leest, kan dan zelf nagaan of een melding klopt.

Voor beveiliging gebruiken reviewers vaak de OWASP Top 10⁠↗ als vertrekpunt, een lijst van veelvoorkomende risico's in webapplicaties. De meest recente editie is van 2025. Zo'n lijst is een kader, geen garantie dat alles gevonden is.

Review van oudere software en voorbereiding op een audit

Een council kan ook een bestaande codebase onderzoeken, niet alleen een nieuwe wijziging. Dat doen we bij oudere software en bij een oplevering die een audit moet doorstaan.

Bij oudere software wil je eerst weten waar de risico's zitten voordat je iets verandert. De reviewers kunnen de hele codebase lezen zonder iets aan te raken, en geven aan waar het probleem zit en hoe ernstig het is. Ook code die snel met AI is gemaakt, bijvoorbeeld met vibe coding, heeft baat bij zo'n review voordat hij in productie gaat.

Bij een audit telt dat je kunt laten zien wat er is gecontroleerd. Daarom krijg je de bevindingen met de controles waarop ze zijn gebaseerd. Een council-review is geen audit en vervangt die niet. Het is voorbereiding, zodat je weet wat een auditor gaat vinden voordat die komt.

Wat krijg je terug?

Je krijgt de bevindingen, elk met de controle waarop die is gebaseerd. Hoe het rapport eruitziet, stemmen we af op de opdracht. De review van Plens laat zien wat erin kan staan:

• de ernst per bevinding: blokkerend, hoog, middel of laag;
• het scherm of bestand waar het om gaat;
• het gevolg voor de gebruiker;
• de voorgestelde oplossing en de status ervan;
• een feitenbord met wat er is gelezen en welke toegang of welk bewijs ontbrak.

Door dat feitenbord zie je ook wat niet is gecontroleerd. Een mens beslist daarna wat er wordt opgelost en in welke volgorde. Hoe dat binnen een project loopt, staat bij bouwen en in de dienst codereview.

Wil je je code laten beoordelen door een council? Neem contact op, dan bespreken we eerst wat de review moet opleveren.