Moet je de code van je AI-agent nog steeds beoordelen?

De discussie begint op dezelfde manier in elk team. De ene kant zegt dat de agents nu schonere code leveren dan de helft van de pull requests die we vroeger goedkeurden, dus waarom lezen we nog steeds elke regel? De andere kant zegt omdat wij degenen zijn die het goedkeuren.

Beide kanten hebben gelijk. Dat is precies waarom de discussie nooit eindigt. Het eindigt niet omdat de vraag verkeerd is, en zodra je de vraag aanpast, wordt het antwoord bijna saai.

Het argument om te verzenden zonder elke regel te lezen

Begin met de sterkste versie van het optimistische argument, omdat het sterker is dan de meeste beoordelaars toegeven.

Bij een afgebakende taak met een duidelijke specificatie en een testpakket produceert een moderne codeeragent consistentere code dan de gemiddelde mens die onder een deadline werkt. Het verveelt zich niet op het foutpad. Het schrijft de null-check om 18.00 uur op een vrijdag. Het volgt de projectconventies die het kreeg, elke keer, zonder de kleine stille opstanden die een vermoeide ontwikkelaar zichzelf toestaat.

Menselijke beoordeling was ook al gebroken voordat agents arriveerden. Iedereen die in een echt team heeft gewerkt, kent de LGTM-reflex: de aandacht van de beoordelaar stort in na een paar honderd regels, en de goedkeuringen die volgen zijn sociaal, niet technisch. We hebben geen gouden tijdperk van rigoureuze beoordeling verloren. We verloren een ritueel dat al grotendeels theater was.

Dan is er nog het volume. Een ontwikkelaar die vijf agents parallel laat draaien, genereert meer diff per uur dan een mens zorgvuldig kan lezen. Als je regel is "lees alles", heb je jezelf stilletjes opnieuw geïnstalleerd als de bottleneck die je net hebt geautomatiseerd. Een mens die een diff van 900 regels vluchtig doorleest, produceert een handtekening zonder kennis te produceren, en dat is erger dan helemaal niet beoordelen, omdat het zekerheid creëert waar die er niet is.

Het argument om een mens op de diff te houden

Nu de andere kant, die ook sterker is dan de enthousiastelingen toegeven.

Verantwoordelijkheid wordt niet overgedragen. Het model wordt niet om 3 uur 's nachts gepaged. Het is niet in de incidentbeoordeling, het praat niet met de klant wiens gegevens zijn gelekt, en het draagt de consequentie van de verandering niet naar het volgende kwartaal. Degene die merge, is verantwoordelijk voor het resultaat, en beoordelen is hoe eigenaarschap wordt uitgeoefend in plaats van alleen maar verklaard.

Agentbeoordelaars falen in dezelfde richting als agentauteurs. Dit is het argument dat daadwerkelijk het voorstel "laat gewoon een andere agent het beoordelen" beslecht. Twee agents uit dezelfde modelfamilie, met dezelfde context, delen vooroordelen, delen trainingsdata en delen blinde vlekken. Hun fouten zijn gecorreleerd. Een tweede agent zal graag een ontbrekende test of een niet-afgehandelde fout opmerken, en zal graag de subtiele misvatting van je domein goedkeuren die de bug in de eerste plaats veroorzaakte, omdat het dezelfde misvatting had. Twee beoordelaars die in dezelfde richting fout zitten, vormen geen beoordeling.

De metingen zijn ook niet vleiend. Industriële gegevens tonen aan dat beoordelaars aanzienlijk meer rondes uitwisselen over AI-gegenereerde wijzigingen dan over door mensen geschreven wijzigingen: de code komt sneller aan en duurt langer om betrouwbaar te worden. Een studie uit januari 2026 ging verder en ontdekte dat door agents gegenereerde wijzigingen meer redundantie en meer opgebouwde technische schuld per wijziging bevatten dan door mensen geschreven wijzigingen, terwijl beoordelaars zich beter voelen over het goedkeuren ervan. Die kloof, tussen hoe goed de code aanvoelt en hoe goed deze is, is het hele risico in één zin.

De discussie is verkeerd ingekaderd

Hier is de herformulering die de vergadering beëindigt.

