Loop Engineering: Optimalisatie van Codegeneratie en Verificatie

Een praktische kaart voor AI-ondersteunde ontwikkeling: kwalificeer kandidaten voor menselijke beoordeling, verminder verspilde arbeid binnen de build-loop en meet welke controles en correcties hun kosten waard zijn.

AI-ondersteunde codegeneratie kan de tijd die nodig is om code te produceren verkorten, terwijl de hoeveelheid werk die nodig is om deze te begrijpen en te verifiëren toeneemt. Dit artikel beschrijft hoe processen ontworpen kunnen worden die menselijke tijd, aandacht en oordeelsvermogen behouden: verbeter het proces dat kandidaten voor evaluatie ontwikkelt en organiseer het bewijs dat mensen nodig hebben om deze te beoordelen.

Wat u zult leren

• Het behoud van menselijke tijd, aandacht en oordeelsvermogen.
• Het onderscheid tussen capaciteit (capability) en betrouwbaarheid (reliability).
• Het omzetten van specificaties in onafhankelijke controles en afgedwongen stopregels.
• Het voorbereiden van agents op succes door bruikbare context, werkende tools en overdrachten (handoffs) te leveren.
• Het detecteren van fouten en het verifiëren van reparaties door terugkerende faalmodi om te zetten in gerichte controles.
• Het vergemakkelijken van menselijke review door vereisten, code, controleresultaten en onopgeloste vragen samen te brengen.
• Het meten van welke controles hun kosten rechtvaardigen door tijd, tokens en menselijke inspanning te vergelijken.

---

Inleiding

Twee fundamentele uitdagingen bij AI-ondersteunde softwareontwikkeling zijn het nauwkeurig en volledig specificeren van de intentie, en het verifiëren dat de gegenereerde code aan die specificatie voldoet. Dit artikel richt zich primair op het tweede deel van die vergelijking: het verifiëren van de code die door AI is geschreven.

AI-ondersteunde codegeneratie kan in dezelfde hoeveelheid tijd veel meer code produceren. Een NBER-working paper over meer dan 500.000 GitHub-ontwikkelaars schatte dat interactieve coding agents in de weken 21–30 na adoptie de wekelijkse wijzigingen in regels code met 958% en het aantal aangemaakte PR's met 86% verhoogden, terwijl de wekelijkse repository-releases met 20% toenamen. Echter, het schrijven en testen van code wordt geschat op slechts ongeveer 25–35% van de tijd van het eerste idee tot de productlancering (Bain). Hoe beïnvloedt het sneller genereren van meer code de rest van de software development lifecycle (SDLC)?

Het leveringsprobleem

Snellere generatie is slechts één onderdeel van de levering:

1. Genereren: AI produceert een kandidaat.
2. Begrijpen: Mensen reconstrueren wat er is veranderd en waarom.
3. Verifiëren: Controles en reviews stellen vast wat het bewijs ondersteunt.
4. Release: Integreren, implementeren en observeren van de geaccepteerde wijziging.

Dit artikel richt zich op het verminderen van het werk tussen een gegenereerde kandidaat en een geïnformeerd acceptiebesluit.

De verificatie-bottleneck

Snellere en goedkopere codegeneratie kan nieuwe bottlenecks creëren of bestaande verergeren in downstream-processen. Verificatie wordt om vijf redenen zwaarder:

