Software bouwen met AI begint niet met code, maar met een schermopname

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 overhandigt het resultaat aan een agent die er een gestructureerd productdocument van maakt, in het vak een PRD (Product Requirement Document). Daarna stelt de agent je vragen over de opzet. Daarna bouwt hij.

De rol van "developer" is hier niet om code te schrijven. Het is om de loop te ontwerpen 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. Niet "open een leeg bestand". Niet "schrijf een spec". Laat zien in plaats van vertellen, en laat het model het document structureren.

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. Ik ben 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:

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 terecht in CLAUDE.md. Andere komen terecht in een tasks/lessons.md die de agent zelf bijwerkt na elke correctie.

Het blijvende geheugen bouwt 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 shipte, had 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 is geen slimmer model. De oplossing is gestructureerde planningscycli.

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, schrijft dan code" is enorm. De eerste raakt uit koers. De tweede blijft coherent over honderden commits heen. Ik heb 240 commits over drie repos in zes weken geshipt volgens het tweede patroon, waarvan 7 procent teruggedraaid. Met het eerste patroon stierven dezelfde projecten al bij sessie twaalf.

Voor wie is dit nu interessant, en voor wie nog niet?

Voor wie dit leest als beslisser en niet als bouwer: de winst zit niet in goedkopere developers, maar in een kortere lijn tussen idee en werkende versie.

Dit is nu interessant voor softwarebedrijven en bureaus die maatwerk leveren, 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 vervangt geen vakkennis, hij vermenigvuldigt hem. Zonder iemand die ziet wanneer het misgaat, vermenigvuldig je nul.

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 vloot cloud agents opstart die je branch end-to-end lezen, problemen vinden, tests draaien, en terugkoppelen. Het nieuwe zit hem niet in review-door-AI (dat hadden we al). Het zit in parallelle review door onafhankelijke agents die geen context delen. Je krijgt echt onafhankelijke beoordelingen binnen vijf tot tien minuten voor de prijs van een lunch. Ik draai dit nu voor elke niet-triviale pull request.

Plan mode als volwaardige tool. Plan mode was vroeger een vlag. Het is nu standaard voor alles van 3+ stappen. Je gaat expliciet plan mode in, itereert op het plan 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. 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 is geen statische scanner. Hij plant aanvallen, voert ze uit, observeert de uitkomsten, en rapporteert met reproducties. Ik draaide het vorige week op een side project en het vond twee echte kwetsbaarheden die mijn codereview miste: een IDOR, een lek waarbij je met een aangepast ID andermans data opvraagt, en een SSRF in een webhook-endpoint, waarbij de server verleid wordt 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: parallelle verificatie, plannen voor uitvoeren, aanvalssimulatie. Die richting is onmiskenbaar.

Hoe dit eruitziet als dagelijkse praktijk

Een typische sessie voor mij ziet er nu zo uit:

1. Opnemen en becommentariëren (5 tot 15 minuten) met het dichtstbijzijnde equivalent van wat ik wil bouwen.
2. Multimodale PRD-generatie. Doornemen en aanscherpen. Misschien twee rondes met de agent.
3. Plan mode voor het volgende stuk werk. Akkoord geven op bestandslijst en aanpak.
4. Uitvoeren. Agent schrijft, ik kijk mee terwijl de diff binnenstroomt.
5. Testen en beoordelen. Draai /ultrareview voor niet-triviale wijzigingen. Draai Strix periodiek op alles wat gebruikers zien.
6. 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:

1. 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.
2. Behandel instructies als de echte codebase. De code is een afgeleide. De blijvende regels in CLAUDE.md, tasks/lessons.md, en je planningssjablonen zijn de bron. Zet ze onder versiebeheer, review ze en controleer ze op veroudering.
3. 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, maar ontwerpt betere systemen waaruit code voortkomt. Het oneerlijke voordeel zit niet in modelkwaliteit. Iedereen krijgt dezelfde modellen. Het voordeel zit in de loop die je eromheen bouwt.