Je beoordeelt de code niet omdat je de auteur wantrouwt. Je beoordeelt het omdat jij degene bent die tekent. Dat zijn totaal verschillende activiteiten, en het hele argument komt voort uit het verwarren ervan.

Zodra je het zo ziet, stopt "is de agent beter dan een mens" de beslissende vraag te zijn. De beslissende vraag is: als deze wijziging verkeerd is, hoe duur is het om erachter te komen, en hoe duur is het om het ongedaan te maken? Een typefout in een marketingkop wordt binnen enkele seconden ontdekt en binnen enkele seconden teruggedraaid. Een omgekeerde permissiecontrole in een autorisatiemiddleware wordt ontdekt door een klant, of door een toezichthouder, en wordt nooit echt teruggedraaid, omdat de gegevens tegen die tijd al zijn gelezen.

Dus het antwoord is noch "alles beoordelen" noch "de agent vertrouwen". Het is:

Je stopt met het beoordelen van regels. Je begint risico's te beoordelen.

Concreet verschuift de beoordeling van het midden van het werk naar de twee grenzen ervan. Vooraf: lees het plan, want een verkeerd plan dat perfect wordt uitgevoerd, is de duurste faalmodus die er is, en een plan is vijftien regels in plaats van negenhonderd. Achteraf: lees de diff in verhouding tot de impact. Tussendoor behoren de regels tot de machine.

Hoe "de agent maakte een fout" er eigenlijk uitziet

Het nuttigste dat je kunt terugbrengen naar je team is geen mening, het is een lijst van objectieve signalen. Niet "de code voelt niet goed", maar signalen die je in minder dan een minuut op een diff kunt controleren. Dit zijn de signalen die hun plaats hebben verdiend.

1. De tests zijn gewijzigd in dezelfde commit als de code die ze dekken. Het groen werd geconstrueerd, niet waargenomen. Dit is het signaal met de hoogste waarde op de lijst, en het is degene die je als eerste moet controleren.
2. Een bewering werd verzwakt of een test werd uitgeschakeld. Een skip, een only, een bewering die werd verruimd om te accepteren wat de nieuwe code toevallig retourneert, een try/catch die de fout opvangt die de test zou moeten blootleggen.
3. De diff is groter dan de taak. Bestanden die niemand vroeg werden aangeraakt. Scope creep in een agent is geen enthousiasme, het is een teken dat de agent het doel ergens onderweg opnieuw heeft geïnterpreteerd.
4. Een verzonnen oppervlak. Een API-methode, een configuratieoptie of een pad dat niet bestaat. Het compileert in het hoofd van de agent en nergens anders.
5. De omgeving werd aangepast in plaats van de code. Een hardgecodeerd absoluut pad, een machine-specifieke waarde, een persoonlijke token, een gebruikersnaam. Het symptoom verdween op de machine van de agent en verplaatste zich naar die van iedereen anders.
6. Een afhankelijkheid verscheen zonder dat erom werd gevraagd. Nieuwe toeleveringsketen, nieuwe licentie, nieuw onderhoudsoppervlak, beslist door iets dat het niet zal onderhouden.
7. Duplicatie in plaats van hergebruik. Het implementeerde een helper die al twintig regels verderop bestond. Dit is het mechanisme achter de gemeten schuld: elke wijziging lijkt lokaal redelijk en de codebase krijgt stilletjes een derde manier om hetzelfde te doen.
8. De samenvatting komt niet overeen met de diff. "Gerepareerd en getest" terwijl er geen test is uitgevoerd. Vertelling wordt met hetzelfde vertrouwen gegenereerd, ongeacht of het werk is gedaan, dus behandel het als een claim om te verifiëren, nooit als een rapport.
9. De instructies werden niet meer gevolgd. Kleine conventies die stilletjes worden weggelaten, is hoe een sessie degradeert voordat deze volledig begint te hallucineren. Als je een kanarie in je contextbestand gebruikt, is dit precies waar het voor is bedoeld.
10. Gevoelig terrein werd terloops aangeraakt. Een .env-lezing, een nieuwe uitgaande netwerkoproep, een nieuwe logregel met gebruikersgegevens, een migratie gebundeld in een feature commit.

Let op wat niet op de lijst staat: stijl, naamgeving, opmaak, "ik zou het anders hebben gedaan". Dat waren altijd al de zwakste delen van menselijke beoordeling en ze zijn nu echt een verspilling van een mens. Verwijder ze uit je beoordeling en je koopt de aandacht terug die je nodig hebt voor de tien bovenstaande items.

