Engineering Reliable Coding Agents: Evaluating and Operating the System Around the Model

Stel je voor dat je naar een goocheltruc kijkt waarbij een robotassistent probeert een kapzaam speelgoedstuk te repareren. Je ziet de robot een schroevendraaier oppakken, een schroef aandraaien, en het speelgoed begint weer te werken. Het lijkt alsof de robot een genie is. Maar wat als de robot eigenlijk gewoon aan het gokken was, en het speelgoed alleen begon te werken omdat er per ongeluk een verborgen veer binnenin op zijn plaats sprong? Of wat als de robot naar een foto van het speelgoed van vorig jaar keek, en niet naar het kapotte exemplaar dat voor hem staat? In de wereld van de informatica, specifiek in het vakgebied van Kunstmatige Intelligentie (AI) en Software Engineering, bouwen we deze "robotassistenten" (genaamd coding agents) die computercode schrijven en repareren. Een tijdlang dachten mensen dat de "hersenen" van de robot — het AI-model — het enige was dat telde. Als de hersenen slim waren, zou de robot betrouwbaar zijn. Maar dit artikel betoogt dat de hersenen slechts één onderdeel zijn van een veel grotere machine. De echte magie (of het echte drama) vindt plaats in het systeem rondom de hersenen: de tools die het gebruikt, het geheugen dat het bijhoudt, de veiligheidscontroles die het doorlowt, en de mensen die toezicht houden. Als het systeem slordig is, zal zelfs het slimste brein falen, en als het systeem solide is, kan een eenvoudiger brein wonderen verrichten.

Dit artikel, geschreven door Stephanie Jarmak, is als een enorme reparatiehandleiding en een gids voor een detective die deze AI-codingsystemen bouwt. De auteur voerde in juli en augustus 2026 een gestructureerd onderzoek uit, waarbij honderden studies, echte engineering-logs en haar eigen experimenten werden geanalyseerd om te achterhalen waarom AI-coding agents soms falen, zelfs wanneer ze op papier geweldig lijken te presteren. De belangrijkste bevinding is een beetje een waarschuwing: Je kunt een AI-coding agent niet beoordelen door alleen naar de eindscore of zijn "hersenen" te kijken. In plaats daarvan moet je naar de hele "harnas" kijken die eromheen zit. Het artikel introduceert een concept genaamd de "betrouwbaarheidsafhankelijkheidsketen" (reliability dependency chain). Denk eraan als een rij dominosteentjes. Als het eerste steentje (de manier waarop succes wordt gemeten) wankel is, zal het tweede steentje (het beoordelingssysteem) omvallen, wat het derde steentje (het herstelplan) omverwerpt, enzovoort. Als een schakel in deze keten zwak is, wordt het hele systeem onbetrouwbaar, ongeacht hoe slim de AI ook is.

Het artikel spreekt zich tegen het idee uit dat we simpelweg de AI-modellen groter en slimmer kunnen maken om alle problemen op te lossen. Het suggereert dat veel "fouten" eigenlijk niet de schuld zijn van de AI, maar worden veroorzaakt door het systeem eromheen. Bijvoorbeeld, als een AI een taak krijgt, maar het systeem geeft het niet de juiste bestanden om te lezen, dan zal de AI falen. Is dat de schuld van de AI? Nee, het is de schuld van het systeem. Het artikel waarschuwt ook tegen het "gamen" van het systeem. Als je een AI test op een reeks puzzels die hij al eerder heeft gezien, kan hij een perfecte score halen, maar dat betekent niet dat hij nieuwe puzzels kan oplossen. De auteur laat zien dat veel publieke scores opgeblazen zijn omdat de AI de antwoorden heeft "onthouden" of omdat de tests niet streng genoeg waren.

Om dit op te lossen, stelt het artikel een nieuwe manier voor om deze agents te bouwen en te testen. Het gaat niet om het vinden van het "perfecte" AI-model; het gaat om het bouwen van een robuuste fabriek. Stel je een fabriek voor waar een robot een auto bouwt. Als de robot een onderdeel laat vallen, mag de fabriek niet doen alsof het niet is gebeurd. De fabriek moet een systeem hebben om de val op te merken, te registreren en opnieuw te proberen zonder de auto te beschadigen. Het artikel biedt een checklist van 206 "betrouwbaarheidsrecords" — in feite regels en tools om ervoor te zorgen dat het systeem veilig is. Deze bevatten zaken als:

• Tests meerdere keren uitvoeren: Net zoals het één keer gooien van een muntje niet vertelt of het eerlijk is, vertelt het één keer draaien van een AI niet of het betrouwbaar is. Je moet het vele malen draaien om te zien of het consistent is.
• De tools controleren: Ervoor zorgen dat de AI geen tools gebruikt die hij niet mag hebben, of dat de tools die hij gebruikt daadwerkelijk werken.
• Menselijk toezicht: Een mens de controle laten uitvoeren, maar alleen op de juiste momenten, zodat de mens niet overweldigd raakt.
• Veilige herstelprocedures: Als de AI crasht of een fout maakt, moet het systeem in staat zijn om te herstarten zonder voortgang te verliezen of meer schade aan te richten.

De auteur is zeer voorzichtig om niet te zeggen dat ze alles hebben "opgelost". Ze geeft toe dat sommige van haar ideeën gebaseerd zijn op sterk bewijs uit experimenten, terwijl andere gebaseerd zijn op logische redeneringen over hoe systemen zouden moeten werken om rampen te voorkomen. Ze beweert niet dat haar regels voor elke AI in de wereld zullen werken, maar ze biedt een solide kader voor ingenieurs om hun eigen systemen te testen. Ze benadrukt dat als je een AI wilt vertrouwen om code te schrijven voor een bank of een ziekenhuis, je niet alleen naar de testscores kunt kijken. Je moet naar de hele machine kijken, de dominosteentjes controleren en ervoor zorgen dat het systeem gebouwd is om fouten veilig af te handelen.

Kortom, dit artikel vertelt ons dat het bouwen van een betrouwbare AI-coder minder gaat over het vinden van een supergeniale robot en meer over het bouwen van een superbetrouwbare fabriek eromheen. Het is een gids voor ingenieurs om te stoppen met gissen en te beginnen met meten, zodat wanneer een AI zegt "Ik heb het gerepareerd", hij ook echt bedoelt "Ik heb het gerepareerd, en ik kan het bewijzen." Het artikel concludeert dat de toekomst van AI-codering niet alleen draait om slimmere hersenen, maar om slimmere, veiligere en eerlijkere systemen die eromheen staan.