Checklist · Agent security & het AI coding harness

Checklist: van indruk naar meting

De meeste organisaties beoordelen hun AI-gebruik in softwareontwikkeling op gevoel. Deze checklist helpt je dat te vervangen door iets wat je kunt nakijken.

Gebaseerd op het Agentic Engineering-onderzoek 2026 · Markteffect in opdracht van Info Support · 330 Nederlandse IT-beslissers.
Bij de AIToday Live-aflevering “Wie heeft gelijk: de bestuurder of de engineer?”

Waarom deze checklist bestaat

Ruim acht op de tien Nederlandse organisaties zetten AI in tijdens het ontwikkelproces. Kijk je naar wie er actief toezicht op AI-agents heeft geregeld — logging, audits, een duidelijke rolverdeling — dan blijft ongeveer een derde over. En bij minder dan één op de tien is AI-governance formeel verankerd.

In die tussenruimte gebeurt iets ongemakkelijks. Zonder toezicht is elk oordeel over hoe goed het gaat een indruk, of je nu in de directie zit of in het team. Het onderzoek laat zien hoe ver die indrukken uiteenlopen: ongeveer een kwart van de hoofdbeslissers vindt dat elke AI-actie menselijke controle vereist, tegenover ongeveer de helft van de adviseurs met invloed op het beleid. Precies het dubbele.

De zorgen zijn scherp, de grenzen zijn zacht. Vrijwel iedere IT-beslisser benoemt de risico's: bedrijfsdata bij externe providers, hallucinaties in code, wet- en regelgeving, gebrek aan observability, agent security.

Wat achterblijft zijn de maatregelen die iets afdwingen. Beleid en goedkeuringsprocessen staan bovenaan; logging, monitoring en een afgeschermde sandbox blijven achter. Een taalmodel leest je beleidsdocument niet.

Wat is een AI coding harness?

De ontwikkelomgeving waarin architectuurprincipes, specificaties, tests, securityregels en feedbackloops zijn vastgelegd én technisch worden afgedwongen. Wat daarin staat, hoeft niemand meer na te kijken: de agent kon niet anders. De vraag verschuift van “heeft deze agent zich aan de regels gehouden?” naar “staan de goede regels in ons harnas?”.

De mens blijft in de loop. Alleen op een andere plek: bij het inrichten van de kaders, niet bij het narekenen van details.

Hoe je hem gebruikt

Loop de checklist door met de mensen die er samen over besluiten: bestuur, architectuur en de teams zelf. Laat ze de vragen eerst onafhankelijk beantwoorden. De waarde zit niet in het afvinken, maar in de plekken waar de antwoorden uiteenlopen.

01

Weten waar je staat

Zolang niemand meet, wint niet het beste argument maar de positie waar je zit.

Stap 1

Meet in plaats van vragen

Vervang “gaat het sneller?” door cijfers uit je eigen pipeline.

Kun je deze vragen niet beantwoorden, dan is dat de uitkomst van fase 1.

Stap 2

Haal de beelden naast elkaar

Laat bestuur, architecten en teams onafhankelijk van elkaar antwoorden. Vergelijk daarna pas.

Het verschil tussen de antwoorden is je agenda.

02

Het harnas inrichten

Van afspraken op papier naar grenzen die het systeem afdwingt.

Stap 3

Classificeer je applicaties en data

Er bestaat geen universeel harnas. Een interne medewerkersapp vraagt om andere kaders dan een systeem dat energie-infrastructuur aanstuurt.

Stap 4

Dwing grenzen technisch af

Regel per toepassing wat het systeem afdwingt, in plaats van wat je opschrijft.

Uit de praktijk

Twee soorten grenzen: guides en sensors

Guides sturen de agent vóórdat hij handelt, sensors observeren en grijpen in nadat hij heeft gehandeld. Een harnas met alleen guides is een beleidsdocument; een harnas met alleen sensors laat de agent eerst de verkeerde kant op werken. Hieronder de mechanismen uit de podcastpipeline van AIToday Live, als voorbeeld van hoe zo'n set eruit kan zien.

