💻 computer science

Software Delegation Contracts: Measuring Reviewability in AI Coding-Agent Work

Deze gecontroleerde pilotstudie toont aan dat hoewel expliciete software-delegeringscontracten de objectieve correctheid van de outputs van AI-codeeragenten niet verbeteren, ze de controleerbaarheid van hun werk aanzienlijk vergroten door de bewijsvoering te versterken en ambiguïteit te verminderen, zij het ten koste van een verhoogd tokenverbruik en een langere executietijd.

Oorspronkelijke auteurs: Vincent Schmalbach

Gepubliceerd 2026-06-17

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Vincent Schmalbach

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een manager bent die een zeer slimme, maar soms praatgrage stagiair inhuurt om een lekkende kraan in je huis te repareren.

In het verleden zou je misschien gewoon zeggen: "Hé, repareer dat lek." De stagiair gaat aan de slag, doet het werk en komt terug met een moersleutel en een droge vloer. Je controleert de vloer, deze is droog, en je zegt: "Goed gedaan!"

Maar wat als de stagiair een AI is? En wat als de stagiair, in plaats van alleen de lekkage te repareren, ook de ruimte krijgt om je meubels te verplaatsen, de muren te schilderen of zelfs de gootsteen te verplaatsen, zolang ze het je maar vertellen?

Dit paper stelt een eenvoudige vraag: Als je de stagiair een strikt, schriftelijk "contract" geeft waarin precies staat wat hij wel en niet mag doen en precies welk bewijs hij moet meebrengen, maakt dat het voor jou dan makkelijker om zijn werk te controleren?

De auteur, Vincent Schmalbach, voerde een klein experiment uit om dit te ontdekken. Dit is wat er gebeurde, eenvoudig uitgelegd.

De Opzet: Het "Speelgoed"-huis

De onderzoeker bouwde een piepklein, nep softwareproject (een kleine website) met een paar opzettelijke "bugs" (lekken). Hij creëerde 10 verschillende taken, zoals "fix de login-knop" of "werk de instructies bij."

Vervolgens stuurde hij deze taken naar twee verschillende AI-"stagiairs" (één zeer slimme, één snellere maar iets minder slimme) onder drie verschillende regels:

De Informele Vraag: Gewoon een normaal berichtje met: "Los deze bug op." (Zoals tegen een vriend zeggen: "Repareer de kraan.")
Het Contract: Een formeel document met de tekst: "Je mag alleen deze twee bestanden aanraken. Je mag de database niet aanraken. Wanneer je klaar bent, moet je elk bestand dat je hebt gewijzigd opsommen en uitleggen waarom."
Het Contract + Bewijs-checklist: Hetzelfde contract, maar met een verplichte checklist die de AI moest invullen, inclus kind een sectie over "Wat er nog mis zou kunnen gaan" en een "Reviewer Checklist."

De Resultaten: De "Droge Vloer" versus het "Rapport"

De studie mat twee dingen: Werd het werk daadwerkelijk gedaan? en Was het makkelijk te controleren?

1. Het Werk Was Al Perfect (De "Droge Vloer")
Verrassend genoeg maakte het niet uit welke regel de AI volgde. Of ze nu een informele vraag kregen of een strikt contract, elke AI loste de bugs perfect op.

De "lekkage" was gerepared.
De AI heeft niets anders kapot gemaakt.
De AI heeft geen bestanden aangeraakt die hij niet mocht aanraken.

Waarom? Omdat de taken klein waren en de AI slim genoeg was om ze toch al te begrijpen. Het "contract" maakte de AI niet beter in het oplossen van de code. Het werk was al 100% correct.

2. De Controle Werd Veel Makkelijker (Het "Rapport")
Hier gebeurde de magie. Hoewel de code in beide gevallen perfect was, maakte het Contract het rapport van de AI veel makkelijker voor een mens om te lezen en te vertrouwen.

Zonder het contract: De AI zou de bug oplossen en zeggen: "Gereed." De AI legde zelden uit welke bestanden hij had gewijzigd of waarom. Het was alsoam de stagiair de kraan heeft gerepareerd, maar het gereedschap zonder briefje heeft laten rondslingeren.
Met het contract: De AI leverde een net pakketje aan. Het somde elk gewijzigd bestand op, legde de redenatie uit, vermeldde de tests die het heeft uitgevoerd en gaf zelfs toe: "Hier is een klein risico dat mogelijk nog steeds bestaat."

De Analogie:
Stel je voor dat de AI een chef is.

