Elke week duik ik diep in een onderwerp binnen AI en test ik het in de praktijk. Deze week gaat het over de werkwijze die ik in stilte al toepas op drie side projects. Die draait de traditionele rol van een developer zo hard om dat ik hem wil opschrijven voordat hij gemeengoed wordt.
De korte versie: de productiefste manier die ik heb gevonden om software te bouwen, begint niet met code. Het begint met een schermopname van jezelf terwijl je een product gebruikt dat bijna doet wat je wilt. Je benoemt elke wrijving hardop en geeft die opname aan een agent, die er een gestructureerd productdocument van maakt: in het vak een PRD, voluit Product Requirements Document. Daarna stelt de agent je vragen over de opzet. Daarna bouwt hij.
De rol van "developer" verschuift daarmee van code schrijven naar het ontwerpen van de loop waaruit de code voortkomt.
Hoe een build nu echt begint
Ik probeerde dit voor het eerst op een kleine interne tool. In plaats van mijn code-editor te openen, opende ik de dichtstbijzijnde concurrent van het product dat ik wilde bouwen. Ik zette de schermopname aan, begon het te gebruiken en gaf op elke interactie hardop commentaar.
"Deze lijstweergave is prima maar het filter blijft actief tussen sessies terwijl ik dat niet wil."
"Hier zou ik een sneltoets willen."
"Deze lege staat is top, kopieer dit exact."
"Dit prijsmodel klopt niet voor onze use case, we hebben per-seat met caps nodig."
Twaalf minuten ongescript commentaar geven. Geen bullet points, geen specs, geen nadenken over wat je moet opschrijven. Gewoon gebruiken en becommentariëren.
De video ging naar een multimodaal model: een AI-model dat ook beeld en geluid verwerkt, dus het transcribeert mijn commentaar en analyseert de beelden. Twintig seconden later had ik een PRD van 4 pagina's met onderdelen waar ik zelf niet aan had gedacht: Doelen, Non-doelen, Gebruikersflows, Datamodel, Edge cases, Succesmetrics, zelfs een "Dingen die we bewust overslaan in v1".
Dat is het begin van de nieuwe loop. In plaats van een leeg bestand openen of een spec uitschrijven, laat je zien wat je bedoelt en laat je het model daar een document van maken.
Wat de agent doet dat ik vroeger zelf deed
De PRD gaat naar een coding agent. Het eerste wat hij doet, is geen code schrijven. Hij stelt vragen.
Echte vragen uit een van deze sessies:
- "Je zei dat filters 'persisteren in localStorage', maar de lege staat vraagt om een login. Moeten filters een uitlog overleven?"
- "Prijzen hebben per-seat caps. Is de cap gedeeld tussen organisaties of per organisatie?"
- "De video laat zien dat je items tagt. Zijn tags account-specifiek of globaal?"
- "Sectie 3 spreekt sectie 5 tegen over de standaard sorteervolgorde. Welke moet blijven?"
Dit zijn geen generieke vragen. Het zijn tegenstrijdigheden en gaten die de agent vond door de PRD te vergelijken met de zichtbare UI in de opname. Ik antwoord in gewone taal, de agent past de PRD aan, en we herhalen dat een paar keer. Twee of drie rondes later is het document intern consistent en begint de agent code te schrijven.
De rolverschuiving die ik niet had verwacht
Ik ben niet de coder in deze loop en ook niet de architect. Ik ben de loop-ontwerper.
Wat dat in de praktijk betekent:
- Ik lever context (de opname, de PRD, de bestaande codebase, de randvoorwaarden)
- Ik laat de agent bouwen
- Ik laat hem falen
- Ik verfijn de instructies, niet de code
Naast elkaar gezet:
| Traditionele werkwijze | De build loop | |
|---|---|---|
| Startpunt | Leeg bestand, spec schrijven | Schermopname met hardop commentaar |
| Waar kennis zich ophoopt | In hoofden en losse documenten | In een instructielaag onder versiebeheer |
| Wat je verbetert na een fout | De code | De instructies |
| Verificatie | Eén collega leest de wijziging | Meerdere onafhankelijke agents parallel |
Als er iets misgaat, patch ik de output niet. Ik update de instructielaag zodat dezelfde fout niet nog eens kan gebeuren. Na een paar sessies groeit dit uit tot een blijvende set projectregels die de agent leest aan het begin van elk gesprek. Sommige van die regels komen in CLAUDE.md terecht. Andere landen in een tasks/lessons.md die de agent zelf bijwerkt na elke correctie.
Dat geheugen stapelt zich op: de agent wordt met elke sessie scherper op deze specifieke codebase, in plaats van steeds weer bij nul te beginnen.
Waarom architecturale drift deze projecten vroeger de das omdeed
Elk AI-ondersteund project dat ik in 2024 opleverde, kende dezelfde neerwaartse spiraal. Eerste drie sessies: schone code, snelle voortgang. Sessies vier tot tien: kleine inconsistenties. Sessies elf en verder: architecturale drift, componenten die dingen doen waarvoor ze niet bedoeld zijn, drie licht verschillende manieren om hetzelfde te doen, en de snelheid stort in.
De oplossing bleek in gestructureerde planningscycli te zitten.
Voor elke niet-triviale wijziging gaat de agent in plan mode: hij benoemt eerst wat hij gaat doen, somt de bestanden op die hij zal aanraken, wijst op afwegingen, en vraagt om akkoord. Pas daarna bewerkt hij. Als er tijdens de uitvoering iets misgaat, stopt hij en plant opnieuw in plaats van door te drukken.
Het verschil tussen "agent schrijft code" en "agent plant en schrijft dan code" is groot. De eerste variant raakt na verloop van tijd uit koers, de tweede blijft coherent over honderden commits heen. Volgens dat tweede patroon leverde ik in zes weken 240 commits op over drie repos, waarvan 7 procent is teruggedraaid. Volgens het eerste patroon liepen dezelfde projecten al bij sessie twaalf vast.
Wat je in huis moet hebben voordat dit werkt
Lees je dit als beslisser in plaats van als bouwer, dan is dit de kern: de winst zit in een kortere lijn tussen idee en werkende versie, niet in goedkopere developers.
Dit is nu interessant voor softwarebedrijven en bureaus die maatwerk leveren. Ook voor teams met minstens één persoon die de output van een agent op waarde kan schatten, en voor ondernemers die interne tools of prototypes willen bouwen zonder volledig team. Nog niet, of alleen met veel meer waarborgen: systemen waar fouten direct geld of gezondheid kosten, en organisaties waar niemand kan beoordelen of de agent onzin bouwt. Deze loop vergroot de vakkennis die er al is. Is er niemand die ziet wanneer de agent de verkeerde kant op gaat, dan valt er ook niets te vergroten.
De meeste Nederlandse mkb-bedrijven zonder eigen developers krijgen dit patroon via de zijdeur binnen: het bureau dat je inhuurt gaat zo werken, en jij merkt het doordat maatwerk sneller wordt opgeleverd.
De realistische eerste stap kost een middag: film jezelf een kwartier in een tool die lijkt op wat je wilt hebben, benoem hardop wat je anders wilt, en laat een AI-model er een PRD van maken. Alleen al dat document is de oefening waard; een agent laten bouwen is stap twee.
Wat je nu in de gaten moet houden
Drie ontwikkelingen die ik iedereen aanraad die dit serieus neemt:
Multi-agent cloud review. Claude Code heeft nu /ultrareview, dat een reeks cloud agents opstart die je branch end-to-end lezen, problemen zoeken en los van elkaar terugkoppelen. Het nieuwe zit hem in die parallelle opzet. Review door AI hadden we al, alleen delen deze agents geen context, waardoor hun oordelen elkaar niet kleuren. Binnen vijf tot tien minuten liggen er meerdere beoordelingen. Ik draai dit nu voor elke niet-triviale pull request.
Plan mode als volwaardige tool. Plan mode begon als een optie die je zelf aanzette. Bij mij is het inmiddels vaste prik voor alles van 3+ stappen. Je gaat expliciet plan mode in, schaaft het plan bij samen met de agent, geeft akkoord en voert dan pas uit. Een slechte aanpak ontdekken in plan mode kost niets. Diezelfde aanpak ontdekken na 40 bestandswijzigingen kost uren.
AI-pentestagents. Dit is wat mij betreft de meest onderschatte categorie van het jaar. Strix (github.com/usestrix/strix) draait een gecoördineerde zwerm agents die je applicatie aanvallen zoals echte hackers dat zouden doen. Authenticatietests, IDOR-enumeratie, misbruik van bedrijfslogica, race conditions, SSRF, prompt injection op AI-functionaliteit. Het werkt anders dan een statische scanner: hij plant aanvallen, voert ze uit, kijkt wat eruit komt en rapporteert alleen wat hij ook echt heeft kunnen reproduceren. Ik draaide het vorige week op een side project. Het vond twee echte kwetsbaarheden die mijn codereview had gemist. De eerste was een IDOR: met een aangepast ID kon je andermans data opvragen. De tweede was een SSRF in een webhook-endpoint, waarbij de server verleid wordt om interne adressen aan te roepen. Mijn inschatting: een menselijke pentester vervangt dit nog niet, maar als vaste extra laag is het nu al de moeite waard.
Nog één nuance: deze tools veranderen snel van naam en vorm. De patronen eronder blijven overeind, namelijk parallelle verificatie, eerst plannen en dan uitvoeren, en aanvalssimulatie.
Hoe dit eruitziet als dagelijkse praktijk
Een typische sessie voor mij ziet er nu zo uit:
- Opnemen en becommentariëren (5 tot 15 minuten) met het dichtstbijzijnde equivalent van wat ik wil bouwen.
- Multimodale PRD-generatie. Doornemen en aanscherpen. Misschien twee rondes met de agent.
- Plan mode voor het volgende stuk werk. Akkoord geven op bestandslijst en aanpak.
- Uitvoeren. Agent schrijft, ik kijk mee terwijl de diff binnenstroomt.
- Testen en beoordelen. Draai
/ultrareviewvoor niet-triviale wijzigingen. Draai Strix periodiek op alles wat gebruikers zien. - Lessen. Als er iets misgaat, gaat de regel die het voorkomt naar de instructielaag, niet alleen naar de code.
Dat is het. De stap die vroeger "schrijf code" heette, is nu twee stappen: ontwerp de loop, draai de loop. De eerste stap is waar de hefboom zit.
Wat ik iemand zou vertellen die vandaag begint
Drie lessen uit een jaar waarin ik dit patroon draaide:
- Laat zien, niet specificeren. Een schermopname van 12 minuten leverde bij mij een betere PRD op dan een schrijfsessie van 2 uur. Het model ziet wat je bedoelt. Je kunt niet alles onder woorden brengen wat je bedoelt, maar je kunt het wel laten zien.
- Behandel instructies als de echte codebase. De code is een afgeleide. De blijvende regels in
CLAUDE.md,tasks/lessons.mden je planningssjablonen zijn de bron. Zet ze onder versiebeheer, beoordeel ze en controleer ze op veroudering. - Gebruik parallelle agents voor verificatie. Vertrouw nooit op de output van één enkele agent voor iets dat live gaat. Onafhankelijke agents die elkaars fouten opvangen, zijn de goedkoopste verzekering die je kunt kopen.
Mijn inschatting voor de komende jaren: de developer schrijft steeds minder code zelf en besteedt die tijd aan het ontwerpen van de systemen waaruit code voortkomt. Iedereen werkt met dezelfde modellen, dus daar valt weinig voorsprong te halen. Het onderscheid ontstaat in de loop die je eromheen bouwt.