Waarom Losjes AI Gebruiken Een Recept Voor Ellende Is

Laat me een bekend plaatje schetsen. Het is 23:00. Je hebt een feature om af te leveren, en je bent al een uur aan het ping-pongen met een AI coding assistant. Elke prompt levert een antwoord op. Elk antwoord plak je in. Sommig werkt. Sommig niet. Je weet niet precies wat wat is.

Herkenbaar?

Hier is de ongemakkelijke waarheid: de meeste developers gebruiken AI agents alsof je een rekenmachine gebruikt, maar zelf de knoppen moet indrukken. Ja, het rekent. Nee, je hebt geen flauw idee wat er intern gebeurt. En wanneer het onvermijdelijk iets geeft dat plausibel klinkt maar subtiel kapot is, zit jij om middernacht met de debugs.

De teams die wél echte productiecode leveren met AI hebben iets anders doorgrond. Ze zijn gestopt met denken dat AI-assistentie een vraag-antwoordspelletje is. In plaats daarvan bouwen ze systemen — loops — die AI in staat stellen om kleine, veilige, verifieerbare wijzigingen door te voeren. De resultaten spreken voor zich: minder regressies, geen context-overflow, en diffs die je daadwerkelijk kunt lezen.

Het Probleem Met Alles-In-Één-Keer

Er is een verleidelijke eenvoud aan one-shot prompting. "Schrijf me een gebruikersauthenticatiesysteem." Klaar. "Refactor deze hele module naar de nieuwe API." Boem. Het voelt productief. Het voelt snel.

Totdat het dat niet meer doet.

Denk eens na over wat er eigenlijk gebeurt wanneer je een grote taak in één keer aan AI geeft. Eerst loop je tegen de contextmuur aan. De meeste codebases die de moeite waard zijn om aan te werken passen niet volledig in het geheugen van een AI. Dus begint het te gissen naar de delen die het niet kan zien — aannames over dependencies, naamgeving, architectuurpatronen die compleet verkeerd kunnen zijn.

Dan komt het reviewprobleem. Als de AI een diff van 500 regels teruggeeft, wat doe je daar dan mee? Je scannt het. Je vertrouwt het meer dan zou moeten, omdat de AI zelfverzekerd overkomt. Je merged het en hoopt het beste.

Het ding over hopen: het is geen kwaliteitscontroleproces.

Het derde probleem is het slimste. AI-modellen zijn getraind om behulpzaam te zijn, wat betekent dat ze getraind zijn om zelfverzekerd te klinken. Wanneer een AI je code geeft die redelijk oogt, oogt hij waarschijnlijk redelijk omdat het getraind is op redelijke code. Dat betekent niet dat het correct is voor jouw specifieke context. Zonder een poort die daadwerkelijk gedrag controleert, wordt zelfverzekerdheid je enige acceptatiecriterium — en zelfverzekerdheid is een verschrikkelijke maatstaf voor correctheid.

De Loop

Het alternatief klinkt bijna teleurstellend eenvoudig: in plaats van één grote prompt, doe je veel kleine stappen. Na elke stap controleer je je werk. Dan doe je de volgende stap.

Doe. Controleer. Herhaal.

Dat is een agentic loop in zijn meest basale vorm, en als het klinkt alsof het te voor de hand liggend is om te bespreken, bedenk dan dat de meeste teams het nog steeds niet doen. De magie zit niet in het concept — het zit in de discipline om het rigoureus af te dwingen.

Zo ziet dat er in de praktijk uit. In plaats van een AI te vragen "los alle falende tests op," zou je:

1. De test suite draaien en de eerste fout identificeren
2. De AI vragen om alleen dát ene probleem op te lossen
3. De tests opnieuw draaien om de fix te verifiëren
4. Als het slaagt, door naar de volgende fout; als het faalt, wordt de wijziging teruggedraaid
5. Herhalen tot nul fouten over zijn — of tot de AI meldt dat het niet verder kan

Let op wat hier gebeurt. Elke wijziging wordt onafhankelijk geverifieerd. Wanneer iets breekt, weet je precies welke edit het veroorzaakte. Wanneer iets werkt, blijft het werken. De loop bouwt een ratel van geverifieerde vooruitgang in plaats van een berg hopelijk-correcte code.

De Drie Regels Die Het Laten Werken

Niet alle loops zijn gelijk. Een slecht ontworpen loop is erger dan geen loop — hij kan eindeloos draaien terwijl hij cosmetische wijzigingen maakt, of hij kan zelfverzekerd dingen breken terwijl het lijkt alsof alles werkt. De loops die daadwerkelijk resultaten leveren hebben drie non-negotiable eigenschappen.

Ten eerste: een geautomatiseerde poort waar je niet omheen kunt praten. De poort is je waarheidsdetector. Het kan een test suite zijn die slaagt, een linter die nul errors teruggeeft, een type checker die geen type-mismatches bevestigt, of geautomatiseerde screenshot-vergelijkingen die visuele regressies opvangen. Het cruciale punt is dat de poort deterministisch en objectief is. Je kunt er niet langs praten, en de AI ook niet. Als de code de poort niet passeert, is het niet gebeurd — teruggedraaid, niet gemerged.