Geen Contract: De chef brengt je een perfect biefstuk. Je eet hem, en hij is heerlijk. Maar je hebt geen idee of ze verse ingrediënten hebben gebruikt of dat ze hun handen hebben gewassen. Je moet gokken.
Met Contract: De chef brengt hetzelfde perfecte biefstuk, maar brengt ook een bonnetje mee met de ingrediënten, een foto van de keuken, en een notitie: "Ik heb dit 4 minuten gebakken, maar als je hem graag 'rare' wilt, moet je hem misschien langer bakken."
Het Resultaat: De biefstuk smaakte hetzelfde, maar de tweede versie was veel makkelijker te vertrouwen en goed te keuren.

De Kosten: Het Duurt Iets Langer

Het enige nadeel was snelheid en "kosten."

De AI gebruikte ongeveer 13% meer "hersencapaciteit" (tokens) om het rapport te schrijven.
Het duurde ongeveer 38% langer om de taak te voltooien.

Zie het als het betalen voor expressverzending met een gedetailleerde track-and-trace code. Het pakket arriveert rond dezelfde tijd (of iets later), maar je weet precies waar het is en wat erin zit.

De Belangrijkste Conclusie

Het paper concludeert dat voor kleine, duidelijke taken je geen contract nodig hebt om het werk gedaan te krijgen, maar je hebt WEL een contract nodig voor een goede controle.

Correctheid: De AI is al goed genoeg om kleine bugs zelfstandig op te lossen.
Controleerbaarheid: De AI is niet goed in het uitleggen van zichzelf, tenzij je er expliciet om vraagt.

