Een AI-agent vier uur zelfstandig laten programmeren: wat 50 iteraties echt opleveren

Er lag bij mij al twee maanden een kleine interne CLI-tool te wachten op onderhoud: gaten in de input-validatie, ontbrekende tests, een paar flags die wel gedocumenteerd maar nooit geïmplementeerd waren, en wat lint-schuld (achterstallige waarschuwingen van de automatische codecontrole). Zo'n 30 kleine taken waarvoor ik nooit een halve dag de tijd had. Vrijwel elk ontwikkelteam heeft zo'n lijstje.

Elke week test ik een AI-onderwerp onder echte omstandigheden. Deze week wilde ik weten of ik dat lijstje kon uitbesteden aan een AI-agent die zelfstandig doorwerkt terwijl ik iets anders doe. Het patroon heet Ralph: je zet Claude Code op een lijst met requirements (in het vak een PRD), stopt dat in een shell-loop en loopt weg. AFK, away from keyboard. De belofte is dat je terugkomt en werkende code aantreft. Ik wilde weten of dat ook echt klopte.

Ik gaf Ralph 50 iteraties en een zaterdagmiddag.

De setup, in 20 minuten

Ralph zelf is nauwelijks een systeem. Er is een PRD.md (het requirements-document met de takenlijst), een progress.txt (wat er al af is) en een shell-loop die Claude Code aanroept met beide bestanden erbij en de opdracht om precies één taak per pass uit te voeren.

Het geheel past op één scherm:

• Docker Desktop met sandboxes ingeschakeld: kleine virtuele machines met een eigen kernel en een eigen bestandssysteem, waarin de agent buiten de gedeelde projectmap niets van mijn laptop kan raken
• claude geïnstalleerd via de native binary
• Een PRD met 30 taken die ik in 15 minuten in de plan-modus van Claude heb gedicteerd
• Een lege progress.txt
• Een loop-script dat claude --permission-mode acceptEdits in print-modus draait, dus zonder interactieve chat, en uitkijkt naar een afgesproken eindsignaal. Bewerkingen aan bestanden gaan in die modus vanzelf door; commando's moeten in de allow-lijst staan, anders weigert Claude ze zonder te vragen

De eerste iteratie draaide in 1m48s en committede een nette verbetering van de testdekking. Ik was bijna geneigd om er meteen mee te stoppen. Het zag er al te goed uit.

Hoe die 50 iteraties er echt uitzagen

Ik liet het 4 uur draaien. De uitsplitsing:

• 34 iteraties: schoon succes. Pakte een taak, implementeerde die, draaide tests, committede. Geen menselijke tussenkomst nodig. Elke commit was klein, atomisch en liet zich probleemloos terugdraaien als ik het er niet mee eens was.
• 6 iteraties: afgedwaald naar aangrenzend werk. Pakte een taak, raakte gaandeweg bestanden aan buiten de scope van de taak. De meeste hiervan heb ik behouden, want het waren oprechte verbeteringen, maar een paar heb ik moeten terugdraaien.
• 5 iteraties: vastgelopen door ontbrekende context. Een taak verwees naar een interne API die ik niet had gedocumenteerd. Claude weigerde terecht om die te verzinnen en stelde een vraag. In een loop betekent "een vraag stellen" zoveel als "een vraag loggen en de iteratie beëindigen zonder te committen".
• 3 iteraties: te groot. Een taak die ik in één regel had opgeschreven ("voeg input-validatie toe") bleek in werkelijkheid drie dagen werk te zijn. Claude implementeerde de helft, committede en ging verder. Die halve implementatie kostte me meer tijd om te herstellen dan wanneer ik het zelf vanaf nul had gedaan.
• 2 iteraties: ronduit fout. Las de PRD verkeerd, implementeerde het tegenovergestelde van wat er gevraagd was. Beide binnen 30 seconden teruggedraaid.

Dus: ~68% schone winst, ~12% nuttige afwijking, ~20% had mijn ingrijpen nodig. Die 20% is het getal om te onthouden.

Waar het echt uitblinkt

De loop is niet overal even sterk in. Dit zijn de drie categorieën waarin hij op zijn best presteerde:

Testdekking aanvullen. Taken van het type "zoek het grootste bestand zonder dekking, schrijf tests tot de dekking boven de 80% uitkomt, commit". De agent leest de coverage-output, kiest een doel, schrijft een testbestand, draait de testsuite, committeert. Van de 12 iteraties met dit patroon slaagden er 11. De dekking van het project ging van 41% naar 78%.

Lint en dode code opruimen. Taken van het type "los de volgende eslint-fout op" of "verwijder de volgende ongebruikte export". Bijna machinaal perfect. Over 8 iteraties ruimde de loop 240 lint-waarschuwingen en 31 ongebruikte exports op.

Gedocumenteerde maar niet-geïmplementeerde features. Taken waarbij de spec al ergens vastlag: in een man page, een --help-blok of een TODO-comment. Claude kon zowel de spec als de omringende code lezen, implementeren en committen. Werkte in 5 van de 6 pogingen.

Het patroon: taken waarbij succes meetbaar is vanuit de repo zelf (tests slagen, lint schoon, dekking omhoog) en waarbij de spec compleet genoeg is om ertegen te toetsen. Ralph draait op feedbackloops: zonder een manier om zijn eigen werk te controleren, kan hij een iteratie niet afsluiten.

Waar het misging

Drie categorieën waarbij ik twee keer zou nadenken voordat ik de loop erop losliet:

Architectuurbeslissingen. Taken die begonnen met "bepaal of..." of "herstructureer X naar Y" gingen slecht. De agent heeft geen context om over iteraties heen een mening te vormen. Hij kiest de meest verdedigbaar ogende optie, implementeert die, en voor je het weet zit je met een refactor die je niet wilde. Ik verloor een iteratie aan de vraag of we de config van JSON naar TOML moesten verplaatsen: hij koos TOML, deed het werk, en ik draaide het geheel terug.

Alles wat dwars door de codebase snijdt. "Voeg telemetrie toe aan alle commands" vereiste dat 12 bestanden coherent werden aangepast. De agent deed 9 daarvan goed en vergat de overige 3. De halfgeïnstrumenteerde staat was erger dan helemaal geen instrumentatie.

Taken met ongeschreven constraints. Interne naamgevingsconventies, ongeschreven securityregels, "we gebruiken hier geen library X": niets daarvan staat in de PRD. De agent installeert zonder aarzelen het package dat volgens zijn eigen inschatting het beste bij de klus past. Ik betrapte één iteratie op het npm install'en van een package dat op de blocklist van de organisatie staat.

Samengevat in één overzicht:

De cijfers waar het mij echt om gaat

Over 4 uur en 50 iteraties:

• 36 commits die ik ongewijzigd heb doorgevoerd
• 8 commits die ik met kleine aanpassingen heb doorgevoerd
• 6 commits die ik heb teruggedraaid
• 0 commits die main braken (de loop draait tests voordat er gecommit wordt)
• API-kosten: $14,20

Het meest verrassende cijfer was de review-tijd. Elke commit kostte mij gemiddeld 80 seconden om te lezen en te accepteren of terug te draaien. Dat is, in elk geval in mijn test, het echte knelpunt van AFK-coding: hoe snel jij kunt beoordelen wat de agent oplevert. Bij een reviewtempo van 80 seconden per commit betekent een loop van 50 iteraties dus ruim een uur reviewen achteraf.

Wat de sandbox tegenhield

Ik draaide het geheel binnen Docker-sandboxes. Twee iteraties probeerden dingen die ik op mijn eigen machine niet had gewild: één draaide een destructief opruimscript voor tests dat een tmp-directory wiste die het niet had mogen aanraken; één probeerde een globale CLI-tool te installeren. Beide werden ingeperkt.

Reken de sandbox tot de basisuitrusting. De schade van één mislukte iteratie op je echte machine weegt zwaarder dan de setuptijd die je bespaart door hem over te slaan.

Wanneer deze zaterdag zich terugbetaalt

De rekensom van mijn zaterdag: $14,20 aan API-kosten en ruim een uur reviewtijd voor een backlog die anders nooit aan de beurt was gekomen. Voor mij loonde dat. Of het bij jou loont, hangt af van wat er al staat.

Het loont nu voor teams die de basis op orde hebben: versiebeheer, een testsuite die iets betekent, en iemand die commits daadwerkelijk leest. Denk aan softwarebedrijven en bureaus met een backlog van kleine, goed omschreven taken die nooit urgent genoeg zijn.

Het loont nog niet bij codebases zonder tests. De loop leunt volledig op controleerbare voltooiingscriteria; zonder testsuite kan de agent niet weten of zijn werk klopt, en jij ook niet. Hetzelfde geldt voor bedrijfskritische systemen waar je geen sandbox omheen kunt zetten, en voor teams waar niemand tijd heeft om 50 commits te reviewen. Een flink deel van de Nederlandse softwareteams die ik tegenkom mist die basis nog. Testdekking, CI en documentatie zijn dan de eerste stap; dat huiswerk vraagt dit patroon toch al van je.

Een realistische eerste stap: neem een kleine, niet-kritieke repo waar de tests al draaien, en zet er een avond de lint- en dekkingsachterstand op. Klok daarbij hoelang je over het beoordelen van elke commit doet. Dat getal bepaalt of dit patroon voor jouw team schaalt, eerder dan de API-rekening.

Wat ik mezelf vooraf had willen vertellen

Drie regels die ik mezelf zou meegeven als ik opnieuw zou beginnen:

1. Maak je taken agressief klein. "Voeg input-validatie toe" is te groot. "Voeg input-validatie toe voor de --port-flag in server.go, met tests" is goed. De PRD is de enige plek waar de agent de taak kan zien. Als de taak in één regel past, past hij ook in één commit.
2. Zorg altijd voor een voltooiingscriterium dat de agent zelf kan checken. Tests die slagen, dekking die omhooggaat, lint die schoon is, types die kloppen. Als succes niet controleerbaar is binnen de repo, kan de agent niet weten wanneer hij moet stoppen.
3. Begroot reviewtijd naast rekentijd. Een loop van $14 die 50 commits oplevert klinkt goedkoop. Een review van 60 minuten daarbovenop verandert de rekensom.

Waar ik uitkom

Ralph vervangt het nadenken niet; het versnelt backlogs waar je al over hebt nagedacht. Liggen er 30 kleine, goed gespecificeerde taken die je hebt uitgesteld, dan is dit de schoonste manier die ik heb gezien om ze weg te werken. Liggen er 3 architecturale beslissingen, dan neemt de loop ze allemaal voor je, en dat pakt slecht uit.

Het meeste debat over tooling rond AI-coding gaat over het model. Ralph laat zien dat de grotere hefboom in de loop zit: wat de agent te lezen krijgt, waar hij mag schrijven en wat hem stopt. Aan het model lag het bij mij geen enkele keer.

Ik laat mijn zaterdagloop volgend weekend opnieuw draaien. Deze keer met een kleinere backlog en een strakkere PRD.