Dit is moeilijker dan het klinkt, omdat het betekent dat je je commit aan de infrastructuur voor je poorten. Je hebt echte tests met echte coverage nodig. Je hebt je type checker nodig die daadwerkelijk draait. Je hebt je CI/CD pipeline nodig als first-class citizen, niet als afterthought.

Ten tweede: één wijziging per iteratie. Dit voelt pijnlijk langzaam als je gewend bent aan one-shot prompting. Waarom niet alle type errors in één keer oplossen? Waarom niet elke linting warning in één ronde aanpakken?

Omdat wanneer je wijzigingen bundelt en iets breekt, je geen idee hebt wat het veroorzaakte. De AI lost misschien drie dingen op, breekt er één, en het nettoresultaat ziet er positief uit — dus de wijziging wordt gemerged. Nu heb je een regressie zonder duidelijke dader.

Één wijziging, één verificatie, één oordeel. Het is langzamer per stap, maar monumentaal sneller overall omdat elke stap onafhankelijk te reviewen en revertabel is. Wanneer iets in productie breekt, git bisect je naar de exacte wijziging die het veroorzaakte in plaats van een half-afgemaakte puinhoop van onderling verbonden modificaties te debuggen.

Ten derde: een eerlijke stopconditie. Een loop zonder stopconditie is óf oneindig óf stopt willekeurig. Beide zijn slecht. De stopconditie moet een meetbaar signaal zijn: test count tot nul, een "nothing to improve" rapport in opeenvolgende rondes, een evaluation score die plateau bereikt.

De discipline hier is om eerlijke overslagen te accepteren. Wanneer de code daadwerkelijk goed is, is het correcte antwoord "niets veranderd — niets hoefde te veranderen." Een loop die weet wanneer het klaar is, is tien loops waard die blijven malen om marginale wijzigingen te produceren en zo productief lijken.

Wat Loops Vangen Dat Prompts Missen

Laat me een concreet voorbeeld geven van waarom dit belangrijk is.

Stel je een self-improvement loop voor die draait op een productie admin panel. De loop maakt screenshots van elke pagina, vraagt de AI om één usability issue per ronde te identificeren en op te lossen, draait type checks en linting, en gaat door tot er niets meer te verbeteren valt.

Over meerdere rondes produceert deze loop tientallen echte verbeteringen. Verfijning in de UI. Betere foutmeldingen. Slimmere empty states.

Maar de meest waardevolle fix was geen verfijning — het was een bug. In één ronde flagde de screenshot harness dat een settings pagina de full-page crash screen van het framework renderde. Hier is het ding: deze crash was volledig client-side. De API health checks waren de hele tijd groen geweest omdat de API prima was. Een mens die screenshots reviewde had misschien overheen gescrolled of aangenomen dat het een tijdelijke render glitch was.

De geautomatiseerde loop ving het, extraheerde de daadwerkelijke error ("Cannot read properties of undefined (reading 'memes')"), traceerde het naar een state-merge bug in de component lifecycle, en fixeerde het aan de wortel. En omdat de harness nu weet dat het die crash screen pattern moet checken, vangt het die hele klasse van bugs voor altijd.

Dat is de payoff. Een loop doet niet alleen werk — het bouwt een ratel die geverifieerde verbeteringen accumuleert en voorkomt dat geverifieerde regressies terugkeren.

Waarom Dit Belangrijk Is Voor Je Team

Als je een startup bouwt, heb je geen tijd voor AI-tools die constante babysitting nodig hebben. Als je developer bent, heb je geen geduld voor tools die meer bugs introduceren dan ze oplossen.

Agentic loops pakken beide zorgen aan. Ze maken AI-assistentie daadwerkelijk betrouwbaar door vertrouwen te vervangen met verificatie. Ze maken vooruitgang meetbaar door elke wijziging verantwoordelijk te maken. Ze maken debuggen behapbaar door te zorgen dat wanneer iets breekt, je precies weet wanneer en waarom.

Het beste deel? Deze aanpak is niet beperkt tot code generation. Hetzelfde patroon werkt voor geautomatiseerd testen, bug hunting, security scanning, documentatie updates, dependency management — overal waar je one-shot prompts hebt gebruikt terwijl je zou profiteren van continue verificatie.

Of je nu solo werkt of een team aanstuurt, de vraag is niet of je AI gebruikt voor coderen. De vraag is of je het gebruikt op een manier die je daadwerkelijk sneller maakt — of dat het je alleen maar druk doet voelen terwijl je technische schuld opstapelt.

Loops zijn niet de enige manier om met AI te werken. Maar het is de enige manier die ik heb gezien die opschaalt naar serieus productiewerk zonder een grafveld van plausibel-maar-fout code op te bouwen.

Jij deelt.