1. Meer code arriveert sneller dan mensen het kunnen reviewen. Een agent kan duizend regels produceren in minder tijd dan het kost om deze paragraaf te lezen, terwijl de menselijke leessnelheid niet is veranderd. Telemetrie van Faros associeerde een hoge AI-adoptie met 98% meer samengevoegde PR's en 91% langere reviewtijden (Faros 2025). In een grotere dataset uit 2026 steeg het aantal PR's dat zonder enige review (menselijk of agent-gestuurd) werd samengevoegd met 31,3%, wat waarschijnlijk komt doordat reviewers het tempo niet konden bijhouden (Faros 2026).
2. Incorrecte code ziet er nog steeds zeer plausibel uit. Het vinden van fouten vereist mogelijk meer tijd voor het traceren van wijzigingen over bestanden en het vergelijken van gedrag met de vereisten (JetBrains–Lund studie). In een enquête van Sonar (2026) was 61% van de ontwikkelaars het ermee eens dat AI code kan produceren die correct lijkt maar onbetrouwbaar is. Een METR-studie uit begin 2025 identificeerde tijd besteed aan het reviewen, testen en repareren van onbetrouwbare AI-output als een factor die de taakvoltooiing vertraagt.
3. Begripsschuld (Comprehension debt). Als niemand in het team de implementatie heeft geschreven, begint de review zonder het begrip dat een menselijke auteur normaal gesproken zou meebrengen. Osmani noemt dit gat tussen code en menselijk begrip "begripsschuld" en merkt op dat het lezen van elkaars diffs voorheen bijdroeg aan de kennis van het systeem. In een Anthropic-test met 52 engineers die een nieuwe bibliotheek leerden, voltooiden degenen die AI-assistentie gebruikten de taak in ongeveer dezelfde tijd, maar scoorden ze 17 procentpunten lager (50% versus 67%) op een comprehension-quiz.
4. Wijzigingen zijn groter en bevatten meer problemen. Faros associeerde AI-adoptie met een toename van 154% in de gemiddelde PR-grootte en een toename van 9% in bugs per ontwikkelaar (Faros 2025), waarbij de dataset van 2026 die laatste figuur op 54% stelt. CodeRabbit vond in een studie naar 470 open-source PR's dat AI-co-authored wijzigingen gemiddeld 1,7 keer meer problemen per PR bevatten.
5. De controles zijn ook onbetrouwbaar. Tests en statische analyse helpen, maar niemand kan een test schrijven voor gedrag dat ze niet hebben gespecificeerd. Wanneer een AI het gedrag wijzigt en honderden tests aanpast om hiermee overeen te stemmen, verschuift de vraag van "is deze code correct?" naar "waren deze testwijzigingen noodzakelijk?" (Osmani). Een geslaagde testsuite kan dus betekenen dat de tests zijn herschreven om met de code overeen te stemmen. Daarom moeten de controles en verwachte resultaten van de evaluator buiten de bevoegdheid van de builder vallen.

---

1. Terminale Evaluatie

Wat is terminale evaluatie?

Terminale evaluatie beoordeelt uitsluitend het resultaat van een autonome poging. Gegeven een taak en de succescriteria, werkt een AI-systeem autonoom totdat het gelooft dat het een resultaat heeft gegenereerd dat aan de vooraf gedefinieerde criteria voldoet. Vervolgens controleert een evaluator dat resultaat aan de hand van de criteria. In een coding-workflow is het resultaat een "kandidaat" en zijn de criteria de overeengekomen specificatie. Het verdict kan 'geslaagd' of 'gezakt' zijn, een score met gedeeltelijke punten, of meerdere scores. Het uiteindelijke verdict vertelt ons of het resultaat aan de criteria voldeed, maar niets over hoe het systeem daar is gekomen.

Dit verdict stelt ons in staat om twee verschillende vragen te stellen:

• Capaciteit (Capability): Kan dit geconfigureerde systeem de taak uitvoeren? Een succesvol resultaat toont aan dat dit kan onder de geteste omstandigheden.
• Betrouwbaarheid (Reliability): Hoe consistent slaagt het? Door de taak onder vergelijkbare omstandigheden te herhalen, kunnen we die consistentie schatten. Een systeem dat één keer slaagt, verschilt fundamenteel van een systeem dat in 99 van de 100 pogingen slaagt.

Beide vragen hebben betrekking op een geconfigureerd systeem, niet alleen op een model. De configuratie omvat het model van de leverancier en de harness (samen de agent van de leverancier) en alles wat wij toevoegen: een aangepaste harness, tools, context, operationele limieten, een graph of een pipeline.

Variaties op een thema

Agent-gebaseerde benchmarks (evals), prompt engineering, specification-driven development (SDD) en loop engineering zijn vier variaties op hetzelfde basisproces: geef de AI een taak, laat het de taak autonoom proberen en evalueer vervolgens het resultaat. Elke variatie legt de nadruk op andere delen van dat proces.

Het conformiteitscontract coöperatief schrijven

In onze coding-workflow keuren mensen de verplichtingen vóór de run goed en beslissen ze of ze een gekwalificeerde kandidaat daarna samenvoegen (merge). Mensen en AI kunnen samenwerken om intenties te vertalen naar verplichtingen: wat de code moet doen, moet behouden en nooit mag toestaan. Dit noemen we het conformiteitscontract. Hoe nauwkeuriger de intentie is gespecificeerd, hoe kleiner de kans dat fouten door de evaluator glippen.

Verplichtingen omzetten in controles

Elke verplichting heeft een manier nodig om conformiteit te beoordelen. Mensen en AI ontwikkelen de controles, verwachte resultaten en bewijseisen voordat de constructie begint. Testen, abstract syntax tree (AST) checks en runtime-observaties kunnen bewijs leveren. Een controle die zowel de beoogde implementatie als een defecte implementatie goedkeurt, is waardeloos. Het contract en de autoritatieve controles blijven vaststaan tijdens een run; een AI-agent mag deze nooit stilzwijgend wijzigen.

Een kandidaat evalueren

