AI-agents en code review: waar win je snelheid, waar blijft de mens nodig

AI integreren in je CI-pipeline. Als je organisatie GitHub gebruikt, is deze integratie eenvoudig in te richten. Bij Garansys maken we primair gebruik van Azure DevOps. Dit heeft voordelen, maar is in dit geval lastig. Inrichting van agentic PR-review moesten we dus zelf vormgeven. De eerste versies van onze eigen review-agent voor Azure DevOps werkte niet optimaal: weinig comments, en bij een rerun ineens andere bevindingen dan de vorige keer. De oorzaak lag bij de aanpak: één grote aanroep dekt een PR zelden volledig af, hoe sterk het onderliggende model ook is. De agent aansturen om zelf meer regie te pakken, bracht ons de gewenste resultaten.

Tekst: Maarten Botter

We bouwden een pipeline-taak die PR-context ophaalt via de Azure DevOps REST API, de diffs laat beoordelen door een agentic CLI, en de bevindingen als inline comments terugzet op de PR. In plaats van één prompt met de hele PR erin, knipt het systeem de gewijzigde bestanden op in chunks en laat elke chunk zijn eigen pass draaien. Elke pass is coverage-first: rapporteer iedere bevinding met een confidence- en severity-label, en filter niet zelf op relevantie. In eerdere iteraties deed het model dit uit zichzelf, met als gevolg dat het te veel wegfiltert.

Door de tool te integreren in de standaard CI-pipeline, wordt de gehele diff bij iedere push - en dus ook bij verwerking van eerdere (agent-)comments, teruggevoerd aan de LLM. Dat brengt enorme kosten met zich mee. Daarom onthoudt het systeem na een schone run de laatst beoordeelde PR-iteratie, en beoordeelt het bij een rerun alleen het verschil sinds dat punt. Is er niets relevants gewijzigd, dan wordt het model niet eens aangeroepen. Is de wijziging klein, bijvoorbeeld een paar regels na eerdere reviewfeedback, dan schakelt het systeem automatisch naar een goedkoper model op lage reasoning-effort. Gegenereerde bestanden, zoals build-output of designer-bestanden, krijgen een placeholder in plaats van een volledige review. Hierdoor wordt AI alleen ingezet waar het daadwerkelijk waarde toevoegt, en blijven de kosten onder controle.

Niet elke wijziging vereist dezelfde denkdiepte. De reasoning-effort van elke pass schaalt daarom automatisch mee met de omvang van die specifieke chunk, niet met de hele PR, met een ingebouwde ondergrens en bovengrens zodat het systeem nooit te lui en nooit onnodig duur reviewt. We laten de zwaarte van model en effort meebewegen met de omvang en het risico van de wijziging, in plaats van één vaste instelling voor alles te gebruiken.

Na oplevering van onze eerste versie werd duidelijk dat deze tool continue doorontwikkeling zou vragen. Zowel de onderliggende prompt als de tools waar de agent beschikking toe heeft, lijken altijd beter te kunnen. Hierin is de onvoorspelbaarheid van LLM's interessant: in nieuwe cases kan de output hiervan altijd verrassen. Te weinig comments, te veel comments, een verkeerde toon, dubbele meldingen bij een rerun. Door de lessons learned samen met AI te verwerken in de tool, kan eenvoudig en snel geïtereerd worden en wordt het product steeds beter.

De tool helpt in het analyseren van de opgeleverde code. De developer blijft verantwoordelijk voor de kwaliteit van de PR. Omdat het model bewust niet zelf filtert op belangrijkheid, krijg je ook meer ruis: een reviewer moet nog steeds prioriteren en filteren. AI vergroot coverage en consistentie. Verantwoordelijkheid draagt het niet.

De AI-reviewer dient ter ondersteuning van de developer in het leveren van kwaliteit. Het is een extra kwaliteits- en veiligheidscheck bovenop wat de developer levert. Idealiter voer je als developer zelf dezelfde soort checks uit. Door een diff-review te integreren in het lokale-ontwikkelproces van de developer voorkom je tevens extra API-kosten. Prompts vanuit de CLI of GUI gaan immers van het token-budget af. Ook hier speelt standaardisatie een rol: door iedereen in het team te voorzien van eenzelfde standaard-review skill, die net zo ver gaat als de PR-reviewer, voorkom je onnodige iteraties in PR-fase en verhoog je de kwaliteit daarvoor al. De gate in de pipeline houdt daarmee zijn waarde tegen lagere kosten en doorlooptijd.

Snelheid en kostenbesparing komen dus uit orkestratie: chunking, incrementele reviews, en model- en effort-keuzes die meebewegen met de wijziging. Menselijke controle blijft nodig zodra iets faalt, het om security gaat, en bij de uiteindelijke merge-beslissing. Daarbij is het zo veel mogelijk naar voren halen van het AI-proces dus voordelig.