Nagebouwde GitHub pull request van 'ai-agent' (9 commits, 42 gewijzigde bestanden), met 'Review required, no reviewers assigned' en 'No one assigned', en in oranje handschrift 'Wie draagt verantwoordelijkheid?' over de groene 'Merge pull request'-knop.

"Die agents produceren toch alleen maar bugs, wollige code en onnodige complexiteit? Dat krijg ik er met geen tien reviews helemaal uit."

Het is een zorg die ik regelmatig hoor, en een terechte: bij agentic coding is kwaliteit al snel een ondergeschoven kindje. Maar zelfs dit is niet de echte blokkade. De vraag eronder zit een laag dieper: wie is verantwoordelijk voor de code die een agent produceert?

Want agentic coding faalt zelden doordat agents slechte code schrijven. Het faalt doordat teams sneller code laten ontstaan dan ze eigenaarschap, review, guardrails en kwaliteitscriteria hebben georganiseerd.

Toch gaat elk gesprek eerst over de bezwaren. Drie hoor ik het vaakst. Stuk voor stuk reëel, geen ervan een reden om te wachten, op één na. Even er langs, dan terug naar die vraag.

De drie bezwaren

1. "Onze codekwaliteit holt achteruit"

Testdekking mager, die ene legacy-module snapt niemand meer.

De grootste en meest gegronde zorg. Als een team met AI begint, daalt de kwaliteit vaak eerst: je genereert sneller, dus glippen er makkelijker fouten doorheen. Daarom moet je vangnet op orde, met hogere testdekking en meer integratie- en end-to-end tests. En laat dat nu net het werk zijn waar agents waarde leveren, mits je ze beperkt inzet: eerst begrijpen, testen, documenteren en kleine verbeteringen voorstellen, niet meteen autonoom grote refactors laten uitvoeren. Slechts 29% van de developers zegt AI-code in zekere mate functioneel te vertrouwen; volledig vertrouwen doet maar 4%[1]. De verantwoordelijkheid ligt dus bij jou.

Tip: durf je nog niet helemaal met agents? Begin andersom: laat ze eerst jullie code controleren in plaats van schrijven. Laagdrempelig, en je bouwt vertrouwen op voordat een agent code genereert. Jij bewaakt de architectuur en neemt de eindbeslissing.

2. "De security-risico's zijn te groot"

Ik wil broncode en secrets niet naar een extern LLM sturen.

Het risico is reëel: in een test van ruim honderd taalmodellen, ook voor C#, bevatte de AI-gegenereerde code in 45% van de gevallen een beveiligingslek[2]. Geen reden om te wachten, wel om discipline af te dwingen:

  • Context-files die de agent binnen je kaders houden.
  • Enterprise-tooling die je data niet voor training gebruikt.
  • Secrets in een secrets manager (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager), nooit in code, met pre-commit hooks die lekken blokkeren.
  • Iteratieve reviews op je PR's, met strenge en uitgebreide securityinstructies voor de review-agent.

Zet AI daarbij niet neer als securityautoriteit, maar als extra controlelaag: laat agents zoeken naar ontbrekende inputvalidatie, secrets, dependency-risico's en afwijkingen van je eigen richtlijnen. De eindbeoordeling blijft menselijk. Het gebrek aan governance is het risico, niet de tool.

3. "Nog niet iedereen in ons team is enthousiast"

Sceptische seniors houden de boot af.

Dit bezwaar is van een andere orde. Geen agent lost het op; het is veranderkunde. Zit de discussie muurvast, dan helpt betere software niet. Hier ben je als lead aan zet: faciliteer de omslag en herdefinieer de rol van de senior.

Terug naar de vraag: wie is verantwoordelijk?

Twee bezwaren gaan over je codebase, en die los je met AI op. Het derde gaat over je mensen. Geen ervan raakt de kern: eigenaarschap. 97% van de dev-teams gebruikt AI om code te schrijven, slechts 30% heeft vastgelegd hoe[3]. Daar zit het gat.

