De meeste ontwikkelaars behandelen een agent als een zoekmachine met code als uitvoer. Je typt een vage omschrijving van wat je wilt, accepteert wat er terugkomt en herhaalt dat. Het werkt. Tot het niet meer werkt, en dan echt niet meer.
De ontwikkelaars die consistent goede resultaten halen uit agents, zijn niet beter in het schrijven van prompts. Ze volgen een workflow. Zes fases, op volgorde, elke keer. Dit zijn ze.
Fase 1: Voor de eerste prompt
De meest gemaakte fout is beginnen bij de agent. De spec komt eerst.
Geen Jira-ticket. Geen opsomming. Een echt document: wat bouw je, waarom, wie gebruikt het, hoe ziet "klaar" eruit, wat zijn de randgevallen, wat zijn de harde eisen. Schrijf dit zelf, in gewone taal, voordat de agent ook maar iets aanraakt.
Gebruik de agent daarna om de spec te betwisten. Geef hem drie rollen: een Architect die de oplossing in kaart brengt voordat er ook maar een regel code bestaat, een Fact Checker die de aannames van de Architect onderzoekt, en een Devil's Advocate die het ontwerp probeert te breken. Dit levert in een kwartier een beter resultaat op dan de meeste planningssessies in een uur.
Als de spec die kritiek overleeft, splits je hem op in een geordende takenlijst. Één concrete taak per prompt, gesorteerd op afhankelijkheid. Dit is je promptplan. Addy Osmani noemt het hele proces "waterval in een kwartier": een gestructureerde planfase die de codeerfase aanzienlijk soepeler maakt.
De takenlijst is ook je sessiestatus. Als een sessie halverwege vastloopt, zie je aan de afgevinkte taken precies waar je was. Het plan is niet alleen planning. Het is je herstelmechanisme.
De prompt is niet de spec. De spec schrijf je voordat de prompt bestaat.
Fase 2: De contextlaag
Elke serieuze agent heeft een contextbestand. Claude Code gebruikt CLAUDE.md. Cursor gebruikt .cursorrules. GitHub Copilot heeft werkruimte-instructies. Windsurf heeft zijn eigen regelbestand. De naam verschilt. Het doel is hetzelfde: persistente context die de agent leest voordat hij iets doet.
Dit bestand is niet optioneel.
Zet daarin je stack, je commando's, je conventies en @-verwijzingen naar je architectuurdocumenten. Houd het beknopt: drie secties, één pagina. Een contextbestand van drie pagina's verbrandt tokens aan instructies in plaats van aan werk.
Ga verder met coderingsrichtlijnen: expliciete patronen, met voorbeelden. Geen voorkeuren. Patronen. Agents pikken geen sfeer op. Ze volgen regels die je hebt opgeschreven. Als je server actions wilt in plaats van API routes, schrijf dat op. Als je getypeerde returnwaarden op elke functie wilt, schrijf dat op. Stack Overflow verwoordde het begin 2026 treffend: richtlijnen voor agents moeten explicieter en concreter zijn dan richtlijnen voor mensen, omdat agents geen stilzwijgende kennis opbouwen door maanden in de codebase te werken. Ze beginnen elke sessie opnieuw.
Als je agent herbruikbare vaardigheden of maatwerkinstructies ondersteunt voor terugkerende taken, definieer die dan. De investering vooraf betaalt zich terug bij elke sessie.
Fase 3: Afdwinging
Instructies in een contextbestand zijn suggesties. De agent volgt de meeste ervan, de meeste van de tijd. Dat is niet goed genoeg voor de dingen die ertoe doen.
Hooks zijn deterministisch. Een pre-tool hook wordt afgevuurd voordat de agent iets uitvoert. Hij inspecteert de payload, staat de actie toe of blokkeert hem, en geeft bij een blokkade de reden terug aan de agent. Een post-tool hook wordt afgevuurd na elke schrijfactie en kan automatisch je formatter, linter of type checker aanroepen.
Het principe geldt voor elk hulpmiddel. Wat je ook gebruikt: zoek de afdwingingslaag. Lintregels. CI-controles. Pre-commit hooks. ADRs die je hebt gecommit zodat de agent je architectuurbeslissingen als harde grenzen leest in plaats van als achtergrondcontext. De discipline zit in het systeem, niet in de prompt.
Als de niet-onderhandelbare regels in het systeem verankerd zijn, hoef je ze niet bij elke prompt te onthouden. Iets structureels vergeet je niet.
Fase 4: De sessie uitvoeren
Kleine stukken. Één functie, één functionaliteit, één fix per taak. Geef je een agent een grote, vage taak, dan krijg je een grote, vage oplossing. Geef je hem een kleine, concrete taak, dan krijg je iets dat je daadwerkelijk kunt nakijken en begrijpen.
Commit na elk afgerond stuk. Kleine diffs worden gelezen. Grote diffs worden gescand.
Context is eindig. Structurele hulpmiddelen beschermen hem beter dan gedragsmatige omwegen. Houd je contextvenster tijdens actieve sessies onder de vijftig procent. Als je overschakelt op een ander onderwerp, begin dan een nieuwe sessie. Sleep de geest van het vorige gesprek niet mee naar een nieuw probleem.
Gebruik voor parallel werk git worktrees. Twee agents op twee branches, geen gedeelde toestand, geen conflicten. Je tool ondersteunt dit mogelijk van nature. Zo niet, stel de worktrees zelf in. Het patroon is in beide gevallen hetzelfde.
Als de agent begint te herhalen, bestanden herleest die al gelezen zijn, werk opnieuw plant dat al gepland was: dat is een contextprobleem. Kijk naar het contextvenster, niet naar de prompt.
Fase 5: Vertrouwensgrenzen
Beslis vóór een sessie wat de agent mag doen zonder dat jij er uitdrukkelijk toestemming voor geeft. Schrijf dit in je contextbestand zodat het elke keer geldt.
De lijst bevat doorgaans: migraties uitvoeren, productieconfiguratie aanpassen, gegevens verwijderen, deploys uitvoeren en alles wat gedeelde infrastructuur raakt. De dag dat Claude mijn database verwijderde was een les in wat er gebeurt zonder een gate. De agent was niet eigenwijs. Hij was behulpzaam. Dat is juist het probleem.
Pin afhankelijkheden aan commit-hashes, niet aan versietags. Tags zijn veranderlijke verwijzingen. Iemand schreef er 700 van over in vier packages in één weekend. Door AI toegevoegde afhankelijkheden verdienen extra aandacht: de agent kiest packages vol vertrouwen, en vertrouwen is niet hetzelfde als correctheid.
Als de agent twijfel uitdrukt, stop dan en lees goed. Dat signaal is meer waard dan de suggestie die erop volgt.
Fase 6: De review
Dit is geen formaliteit. Dit is het werk.
Lees elke diff alsof je hem zelf geschreven hebt. Niet "ziet dit er goed uit". Elke regel, met aandacht. Als je de wijziging niet aan een collega kunt uitleggen zonder te zeggen "de agent heeft dat gedaan", is hij niet klaar.
Dat is moeilijker dan het klinkt. Code lezen die je niet zelf hebt geschreven kost meer vaardigheid dan het schrijven ervan. Het instinct om te scannen is sterk als de uitvoer er aannemelijk uitziet. Weersta het. Aannemelijk is niet correct.
Uit het ontwikkelaarsonderzoek van Sonar in 2026 bleek dat 96% van de ontwikkelaars AI-uitvoer niet volledig vertrouwt. 48% controleert het voor het samenvoegen. Die kloof is waar incidenten leven, en hij vergroot zich naarmate de codebase lastiger te doorgronden wordt.
Gebruik voor alles wat niet triviaal is een review-agent. Niet dezelfde agent die de code schreef. Een afzonderlijke instantie met een specifiek mandaat: zoek bugs, zoek beveiligingsproblemen, zoek architectuurschendingen. Review door meerdere agents is goedkoop. Retrospectives na een incident zijn dat niet.
De agent regelt het snelle deel. Genereren is goedkoop. Waar je voor betaalt is de structuur eromheen: de spec die richting geeft, de contextlaag die geheugen biedt, de afdwinging die betrouwbaarheid oplevert, de sessiediscipline die focus bewaart, de vertrouwensgrenzen die veiligheid bewaken, en de review die elke uitvoerregel van jou maakt.
De workflow is geen extra last bovenop het gebruik van een agent. Het is hoe werken met een agent er in de praktijk uitziet.