AI-gestuurde review gebruiken

Deze gids laat zien hoe je reviewer-agenten een pull request laat reviewen en hoe je het resultaat naar GitHub publiceert.

Een AI-review starten

Open de PR en ga naar het tabblad Overzicht
Open het ⋯-overloopmenu in de actierij en kies Ask AI

Het item verschijnt alleen zolang de PR open is — het is een actie vóór de merge. Dezelfde knop wordt als Ask AI aangeboden in de lege weergave van het tabblad Review, voordat er een review bestaat.

Control Center start de meegeleverde pr_review-pipeline en opent het tabblad Review van de PR zodat je kunt meekijken. De pipeline:

Opent de eigen reviewruimte van de PR, waarvan de geïsoleerde worktree de PR heeft uitgecheckt op zijn head-ref
Waaiert reviewer-agenten uit voor het reviewniveau van de werkruimte — standaard drie (de meegeleverde qa-, architect- en engineer-agenten, parallel). Er is geen taal- of domeindetectie
Laat de lead-agent (CEO) hun bevindingen bundelen tot een rondleiding
Finaliseert: sorteert de bevindingen in consensusgroepen en berekent het oordeel. Wanneer de koppeling awaiting approval bereikt, verschijnt Publiceren naar GitHub op het tabblad Review

Hoe diep de review gaat, is het reviewniveau van de werkruimte — light (één reviewer), balanced (drie, de standaard) of thorough (alle vijf, inclusief de specialisten beveiliging en performance) — ingesteld via Instellingen → Werkruimte → Algemeen, op de kaart Werkruimtebeleid. Een lichter niveau legt precies evenveel bevindingen vast; het toont er minder vooraan.

Alle reviewers posten in de ene reviewruimte van de PR, en dat is wat hun bevindingen vergelijkbaar maakt. Zie AI-review voor hoe de onderdelen samenhangen.

pr_review wordt alleen met een handmatige trigger geleverd. Wil je dat de pipeline bij elke gepubliceerde PR afgaat, voeg dan zelf een trigger toe — zie Reviewer-agenten starten. Je kunt er ook een starten vanuit GitHub zelf, zonder pipelinetrigger: vermeld de bot van de server in de PR of voeg het label ai-review toe — zie Met Control Center praten vanuit een GitHub-PR.

Als een melding zegt dat er al een review draait voor deze pull request, dan is er al een onderweg; blijf op het tabblad Review of open Pipelines om hem te vinden.

De bevindingen lezen

Reviewers leggen bevindingen vast als reviewnodes in de reviewruimte. Elke node bevat:

Veld	Beschrijving
Soort	`bug`, `suggestion`, `recommendation`, `question` of `ticket`
Prioriteit	P0 (kritiek) → P3 (nit)
Categorie	`security`, `stability`, `data_integrity`, `correctness`, `performance` of `maintainability`
Bestand en regel	Waar de bevinding verankerd is
Oorspronkelijke code	De code waarop de bevinding betrekking heeft
Voorgestelde code	De voorgestelde oplossing
Betrouwbaarheid	Hoe zeker de reviewer is
Status	`open` → `consensus-ready` → `resolved` of `dismissed`

Een bevinding bereikt pas consensus-ready als een peer-reviewer hem bevestigt. Een agent kan zijn eigen bevinding niet bevestigen, dus de mening van één reviewer gaat nooit op eigen kracht verder.

Het tabblad Review toont de bevindingenlijst, filterbaar op soort en status, met een schakelaar voor verworpen bevindingen, naast het artefact dat de bundelende agent heeft gepubliceerd. De deterministische weergave — cohorten, het dashboard met meerdere assen, contract- en visuele diffs — wordt server-side berekend maar heeft geen oppervlak in de app; zie Review-compute (cohorten en assen) voor wat de ronde oplevert.

Het paneel met meningsverschillen bekijken

Wanneer twee reviewers bevindingen aan hetzelfde bestand en dezelfde regel verankeren maar ze heel verschillend beoordelen — prioriteiten twee of meer niveaus uit elkaar, of de een noemt het een bug terwijl de ander het een suggestion noemt — verschijnt er een paneel met meningsverschillen boven de bevindingenlijst. Lees die eerst: daar lopen de meningen van de reviewers uiteen en is jouw oordeel het meest waard.

Het oordeel lezen

Wanneer de lead-agent finaliseert, berekent die een oordeel:

Oordeel	Betekenis
Ship	Niets blokkerends gevonden
Hold	Problemen die vóór de merge moeten worden aangepakt
Block	Kritieke problemen die moeten worden opgelost

Het oordeel draagt een samengestelde betrouwbaarheidsscore en aantallen bevindingen per prioriteit.

De reviewassen wegen daarna mee en kunnen het oordeel alleen strenger maken. Een as met een poort die faalt, dwingt Block af; een as met een poort die niet kon afronden (partial) of helemaal niet kon draaien (unavailable) dwingt minstens Hold af. Afwezigheid van bewijs opent nooit een poort.

De review naar GitHub publiceren

Publiceren is een aparte stap die bewust door de gebruiker wordt geactiveerd. De pr_review-pipeline houdt de review in Control Center; er wordt niets naar GitHub gepost.

Wacht op het tabblad Review totdat Publiceren naar GitHub verschijnt
Druk op Publiceren naar GitHub

Control Center verstuurt één GitHub-review. Bevindingen die al zijn opgelost of verworpen, worden overgeslagen. De knop neemt elke resterende open bevinding mee en dient bij Ship APPROVE in. (De MCP-tool publish_review_to_github gebruikt standaard nog steeds alleen door peers bevestigde bevindingen en keurt niet goed tenzij je approve_on_ship meegeeft.) Bevindingen met een anker naar een bestand en regel worden inline reacties; al het overige komt in de samenvattingstekst terecht, elk met een voettekst “— Control Center AI review”, zodat de bron ondubbelzinnig is. Een Block-oordeel wordt ingediend als REQUEST_CHANGES; Hold als COMMENT; Ship als APPROVE vanaf deze knop. Een melding luidt dan Gepubliceerd. De review wordt geplaatst onder de app-identiteit van de server.

Als GitHub een inline anker weigert omdat de regel geen deel uitmaakt van de diff, wordt de hele review opnieuw verstuurd met elke bevinding in de tekst opgenomen, zodat niets stilzwijgend verdwijnt.

Andere ingebouwde pipelines posten wél rechtstreeks naar GitHub: cross_review, pr_triage, ticket_to_pr en pre_merge_gate eindigen elk in een commentaarstap. Alleen pr_review houdt zijn uitvoer voor jou achter.

Zelf reviewers starten

Wil je zelf bepalen welke rollen de PR reviewen en naar welke bestanden elk van hen kijkt, gebruik dan de MCP-tool dispatch_reviewers in een bestaande reviewruimte, of voeg reviewernodes toe aan een pipeline. Beide manieren, met de exacte signatuur van de tool, staan in Reviewer-agenten starten.