Closing the loop

Juni 2026 – Jan Rietveld

Ik heb tijd over. Naast het werk wat ik doe voor mijn klanten zit ik momenteel in een fase waarin ik weinig nieuwe productideeën heb, en alles voelt nutteloos omdat iedereen het toch kan vibecoden als Fable zo uit is.

Wat ik wél heb is mijn normale werk als software programmeur. Dat loopt door, en dat is de afgelopen jaren flink veranderd door AI. Doordat ik voor mezelf werk ben ik ook erg gemotiveerd om dat werk te optimaliseren.

Ik wil je meenemen in hoe ik nu, op dit moment, AI inzet in mijn werk als software programmeur. Het concept waar ik nu naar leef heet ‘Closing the loop’. Ik vertel je wat dat betekent en hoe ik het toepas.

AI-modellen zijn goed in programmeren. Dat heeft alles te maken met wat ze in Silicon Valley ‘verification loops’ noemen. Zodra je een taak hebt waarbij je weet wat het antwoord moet zijn, kun je een loop opzetten die pas stopt als dat antwoord bereikt is. Code is hier het perfecte voorbeeld van: een stuk code slaagt of faalt. Doorloop dat proces vaak genoeg, en je maakt een model meetbaar beter.

Dat werkt heel goed voor ‘logische code’: een API krijgt input en verwacht een bepaalde output. Lastiger wordt het bij iets als het design van een website. Dat is aan de achterkant ook code, maar een AI kan uit zichzelf niet ‘zien’. Toch is ook dit verifieerbaar. We hebben een design in Figma, dus we kunnen de AI precies vertellen hoe iets eruit moet zien. Geef het model toegang tot dat design én de mogelijkheid om van zijn eigen werk een screenshot te maken, en je hebt opnieuw een loop.

We komen er steeds meer achter dat heel veel van wat mensen doen, vooral achter een computer, op te breken is in dit soort loops.

Ik neem je even mee hoe ik dit concept nu toepas in mijn eigen werk.

Programmeren met AI doe ik al jaren, maar pas sinds dit jaar is het écht goed. Waar ik AI vroeger gebruikte als co-piloot die suggesties gaf, heb ik sinds een paar maanden het stuur losgelaten. Elke bug, feature of verbetering start nu met een agent. Vorig jaar wilde ik nog altijd zelf de controle houden; nu kan de AI het simpelweg beter en sneller. Ik zoek vooral naar de plekken waar het dat nog niet is. Dáár moet ik zitten.

AI compleet loslaten doe ik niet, en dat is ook niet het doel. Het doel is sneller de juiste dingen maken. Als AI iets fout doet, kun je denken ‘dan doe ik het zelf wel’, of je past je workflow aan zodat het die fout niet meer maakt. Veel mensen blijven hangen in het eerste: ‘het kan nog niet alles, dus doe ik het zelf’. Maar dan investeer je in de verkeerde plek. Je kunt beter een systeem bouwen waarin jij precies daar zit waar AI (nog) niet goed is.

Terug naar de praktijk. Alles start dus met een verzoek aan een agent — Claude Code in dit geval, maar volgende week kan dit weer Codex zijn. Het boeit niet, ze kunnen tegenwoordig allemaal hetzelfde. Ik tag Claude in ons Slack-kanaal en dump er iets neer als: ‘dit scherm scrollt niet smooth, kun je kijken waar het aan ligt en fixen pls’ met een screenshot erbij.

Claude gaat aan de slag. Het spawnt subagents die de codebase doorzoeken, spot een aantal mogelijke oorzaken, kiest zelf de beste fix, past de code aan en valideert of alles nog werkt.

Klaar. Right? Nee. Mijn hele carrière werk ik al met backenders die zeggen dat iets gefixt is terwijl het nog niet werkt. ‘Heb je het getest?’ vraag ik dan. ‘Het runt’, krijg ik terug. Ja, leuk. Maar goede code betekent niet altijd dat iets ook doet wat ik wil.

Dus heb ik Claude verteld dat het het project ook echt moet draaien. Ik werk aan een mobiele app, dus dat is lastiger dan een website. Daarom heb ik Claude toegang gegeven tot zijn eigen Mac Mini, waarop het via een MCP een iPhone-simulator kan gebruiken. Het start de app, logt in en checkt visueel of de bug daadwerkelijk weg is. Zo niet, dan gaat het terug en verzint het een andere oplossing. De loop is pas af als het werkt — niet als het runt.

Als de bug gefixt is, maakt Claude een Pull Request aan met daarin wat het gedaan heeft. Een tweede, onafhankelijke agent doet vervolgens een code review: klopt het met wat er moest gebeuren, en breekt het niets anders? Komt daar feedback uit, dan wordt Claude wakker en pakt het die automatisch op.

Maar, as they say, trust but verify. Voor de zekerheid laat ik Claude tijdens het valideren een schermopname maken, die het meestuurt als bewijs dat het goed gaat. Bij iets groters of belangrijkers wil ik het soms alsnog zelf testen. Claude stuurt mij dan een download linkje waarmee ik deze specifieke versie direct op mijn iPhone kan zetten.

Sinds kort laat ik Claude er een kort rapportje bij schrijven: wat was de oorzaak, welke oplossingen heeft het overwogen, en waarom is dit de beste? Dat staat kort en bondig in de PR, zodat ik sneller kan beoordelen of het denkfouten heeft gemaakt in het vinden van een oplossing.

En pas dan kom ik weer terug in de loop en kijk ik naar de code.

Wat ik vooral merk is dat programmeren met AI steeds meer een vertrouwenskwestie is. Durf je de controle uit handen te geven? De meeste feedback die ik nog heb gaat namelijk niet over fouten, maar over smaak: een andere conventie, of iets dat ik zelf nét anders had opgelost. Als een menselijke collega het zo had gedaan, had ik het goedgekeurd. Als het een AI is heb ik ineens andere standaarden, blijkbaar.

In de drie dagen dat ik Claude Fable kon proberen, viel zelfs dat laatste stukje twijfel vrijwel weg. En dat is wat ‘closing the loop’ uiteindelijk betekent. Technisch kunnen we de loop nu bijna sluiten, maar durven we het ook?

Ik wil afsluiten met een kleine tijdlijn van hoe ik AI inzet in mijn werk:

2026 wordt het jaar dat je AI ook echt kan vertrouwen en dingen uit handen kan geven. En of je dat aandurft.