Wanneer de constructie een kandidaat teruggeeft, roept controller-code een onafhankelijke evaluator aan. De evaluator leeft buiten de build-loop. Zijn controles, verwachte resultaten en stopregels liggen buiten de bevoegdheid van de builder.

De stopcondities bepalen het vervolg:

• Een kandidaat die aan de kwalificatie-eisen voldoet, gaat naar menselijke review.
• Een afgewezen kandidaat keert terug naar constructie, mits er retries over zijn.
• Uitgeputte retries stoppen de run zonder gekwalificeerde kandidaat.
• Ondubbelzinnigheden die menselijk oordeel vereisen, pauzeren het proces.

Kwalificatie-stappen:

1. Stel de verplichting vast: Wat moet de code doen, behouden en nooit toestaan?
2. Oefen de verplichting uit: Welke controles maken onderscheid tussen conform gedrag en een schending?
3. Bind het bewijs: Welke kandidaat is gecontroleerd, wat is er uitgevoerd en wat blijft ongeverifieerd?

Menselijke review

Zodra de evaluator een kandidaat kwalificeert, moet de mens beslissen of deze wordt geaccepteerd. Hier betalen de vooraf voorbereide controles zich terug. Wat deterministisch geverifieerd kan worden (tests, AST checks), hoeft de reviewer niet opnieuw af te leiden.

De AI stelt een overzicht samen voor elke verplichting, waarin de verplichting zelf, de controles en hun resultaten, de gegenereerde code en onopgeloste vragen worden gebundeld. Hierdoor kan de reviewer zijn aandacht richten op claims die menselijk oordeel vereisen, in plaats van het bewijs vanaf nul te moeten reconstrueren.

Voorbeeld: een opslag-leesfout (storage-read failure)

Stel een applicatie voor die geen eerder opgeslagen gegevens kan lezen. Het contract vereist dat de applicatie de fout rapporteert én de originele gegevens behoudt. Een kandidaat die de fout rapporteert maar de gegevens overschrijft met een lege lijst, voldoet slechts aan de helft van de verplichting. De evaluator moet beide aspecten controleren.

Wat terminale resultaten onverklaard laten

Wanneer we alleen naar terminale resultaten kijken, behandelen we het proces als een black box. Een succesvol verdict zegt niets over of het systeem foutloos werkte of dat het meerdere fouten maakte en herstelde. Terminale verdicts hebben een lage diagnostische resolutie. Om dit te begrijpen, moeten we de trajecten, robuustheid en de gevolgen van falen onderzoeken.

Gedachte-experiment: perfecte evaluatie Stel dat het conformiteitscontract alle intenties volledig vastlegt en de evaluator perfect is. Alleen correcte code kan dan worden gekwalificeerd. Zelfs met deze perfecte poort kan het build-proces fouten maken en werk verspillen voordat het een correcte kandidaat produceert. De vraag wordt dan: wat zou vroege detectie en correctie besparen aan tijd, tokens en menselijke aandacht?

---

2. Engineering van de Inner Loop

Binnen de build-loop plant, schrijft, controleert en herviseert een agent (of pipeline/graph) om code te construeren die aan de specificaties voldoet. We onderscheiden twee bronnen van fouten:

Bron van fout	Voorbeeld (Opslag-leesfout)	Oorsprong	Hoofdrespons
Omgeving (ontbrekende vereisten)	De planningsfase krijgt verplichting TD-08 niet door of weet niet dat data onleesbaar kan zijn.	Hoe een fase is ingericht: verplichtingen, context, tools en overdrachten.	Voorkomen door de fase voor succes in te richten. Detecteren door te inspecteren wat de fase daadwerkelijk bereikte.
Agent-faalmodus (fout ondanks info)	De planningsfase heeft de verplichting en feiten, maar plant toch om onleesbare data te vervangen door een lege store.	De eigen beslissingen en acties van de agent in een fase.	Blootstelling verminderen via werkorganisatie, observeren, op het juiste punt controleren en corrigeren.

Drie activiteiten om de weg naar een kandidaat te verbeteren

Activiteit 1: Zet de fase(s) in voor succes (PREPARE)

Een "fase" is één eenheid werk (een stap in een sessie, een rol in een pipeline of een node in een graph).

• Geef elke fase wat het nodig heeft: Duidelijke verantwoordelijkheid, relevante verplichtingen, accurate API-kennis en geschikte tools.
• Ontwerp fasen en overdrachten bewust: Stel voor elke fase vijf vragen vast: waar is het verantwoordelijk voor, wat moet het weten, wat mag het wijzigen, wat moet het retourneren, en wat gebeurt er als het niet kan voltooien?
• Bereid de overdracht voor:

1. Verantwoordelijkheid: Welk besluit of artefact moet deze fase produceren?
2. Inputs: Welke verplichtingen, feiten en tools zijn nodig?
3. Autoriteit: Wat mag het wijzigen en wat moet het escaleren?
4. Output: Wat moet de volgende fase ontvangen (incl. onopgeloste vragen)?

