Werken met agentic AI: twee weken bouwen met drie “collega’s” die nooit koffie halen.
De afgelopen twee weken heb ik iets gedaan wat een paar jaar geleden nog voelde als sciencefiction, en eerlijk gezegd soms nog steeds een beetje zo aanvoelt: ik heb een applicatie gebouwd met een backend, een services-laag, een router en een GUI — met agentic AI als vaste co-workers. Niet “AI als zoekmachine”, maar AI als rolgedreven team: één model als business analist, één als software engineer, één als QA.
Mijn setup was simpel en tegelijk verrassend effectief:
- ChatGPT in de rol van Business Analyse (requirements, scope, user flows, acceptatiecriteria)
- Claude als Software Engineer (architectuurkeuzes, code-implementatie, refactoring-voorstellen)
- Codex als QA medewerker (testcases, edge cases, regressiechecks, “wat kan hier stuk?”)
Het klinkt als een gimmick, maar het werkte al snel alsof ik drie extreem snelle collega’s had die je op commando kunt laten wisselen van focus. Het is ook precies daar waar de lessen begonnen. Want ja: je kunt keihard versnellen. Maar die versnelling vraagt om volwassen besturing, anders bouw je met turbo een huis… op drijfzand.
Wat ik meteen wil nuanceren: kwaliteit was niet iets wat pas later belangrijk werd. Ik begon juist bewust met kwaliteit als uitgangspunt. Ik had vanaf dag één een claude.md (en QA-notities) waarin ik verwachtingen vastlegde: structuur, coding standards, afspraken over refactoring, en hoe we “done” definiëren. Mijn idee was: als ik de kaders scherp neerzet, kan de snelheid omhoog zonder dat de codebase ontspoort.
Dat bleek deels te kloppen — maar ik heb die kaders gaandeweg wel iteratief moeten uitbreiden. Sterker nog: die uitbreiding werd een belangrijk onderdeel van de werkwijze.
Les 1 — Productiviteit is indrukwekkend, maar alleen “gratis” als je de kwaliteit al georganiseerd hebt
De productiviteit van agentic AI is echt opvallend. Vooral door de korte afstand tussen requirement en implementatie. Als de BA-rol (ChatGPT) een requirement aanscherpte, kon Claude het vrijwel direct in de services-laag verwerken. Vervolgens kon Codex er meteen testscenario’s en edge cases tegenover zetten. Dat levert korte cycli op waarin je snel tastbaar resultaat hebt.
Maar in mijn ervaring is die snelheid pas echt bruikbaar als je kwaliteit al vanaf het begin meeneemt. Anders ga je niet “sneller bouwen”, maar “sneller herstellen”. Met andere woorden: agentic AI versnelt alles — ook je fouten. Het voordeel is dat je het snel ziet. Het nadeel is dat je er ook snel een patroon van kunt maken.
Les 2 — Kwaliteit borgen vraagt om voortdurende bijsturing — en dus om levende documentatie
Ik dacht dat mijn claude.md in het begin “wel veel” bevatte. Achteraf bezien was het vooral een goede start. In de praktijk kwamen er steeds nieuwe uitbreidingen bij. Niet omdat ik van documenten houd (ik ben geen documentfetisjist), maar omdat ik merkte dat iedere iteratie nieuwe randen blootlegt: een nieuw type functionaliteit, een nieuwe afhankelijkheid, een nieuwe manier waarop duplicatie kan ontstaan, of een nieuwe conventie die je wilt afdwingen.
Die documentatie werd dus een soort kwaliteits-OS: steeds net iets verder verfijnd naarmate ik zag waar het systeem wrijving kreeg. Denk aan uitbreidingen zoals:
- explicietere afspraken over projectstructuur en naamgeving
- strengere “definition of done” (tests, error handling, logging, linting)
- refactoring als vaste stap in de cyclus, niet als sluitpost
- checks op herhaalpatronen en duplicatie (zeker bij snelle iteraties)
- afspraken over grenzen tussen lagen (router/service/domain)
Het belangrijke inzicht: agentic AI werkt het best met duidelijke guardrails, maar die guardrails moeten mee-evolueren. Je start met een kader, en je maakt het volwassen door feedback uit de praktijk.
Les 3 — Geheugen en context: alsof je steeds opnieuw moet inwerken
Hier zat de grootste frictie. Niet zozeer in “begrijpen”, maar in “consequent onthouden”. Modellen reageren sterk op de laatste prompt en nemen niet automatisch alle eerder gemaakte afspraken mee, zelfs als je het gevoel hebt dat het project inmiddels een duidelijke koers heeft.
Omdat ik dit merkte, werden mijn prompts gaandeweg explicieter en consistenter. Ik verwees bewust naar de QA-documentatie en de claude.md: “volg deze afspraken”, “gebruik dit patroon”, “valideer tegen dit checklistje”, “refactor volgens deze principes”. Dat hielp zeker — het gaf richting en reduceerde afwijkingen — maar het bleef een terugkerend punt van aandacht. Je kunt er niet van uitgaan dat één keer uitleggen voldoende is.
Mijn lesson learned hier: in agentic AI is context geen achtergrond, maar input. Als je wilt dat afspraken blijven gelden, moet je ze blijven “voeden”. Niet telkens alles, maar wel de essentie: architectuurkeuzes, kwaliteitscriteria, en de do’s/don’ts die je al eerder hebt vastgesteld.
Les 4 — Korte cycli: kleine afstand tussen requirement en implementatie is goud
De combinatie van rollen maakte het mogelijk om klein te werken en toch door te bouwen. Dat hielp enorm bij focus. Je hebt steeds een concreet doel, snel resultaat, snel feedback. Het is eigenlijk een versnelde vorm van het ritme dat je ook in goede productteams ziet: korte feedbackloops met continue bijsturing.
Wat ik daarvan meeneem: agentic AI versterkt een iteratieve werkwijze. Als je die werkwijze al kent (en je kwaliteit op orde hebt), dan kun je er echt veel uit halen. Als je gewend bent aan grote batches en lange feedbackloops, dan wordt de AI vooral een extra bron van variatie.
Les 5 — De modellen worden snel beter — en dat maakt je werkwijze nóg belangrijker
De evolutie van de modellen gaat hard. De huidige versies zijn aantoonbaar beter dan eerdere versies in consistentie, codekwaliteit en redeneervermogen. Dat is hoopgevend, maar het betekent ook dat je je proces niet moet baseren op één momentopname.
Het structurele punt blijft hetzelfde: hoe beter de modellen worden, hoe meer je winst pakt als je je kwaliteitsborging goed hebt ingericht. Anders gezegd: de winst zit niet alleen in “slimmere AI”, maar in “slimmere samenwerking”.
Conclusie: dit is de toekomst, maar kwaliteit is de voorwaarde — en peer-review is goud
Mijn conclusie blijft overeind: dit is de toekomst. Het is leuk om zo te werken, en je kunt echt resultaten leveren met een snelheid die je normaal alleen ziet als je team al perfect ingespeeld is.
Maar het succes zit niet in snelheid alleen. Het zit in het vermogen om kwaliteit en onderhoudbaarheid te borgen terwijl je versnelt. In mijn geval betekende dat: starten met kwaliteit als uitgangspunt, die afspraken vastleggen, en ze vervolgens iteratief uitbreiden op basis van wat je in de praktijk tegenkomt. En vooral: accepteren dat “geheugen” nog niet vanzelfsprekend is, waardoor expliciete verwijzingen naar je QA- en kwaliteitsdocumentatie geen overbodige luxe zijn, maar een essentieel onderdeel van je workflow.
Tot slot: werken met meerdere modellen als peer-review is fantastisch. Het voelt alsof je een ingebouwde tegenkracht hebt die je scherp houdt. En eerlijk? Dat is precies wat je wilt als je snelheid maakt: niet alleen harder gaan, maar ook beter blijven bouwen.