Het antwoord mag niet vaag blijven. Eigenaarschap is een balans tussen drie partijen:

  • De agents: voeren het werk uit, maar dragen geen verantwoordelijkheid; het blijven assistenten.
  • Jij (de developer): je blijft eindverantwoordelijk voor je eigen code, inclusief de code die je met agents genereert, en aanspreekbaar op bugs. Jij bent de meester-architect die zijn stempel zet.
  • Het team: draagt samen de kaders waarbinnen de agents werken, de context-files, de guardrails en de review-afspraken.

Leg dat niet alleen op het bordje van die ene developer. Moedigt de organisatie AI-gebruik aan, dan moet het leiderschap duidelijk benoemen wie waarvoor verantwoordelijk is. Die balans regel je niet in één keer; je bouwt 'm als team op, en dat is net zo goed veranderkunde als techniek.

Eigenaarschap zit in hoe je reviewt

Eigenaarschap wordt concreet in hoe je reviewt. De rol van de senior verschuift daarbij: van zelf code schrijven naar het bewaken van architectuur en logica. Geen degradatie tot afvinker; het vakmanschap gaat mee. Twee spelregels:

1. Stuur nooit onbeoordeelde AI-output door naar een collega. Een agent produceert in minuten meer code dan een developer in een ochtend typt. Review je eigen AI-code net zo grondig alsof je hem zelf had geschreven, voor een teamgenoot ernaar kijkt. Anders zitten jullie beste mensen straks de rommel van de rest op te ruimen, en niets sloopt motivatie sneller.

2. Hou PR's klein. Hoe groter de PR, hoe oppervlakkiger de review en hoe meer er ongezien doorglipt. Kleine, reviewbare stukken houden de reviewdruk beheersbaar en de kwaliteit overeind. En de zwaarste reviewlast voorkom je nog eerder, met scherpe specs vooraf: daar gaat spec-driven development over.

Beleg je het niet, dan word je ingehaald door de praktijk

Doe je dit niet, dan wordt de vraag alsnog beantwoord, alleen niet door jou.

Verbied je het, dan krijg je shadow AI: het gebruik buiten de officiële kanalen groeit hard, securitytools detecteren in een jaar vier keer zo veel, en broncode is veruit het meest geüploade datatype naar niet-goedgekeurde tools[4]. Twee derde van de professionals gebruikt AI zelfs wanneer ze vermoeden dat het niet mag[5].

Stel je geen regels, dan krijg je het tegenovergestelde: openlijk gebruik zonder kaders, volle reviews, felle discussies en kwaliteit die snel daalt.

Hoe dan ook blijft de vraag: ontstaat die code binnen jouw kaders, of erbuiten?

Begin stap voor stap

Wacht niet op het perfecte moment. De kwaliteit bewaak je met AI, de risico's beheers je met een strakke setup, je mensen neem je geleidelijk mee. Een gestructureerde werkwijze, vijf stappen van experiment naar borging, werk ik uit in Van AI-experimenten naar AI-adoptie.

Maar het begint niet bij de tooling en niet bij de codebase. Het begint bij één afspraak: leg vast wie verantwoordelijk is voor de AI-output, en op basis van welke criteria. Niet als last op één developer, maar als gedeelde verantwoordelijkheid die team en leiderschap samen dragen. Doe je dat niet, dan haalt de praktijk je in.

Bronnen

  1. Sonar, State of Code Developer Survey 2026 ↩
  2. Veracode, 2025 GenAI Code Security Report: AI-gegenereerde code introduceerde in 45% van de tests een beveiligingsrisico (ruim 100 taalmodellen; Java, JavaScript, Python, C#) ↩
  3. Infosecurity Magazine, "AI Coding Adoption Hits 97% but Governance Lags Behind" (2026) ↩
  4. Verizon, 2026 Data Breach Investigations Report (DBIR): shadow-AI-detecties verviervoudigd, broncode meest geüpload ↩
  5. PagerDuty, 2026 Shadow AI Survey ↩