Activiteit 2: Observeer wat er gebeurt (CHECK)

Maak onderscheid tussen ontbrekende vereisten en agent-fouten. Een agent-faalmodus is een terugkerend patroon van incorrecte beslissingen ondanks voldoende kennis.

• Observeer voordat u intervenieert: Draai een voorgestelde detector in "observatiemodus": registreer bevindingen zonder de constructie te wijzigen. Dit onthult of een signalering een echt defect betreft of een vals alarm.

Activiteit 3: Intervenieer wanneer het bewijs dit rechtvaardigt (DECIDE & CORRECT + VERIFY)

Voorbeeld van een interventie in de opslag-leesfout: De planningsagent negeert de eis om data te behouden (een "unfaithful handoff").

1. Interventie: Vergelijk de voorgestelde planning met de bronverplichtingen voordat de implementatie begint.
2. Correctie: Als de omissie is bevestigd, herstel de planning en repareer alle afgeleide implementaties of tests.
3. Verificatie: Test het gedrag met vier representatieve faalgevallen (bijv. onondersteunde versie, foutieve data-types). Bevestig dat de correctie werkt en dat de controle ook daadwerkelijk een defecte versie zou afwijzen.

Een controle heeft een doel en een respons nodig:

• Target: Definieer de observeerbare fout en het punt waarop deze vastgesteld kan worden.
• Response: Specificeer de toegestane reparatie, onderzoek of escalatie.
• Validation: Test op gemiste fouten, valse alarmen en ineffectieve reparaties.

---

3. De Learning Loop

De learning loop gebruikt bewijs van zowel succesvolle als gefaalde runs om verbeteringen aan het proces aan te bevelen.

Bronnen van bewijs

Bron	Bewijs dat het levert
Menselijk ontwerp	Versioneerd contract, rationale, aannames en mapping van verplichtingen naar controles.
Build loop	Inputs/outputs per fase, controleresultaten, interventies, reparaties, tijd- en tokengebruik.
Externe evaluatie	Bevindingen per verplichting, afgewezen kandidaten, stopregels en evaluatiekosten.
Menselijke review	Reviewtijd, gestelde vragen, beslissing en rationale.
Na release	Defecten, regressies en incidenten die worden teruggeleid naar de wijziging.

Hoe bewijs een aanbeveling wordt

1. Reconstrueer wat er gebeurde: Traceer elk probleem naar de vroegste fout en de omstandigheden die hiertoe bijdroegen.
2. Koppel het probleem aan kandidaat-wijzigingen: Gebruik algemene principes of de faalmodus-catalogus.
3. Stel een begrensde wijziging voor: Formuleer een hypothese en bepaal welk bewijs tegen de hypothese zou spreken.
4. Test en beveel aan: Vergelijk uitkomsten en kosten. Een mens keurt de wijziging goed.

De processen vergelijken

Om te bepalen of een controle zijn kosten waard is, worden vier vragen onafhankelijk beantwoord:

1. Vond er een fout plaats? (Inspecteer de historie onafhankelijk van de detector).
2. Vond de controle het? (Tel misses en valse alarmen).
3. Werkte de reparatie? (Verifieer de betreffende verplichtingen).
4. Verbeterde de run als geheel? (Vergelijk voltooiing, totale kosten, menselijke inspanning).

De boekhouding moet bevatten:

• Detectie: Bevestigde incidenten per kans, gemiste fouten, valse alarmen en snelheid van detectie.
• Totale kosten: Voorbereiding, coördinatie, elke aanroep van de controle, correctie en re-checking.
• Uitkomsten: Voltooiing binnen budget, regressies en ontsnapte defecten.
• Menselijke inspanning: Supervisie, verduidelijking en reviewtijd.

Herkwalificatie

Een sterkere agent kan veranderen welke ondersteuning zinvol is. Een nieuwe modelversie kan bepaalde faalmodi oplossen, waardoor specifieke controles overbodig worden ("het model eet de harness").

Het proces van herkwalificatie:

1. Herhaal vergelijkbaar werk: Behoud taken, acceptatiecriteria en limieten.
2. Test ondersteuning aan en uit: Onderscheid verbetering in de agent van verbetering door het mechanisme.
3. Neem een gescopeerde beslissing: Behoud, vernauw, reviseer of retireer de ondersteuning op basis van uitkomsten en kosten.

De uiteindelijke output is een aanbeveling gekoppeld aan bewijs. Menselijke goedkeuring sluit de learning loop. De focus blijft: vermindering van tijd en tokens om tot een conform kandidaat te komen, en het verbeteren van het bewijs voor menselijke review.