Een eindtoets
Waaraan lees jij af dat het klaar is? Een test die faalt zolang het niet werkt, is de enige instructie die een agent niet kan wegredeneren.
Een agent een uur laten doorwerken
Tot vorig jaar vroeg je een AI om een regel af te maken. Nu geef je hem een taak en loopt hij een uur door: lezen, plannen, schrijven, testen, opnieuw. Dat verschuift het werk van typen naar opdragen — en het legt de fout ergens anders neer dan je gewend bent.
01/10
Wat er precies veranderd is
Niet de kwaliteit van het antwoord, maar de lengte van de lus.
Een assistent die je code aanvult, werkt binnen één beurt: jij typt, hij stelt voor, jij accepteert. Een agent werkt in een lus. Hij leest je project, bedenkt een plan, voert stappen uit, draait tests, leest de uitkomst en corrigeert zichzelf. Die lus kan tientallen rondes duren zonder dat jij ertussen zit.
Dat is een ander soort gereedschap dan het eruitziet. Je levert geen zin meer aan maar een opdracht, en je krijgt geen suggestie terug maar een reeks wijzigingen die al is uitgevoerd. De vraag verschuift van 'is dit een goede regel code' naar 'klopt wat hier in het afgelopen uur is gebeurd'.
Wie dat verschil negeert, gebruikt een agent als een snellere autocomplete en loopt tegen precies één probleem aan: er is te veel tegelijk veranderd om nog te kunnen beoordelen.
02/10
Wat het kost als je hem laat lopen
Een lus die doordraait, rekent door.
Bij afrekenen per gebruik is de rekening van een agent niet de som van jouw vragen maar van zijn eigen rondes. Eén opdracht van jou kan tien interne stappen zijn: bestanden lezen, een test draaien, de uitvoer terugleggen, opnieuw proberen. Dat is precies waar de winst zit als het goed gaat, en waar het geld weglekt als hij in een lus belandt.
Het patroon dat je wilt herkennen: de derde poging komt niet dichter bij een oplossing dan de tweede. Op dat moment is doorgaan zelden het antwoord. Wat wel helpt is stoppen, opschrijven wat er precies moet gebeuren en waaraan je het afleest, en opnieuw beginnen met een schoon gesprek.
Er is ook een saai maar effectief middel: zet een plafond in bij je aanbieder voordat je begint. Bijna iedereen verbruikt in de eerste weken meer dan verwacht, simpelweg omdat het formuleren van goede opdrachten iets is dat je nog moet leren.
03/10
Wat je vastlegt voordat je hem loslaat
Een speelveld
Welke mappen mag hij aanraken en welke niet. Hoe groter het veld, hoe groter de kans dat hij iets omgooit dat al af was.
Een terugweg
Leg je werk vast vóór je hem start. Niet als mijlpaal maar als uitweg; je hebt hem vaker nodig dan je denkt.
04/10
Waar een lange lus op stukloopt
- Een opdracht zonder eindtoets. De agent blijft poetsen aan iets dat allang goed was, en bij afrekenen per gebruik betaal je voor dat poetsen.
- Een test die traag is. Als een ronde vijf minuten kost, doet hij er in een uur twaalf. Snelle tests zijn bij agentwerk geen luxe maar de brandstof.
- Een omgeving die hij niet kan draaien. Kan hij niet uitvoeren wat hij schrijft, dan valt de belangrijkste terugkoppeling weg en gokt hij.
- Een taak die eigenlijk een ontwerpvraag is. Wat er moet gebeuren is geen agentwerk; hoe het moet gebeuren wel.
05/10
Hoe je een uur werk nakijkt
Niet regel voor regel, maar van buiten naar binnen.
Begin bij het resultaat, niet bij de code. Werkt het? Doen de tests wat ze moeten? Pas als het antwoord ja is, wordt het interessant om te kijken hóé. Andersom lees je driehonderd regels van iets dat misschien niet eens draait.
Kijk daarna naar de omvang van de wijziging. Een agent die voor een kleine taak twintig bestanden heeft aangeraakt, heeft iets anders begrepen dan jij bedoelde. Dat is een signaal om terug te gaan naar de opdracht in plaats van de code te repareren.
En zoek gericht naar de dingen die een agent structureel verkeerd doet: dubbel werk onder een andere naam, een hulpfunctie die al bestond, een instelling die hij hard heeft ingetypt. Dat vind je met zoeken, niet met lezen.
06/10
Wat je aan de agent zelf kunt overlaten
Zijn eigen werk nakijken doet hij verrassend goed.
Een tweede ronde waarin je vraagt om de wijziging kritisch te lezen, haalt er meer slordigheden uit dan je zou verwachten. Niet omdat het model dan ineens beter is, maar omdat de opdracht anders staat: beoordelen in plaats van produceren.
Wat je daarbij kunt vragen: waar wijkt dit af van hoe de rest van het project is opgebouwd, welke aannames zitten er in die nergens staan opgeschreven, en wat gebeurt er als de invoer niet klopt. Dat zijn drie vragen die een mens ook zou stellen en die een agent zelden uit zichzelf beantwoordt.
Wat je er níet aan kunt overlaten: de vraag of dit is wat je wilde. Een agent kan controleren of iets consistent is met wat er al staat. Of het het juiste probleem oplost, weet alleen jij.
07/10
Wanneer je hem juist kort houdt
Wel zinvol
- Een taak die je in één zin kunt beschrijven met een duidelijk einde
- Werk in een gebied dat je zelf goed kent
- Iets waarvoor tests bestaan of snel te maken zijn
Niet zinvol
- Een probleem dat je zelf nog aan het uitdenken bent
- Werk aan een scherm waar je bij elke stap wilt kijken
- Een codebase die je nog niet vertrouwt
08/10
Wat het je oplevert als het wel goed gaat
De winst zit niet in sneller typen. Hij zit erin dat je meerdere dingen tegelijk kunt laten lopen zonder ze allemaal in je hoofd te houden: terwijl de agent een koppeling schrijft, denk jij na over wat er daarna moet gebeuren.
Voor werk dat je goed kunt beschrijven — een integratie, een migratie, een set tests aanvullen — is dat een echte verandering. Voor werk waarin de vraag zelf nog niet vaststaat, is het gereedschap dat sneller de verkeerde kant op rent.
Het praktische advies dat daaruit volgt: gebruik een agent voor het deel dat af te bakenen is, en houd het denkwerk bij jezelf. Dat klinkt als een compromis en het is de manier waarop dit gereedschap het meest oplevert.
09/10
Wat dit betekent voor een bouwdag
Op een dag waarin een idee klikbaar moet worden, is voorspelbaarheid belangrijker dan maximale kracht. We laten agents het werk doen dat scherp te beschrijven is en houden de productkeuzes bij ons, omdat die niet met een prompt terug te draaien zijn.
Wat daarbij helpt: kleine opdrachten met een duidelijk einde, en na elke opdracht kijken voordat de volgende begint. Dat voelt trager dan een agent een half uur laten lopen, en het levert aan het eind van de dag meer op dat je durft te laten zien.
10/10
Veelgestelde vragen
Hoe lang laat je een agent maximaal doorlopen?
Zolang je de uitkomst nog kunt beoordelen. Voor de meeste mensen is dat een taak van tien tot dertig minuten. Daarboven wordt het nakijken zelf een klus die langer duurt dan zelf bouwen.
Kan ik hem 's nachts laten draaien?
Technisch wel. Praktisch loopt hij dan vast op het eerste punt waar hij een keuze moet maken die niet in de opdracht staat, en heb je 's ochtends een half afgemaakte wijziging waarvan je niet weet waar hij is gestopt.
Moet ik alles laten testen voordat ik begin?
Nee, maar wel het deel dat de agent raakt. Eén test die faalt zolang het niet werkt, is meer waard dan een compleet testpakket dat je nooit afkrijgt.
Wat als hij halverwege iets kapotmaakt?
Dan wil je dat je kunt terugvallen op de staat van vlak voor de opdracht. Dat is de reden om vooraf vast te leggen, en het is de enige maatregel die altijd werkt.
Werkt dit ook op een codebase die met AI is gebouwd?
Meestal beter dan op een codebase die in vijf jaar door drie mensen is gegroeid, omdat AI-code consistenter van stijl is. Het probleem is eerder dat er weinig tests in zitten, waardoor de agent niet kan controleren of hij iets sloopt.
Hoeveel scheelt het echt?
Voor afgebakend werk merkbaar, voor verkennend werk weinig tot niets. De eerlijkste maat is niet hoe snel er iets ontstaat, maar hoeveel je zelf moest corrigeren voordat je het durfde te gebruiken.