Het "contract" werkt als een vertaler. Het maakt de AI niet slimmer; het dwingt de AI alleen om in een taal te spreken die mensen (of andere AI's) gemakkelijk kunnen begrijpen en verifiëren.

Een Opmerking over de "Zwakkerere" Stagiair

De studie vond dat de "zwakkere" AI (de snellere, goedkopere variant) het meest profiteerde van het contract. De slimmere AI schreef van nature al goede rapporten, maar de zwakkere AI had het contract nodig om gedwongen te worden ze te schrijven. Dit suggereert dat als je goedkopere AI-tools gebruikt, je moet werken met strikte contracten om betrouwbare resultaten te krijgen.

Samenvatting

Maakte het contract de code beter? Nee. De code was al perfect.
Maakte het contract het rapport beter? Ja, een enorm verschil.
Kostte het extra? Ja, een beetje tijd en geld.
Eindoordeel: Als je het werk van een AI wilt vertrouwen, vraag dan niet alleen om de oplossing. Vraag om het contract dat de AI dwingt om zijn huiswerk te laten zien.

Technische Samenvatting: Software Delegatiecontracten in AI Coding-Agent Werk

Probleemstelling
Naarmate AI-codingagents overgaan van interactieve aanvulling naar gedelegeerde uitvoering—het accepteren van taken, opereren binnen begrensde autoriteit en het teruggeven van werkpakketten voor menselijke beoordeling—verschuift de cruciale vraag voor menselijke toezichthouders van "Werkt de patch?" naar "Kan ik dit beoordelen?". Eerder conceptueel werk stelde het software delegatiecontract (gedefinieerd als de tupel van Taak, Autoriteit, Werkpakket en Acceptatiecontext) voor als de eenheid van analyse voor deze relatie. Dit framework miste echter empirische validatie. Dit artikel adresseert deze kloof door te onderzoeken of het expliciet maken van het delegatiecontract de beoordelbaarheid van teruggegeven werkpakketten verbetert en de daarmee gepaard gaande kosten kwantificeert.

Methodologie
De auteurs voerden een gecontroleerde pilotstudie uit met behulp van een doelgericht gebouwde experimentele harness:

Omgeving: Een dependency-vrije TypeScript HTTP API (~600 regels) met 29 tests. Tien taken werden verspreid over vijf families (failing-test fixes, validatiefouten, ontbrekende tests, afgebakende refactors en documentatie-updates), elk met specifieke grondwaarheid-defecten en latente problemen.
Agents: Runs werden uitgevoerd met twee modeltiers (Claude Sonnet 4.6 en Haiku 4.5) binnen een begrensde sandbox (geen netwerk, geen externe dependencies, geen commits).
Condities: 64 totale runs werden verdeeld over drie condities:
1. Baseline (A): Een realistische, issue-stijl prompt met natuurlijke scope-hints.
2. Expliciet Contract (B): Een gestructureerd document dat doelstellingen, niet-doelen, autoriteitsgrenzen en vereiste bewijslast definieert.
3. Contract + Bewijsbundel (C): Conditie B plus een verplichte template voor het werkpakket (inclusclusief residuele risico's en reviewer-checklists).
Evaluatie:
- Mechanische Scoring: Geautomatiseerde controles op verborgen acceptatietests, mutation testing (het injecteren van defecten om nieuwe tests te verifiëren) en scope-schendingen.
- Blinde Beoordeling: Drie onafhankelijke, op modellen gebaseerde reviewers (Sonnet 4.6) scoorden elk werkpakket op een vaste rubric (192 totale reviews) die de deugdelijkheid van bewijs, ambiguïteit, scope-compliance en vertrouwen besloeg. Reviewers waren blind voor de conditie-labels.
- Analyse: Gepaard gaande statistische analyse (Wilcoxon signed-rank, Cliff's delta) vergeleek Baseline versus Contract-condities.

Belangrijkste Resultaten

Objectieve Uitkomsten Verzadigden: Alle 64 runs slaagden voor verborgen acceptatietests en mutation tests. Er traden geen scope-schendingen op in enige conditie. Bij kleine, goed gespecificeerde taken met capabele modellen verbeterde het expliciete contract de correctheid van de code niet; beide condities bereikten bijna perfect objectief succes.
Beoordelbaarheid Verbeterde Significant:
- Voldoende Bewijslast: Verbeterde met +0,83 punten (op een 5-puntsschaal) in 22 van de 30 gepaarde vergelijkingen, zonder verslechterende gevallen ( $p < 0,0001$ , Cliff's $\delta = 0,66$ ).
- Ambiguïteit: Nam significant af ( $p = 0,035$ ).
- Gestructureerde Elementen: Onder de contract-condities verschenen gestructureerde elementen bijna uitsluitend wanneer daarom gevraagd werd. Bijvoorbeeld, "Gewijzigde bestanden vermeld met redenen" steeg van 7% (Baseline) naar 93% (Contract), en "Bekende beperkingen" steeg van 0% naar 80%. Cruciaal was dat "Residuele risico's" en "Reviewer-checklists" in 0% van de Baseline-runs voorkwamen, maar in 100% van de runs waar de bewijsbundel hen expliciet eiste.
Kostenoverhead: Het expliciete contract bracht meetbare kosten met zich mee:
- Agent-tokens namen toe met 13%.
- Wandklok-tijd nam toe met 38%.
- Tool-invocaties namen toe met 23%.
- Patch-grootte nam toe met 44,7% (voornamelijk gedreven door extra tests, niet door productiecode-wijzigingen).
Model Tier Effecten: Het voordeel van contracten was ongeveer twee keer zo groot voor de zwakkere modeltier (Haiku), wat suggereert dat contracten de rapportage-discipline die sterkere modellen ongevraagd vertonen, gedeeltelijk substitueren.

Belangrijkste Bijdragen

Experimentele Harness: Een herbruikbaar framework voor delegatie-contractstudies, voorzien van een repository met seeded taken, gepaarde prompts, verborgen acceptatie/mutation checks en een blinde review-pipeline.
Empirische Vergelijking: De eerste gepaarde vergelijking van prompt-alleen versus contract-gebaseerde delegatie, resulterend in 64 runs en 192 blinde reviews.
Mechanisme Validatie: Bewijs dat delegatiecontracten primair fungeren als een beoordelingsmechanisme in plaats van een correctiemechanisme voor kleine taken.
Design Defaults: Concrete aanbevelingen voor agent-harness bouwers, zoals het verplicht stellen van "gewijzigde-bestanden-met-redenen" lijsten en "bekende-beperkingen" secties, terwijl de ~15% token en ~40% latentie overhead wordt erkend.

Significantie en Claims
Het artikel concludeert dat voor kleine, goed gespecificeerde taken die door capabele modellen worden afgehandeld, de marginale opbrengst van een expliciet contract op uitkomstkwaliteit nul is omdat uitkomsten al verzadigd zijn. Echter, de opbrengst op bewijslast is groot en uniform. De auteurs stellen dat het delegatiecontract een controlelaag is die het werkpakket (het artefact dat voor beoordeling wordt gepresenteerd) meer vormgeeft dan het werk (de code zelf).

De studie stelt dat "bewijs elastisch is aan de vraag": agents leveren niet spontaan de volledige context die nodig is voor beoordeling (bijv. residuele risico's, checklists) tenzij ze daar expliciet voor gecontracteerd zijn. Daarom, om een software-delegeerder bruikbaar te maken, moet het werk beoordelbaar zijn, en het delegatiecontract is een praktisch instrument om die beoordelbaarheid te waarborgen. De auteurs merken op dat toekomstige iteraties zwaardere taken moeten testen waarbij baseline-runs zouden kunnen falen of afwijken, om de impact van het contract op autoriteitscontrole en foutreductie te meten.