Guides — vooraf
  • Gelaagde instructiebestanden: globaal, per project, per module — de agent laadt alleen wat de taak vraagt.
  • Een vastgelegde domeintaal, zodat agent en team dezelfde begrippen gebruiken.
  • Beslisdocumenten die uitleggen waarom een grens bestaat.
  • Pre-goedgekeurde commando's, zodat routinewerk niet vastloopt op een bevestigingsvraag.
  • Vaste workflows voor terugkerend werk: test-first, verplichte review, opruimen na implementatie.
  • Gespecialiseerde subagents met harde limieten: maximaal twee bestanden per run, of uitsluitend leesrechten.
Sensors — achteraf
  • Directe terugkoppeling na elke bewerking, en logging van elk uitgevoerd commando zodat een sessie te reconstrueren is.
  • Een pre-commit gate die modulegrenzen en architectuurregels controleert en de commit blokkeert bij een fout.
  • Mutatietesten voor de push, die blinde vlekken in de testdekking als issue vastleggen.
  • Een herinnering om documentatie bij te werken zodra de code verandert.
  • Een geheugen dat correcties bewaart, zodat dezelfde fout niet terugkeert.
  • Een periodieke review van het harnas zelf: welke correctie kwam vaak terug, en welke regel ontbrak?

Let op de blinde vlek in de review: laat je het werk beoordelen door hetzelfde model dat het schreef, dan delen schrijver en reviewer dezelfde aannames. Een tweede lezer van een andere makelij ziet andere dingen — mits die snel genoeg is om verplicht te kunnen zijn.

Stap 5

Zet je ervaren mensen op de kaders

Het werk dat een agent overneemt is het werk dat je in je eerste jaren leert. Wat overblijft, leer je in tien jaar.

Dit is de stap die het vaakst wordt overgeslagen. Een organisatie zonder scherp vakinhoudelijk oordeel bouwt een harnas dat de verkeerde dingen afdwingt, en merkt dat pas als het misgaat.

03

Ervan leren

Ruim een derde van de IT-beslissers zegt dat teams soms successen delen en zelden mislukkingen.

Stap 6

Deel ook wat misgaat

Een faalpatroon laat je zien welke regel in je harnas ontbrak. Daarmee sluit fase 3 terug aan op stap 4.

De kernvraag

Sneller bouwen vraagt om sterker vakmanschap

Een harnas bouwt zichzelf niet. Iemand moet bepalen welke regels erin horen, en dat is het zwaarste werk in het vak geworden. Wie agents wil opschalen, schaalt eerst het oordeel op waarmee hij ze beoordeelt.

Zou je een nieuwe collega toegang geven tot alle systemen waar jouw agent vandaag bij kan, zonder inwerkperiode en zonder iemand die meekijkt?

Bronnen & verder lezen

Info Support & Markteffect (2026). Agentic Engineering-onderzoek 2026 — Sneller bouwen vraagt om sterker vakmanschap. Onder 330 Nederlandse IT-beslissers.
infosupport.com/resources/sneller-bouwen-vraagt-om-sterker-vakmanschap

Kepinski, W. (2026). Hoe veilig is AI in softwareontwikkeling? Dutch IT Leaders.
dutchitleaders.nl/news/757244

Snijder, J. Doeltreffend met AI-agents. Boom Management, ISBN 9789024474264. Zie de hoofdstukken over testen en over beveiliging voor operationele grenzen, stopcriteria en rechtenbeheer.
managementboek.nl

Perry, N., Srivastava, M., Kumar, D. & Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS 2023, Stanford University.
arxiv.org/abs/2211.03622

Becker, J., Rush, N., Barnes, E. & Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.
arxiv.org/abs/2507.09089