Hoeveel beoordeling verdient een wijziging?

Impact, niet de grootte van de diff, bepaalt het. De tabel die je team vanmiddag kan aannemen:

De grootte van de diff vertelt je hoe lang de beoordeling duurt. De impact vertelt je of het optioneel is.

De rijen gaan niet over vertrouwensniveaus. Ze gaan over de kosten van het fout zijn, wat een eigenschap is van de code en niet van wie het heeft geschreven. Dat is wat de tabel bruikbaar maakt: niemand hoeft het eens te zijn over hoe goed de agents zijn om het eens te zijn over de tabel. Als je team vastzit op de filosofische vraag, sla die dan over en onderhandel in plaats daarvan over de rijen. Je zult verrast zijn hoe snel dat convergeert.

Als je product persoonlijke gegevens in Europa verwerkt, is er nog een rij voor jou geschreven door de wet in plaats van door smaak: wat een door AI gebouwde functie moet respecteren onder de AVG is geen beoordelingskwestie, en "een agent heeft het geschreven" is nooit een verdediging geweest.

Wat verandert er als vijf agents tegelijk draaien

Alles hierboven gaat ervan uit dat je de wijziging kunt zien. Met parallelle agents breekt die aanname als eerste, en het breekt op een specifieke manier: de diff stopt met een enkele auteur te hebben. Drie agents hebben de werkboom aangeraakt sinds je laatste commit, en de vraag "wie heeft dit bestand gewijzigd, en als onderdeel van welke taak" heeft niet langer een voor de hand liggend antwoord. Beoordeling zonder toeschrijving is geen beoordeling, het is archeologie.

Dat is een toolingprobleem, en het is de reden waarom AgentsRoom beoordeling plaatst waar de agents zijn in plaats van aan het einde van een pull request:

• Beoordelingsmodus toont elke wijziging die je agents hebben gemaakt, als een leesbare diff, voordat er iets wordt gecommitteerd. Het is de stap "lees de diff in verhouding tot de impact", goedkoop genoeg gemaakt zodat mensen het daadwerkelijk doen.
• Per-agent beoordeling filtert die diff per agent en laat je het werk van elke agent afzonderlijk committen. Vijf parallelle agents worden vijf beoordeelbare eenheden in plaats van één onleesbare werkboom, en een slechte wijziging blijft toewijsbaar aan de taak die het heeft geproduceerd.
• Het commitbericht wordt gegenereerd van de echte diff met de glinsterknop op het commitveld, zodat de geschiedenis beschrijft wat er is veranderd in plaats van wat de agent zei dat het deed. Dat onderscheid is belangrijk om 3 uur 's nachts, zes maanden later.

Niets van dit alles vervangt oordeel. Het verwijdert de excuses om het niet uit te oefenen.

Laat de machine de regels bezitten

Als je wilt stoppen met het lezen van regels, moet iets anders ze lezen. In de praktijk dragen vier dingen die last:

Tests die de agent niet in dezelfde adem schreef als de code. Eerst geschreven, of geschreven door een andere agent, of op zijn minst beoordeeld als hun eigen wijziging. Op het moment dat code en de tests ervan uit dezelfde generatie komen, stoppen ze met onafhankelijke bewijzen te zijn.

Een beoordelaar met een ander model. Dit is het praktische antwoord op het probleem van gecorreleerde fouten. Als een tweede agent beoordeelt, laat het dan draaien op een andere provider of modelfamilie dan de auteur. Je zult de fouten niet volledig decorreleren, maar een Codex-familiebeoordelaar op Claude-geschreven code vangt een meetbaar andere klasse van problemen dan een beoordelaar van hetzelfde model, precies omdat het de vooroordelen van de auteur niet deelt.

Poorten die niet moe worden. Types, lint, geheime scanning, dekkingsvloeren, een CI die een migratie gebundeld met een functie weigert. Elke regel die je als poort kunt uitdrukken, is een regel die je nooit meer hoeft op te merken.

Een lus die zichzelf sluit. Een agent die bouwt, zijn eigen werk tegen het plan uitvoert en iteraties doorloopt voordat hij iets overdraagt, verwijdert de hele categorie "niet eens uitgevoerd" uit je beoordeling. Dat is de zelfcorrigerende agentlus, en het is het verschil tussen een agent die een diff produceert en een die een resultaat produceert. Het beantwoordt niet de vraag of een mens moet tekenen. Het betekent gewoon dat de mens iets tekent dat al werkt.

Dus, beoordeel je nog steeds?

Ja, en minder dan je nu doet.

Stop met het lezen van regels om je verantwoordelijk te voelen. Lees het plan vooraf, want daar worden de dure fouten gemaakt. Lees de diff achteraf in verhouding tot wat het kan breken, gebruikmakend van de ladder in plaats van je humeur. Houd een mens persoonlijk op authenticatie, betalingen, permissies, persoonlijke gegevens en alles wat onomkeerbaar is, omdat een model geen verantwoordelijkheid kan dragen en een tweede agent de blinde vlekken van de eerste deelt. Geef al het andere aan tests, types, poorten en een beoordelaar die het model van de auteur niet deelt.

De teams die dit verkeerd aanpakken, falen in een van de twee richtingen, en beide zijn te vermijden. De ene beoordeelt alles, wordt de bottleneck, en begint stilletjes goed te keuren zonder te lezen, wat het slechtste van beide werelden is. De andere beoordeelt niets, verzendt snel gedurende twee maanden, en besteedt vervolgens een kwartaal aan het afbetalen van schuld die het nooit zag oplopen.

De discussie bij je stand-up gaat niet echt over of agents goed zijn. Het gaat erom wie bereid is te tekenen. Beantwoord dat, en het beoordelingsbeleid schrijft zichzelf.

Veelgestelde vragen

Moet je door AI gegenereerde code nog steeds beoordelen?

Ja, maar niet regel voor regel op alles. Beoordeel het plan voordat de agent begint, en beoordeel vervolgens de diff in verhouding tot wat de wijziging kan breken. Marketingtekst en CSS krijgen een vluchtige blik. Authenticatie, betalingen, permissies, persoonlijke gegevens en migraties worden elke keer regel voor regel door een mens gelezen.

Kan een AI-agent de code van een andere AI-agent beoordelen?

Het helpt, maar het is geen vervanging voor een mens bij risicovolle code. Twee agents uit dezelfde modelfamilie, met dezelfde context, hebben de neiging om in dezelfde richting te falen. Hun fouten zijn gecorreleerd, dus een tweede agent vangt typefouten en ontbrekende tests op, maar deelt de blinde vlekken die de bug hebben veroorzaakt. Als je een agentbeoordelaar gebruikt, laat deze dan draaien op een ander model dan de auteur.

Hoe weet je of een AI-agent een fout heeft gemaakt?

Zoek naar objectieve signalen in de diff in plaats van te lezen op stijl. Het sterkste signaal: tests zijn gewijzigd in dezelfde commit als de code die ze dekken, wat betekent dat het groen werd geconstrueerd en niet waargenomen. Andere signalen zijn scope creep, een uitgeschakelde of verzwakte bewering, een verzonnen API, een hardgecodeerd lokaal pad en een samenvatting die niet overeenkomt met de diff.

Zullen AI-agents menselijke codebeoordelaars vervangen?

Ze hebben al het meeste van het lezen van regels vervangen. Ze kunnen de handtekening niet vervangen. Verantwoordelijkheid wordt niet overgedragen aan een model, dus een mens is nog steeds verantwoordelijk voor de beslissing om te mergen op alles wat moeilijk om te keren is.

Moet je AI-code regel voor regel beoordelen?

Alleen waar de impact het rechtvaardigt. Regel voor regel beoordeling schaalt niet voorbij een paar agents die parallel draaien, en een mens die een diff van 900 regels vluchtig doorleest om 18.00 uur produceert een handtekening zonder kennis te produceren. Besteed die aandacht aan de wijzigingen die duur zijn om ongedaan te maken.

Wat mag nooit zonder menselijke beoordeling worden gemerged?

Alles wat te maken heeft met authenticatie, betalingen, permissies, persoonlijke gegevens, databasemigraties, verwijderingspaden en infrastructuur. Deze delen één eigenschap: de kosten van het fout zijn zijn niet evenredig met de grootte van de diff.