BlogAI als ontwikkeltool, niet als buzzword
De meeste discussies over AI (Kunstmatige Intelligentie) in softwareontwikkeling vallen in een van twee kampen: ademloos enthousiasme of existentiële angst. Dit artikel is geen van beide. Ik werk als freelance ontwikkelaar met PHP, Laravel, mobiel (Flutter/Dart), frontend frameworks, C programma's en meer. Het afgelopen jaar heb ik AI agents geïntegreerd in mijn dagelijkse workflow, en ik wil concreet beschrijven hoe dat eruitziet — wat werkt, wat niet, en waarom.
De belangrijkste beperking die deze workflow vormgeeft is er een die zelden wordt genoemd in de hype: AI agents hebben beperkte contextvensters. Ze kunnen niet een volledige codebase in hun werkgeheugen vasthouden. Dit dwingt een discipline af die sowieso goede engineeringpraktijk blijkt te zijn: breek features op in kleinere, goed gedefinieerde stukken; plan voordat je uitvoert; en review iteratief in plaats van in één grote slag.
Wat volgt behandelt de specifieke workflow die ik gebruik, de infrastructuur waarop het draait, de lessen die ik heb geleerd door het toe te passen over meerdere technology stacks, en de faalscenario's waar je je bewust van moet zijn.
Claude Code en Codex
Mijn primaire planning- en implementatie-agent is Claude Code van Anthropic. Het ontwerpt architectuur, schrijft uitvoeringsplannen, genereert code en werkt taken systematisch door. Het behandelt het constructieve deel: gegeven een duidelijke probleemstelling en relevante context, produceert het een plan en implementeert het vervolgens.
Mijn review-agent is Codex van OpenAI. Zijn rol is adversarieel in de productieve zin: het ontvangt het plan dat Claude heeft geproduceerd en zoekt naar gaten, foutieve aannames, ontbrekende randgevallen en betere benaderingen. De twee modellen komen van verschillende organisaties, getraind op verschillende data, met verschillende neigingen en verschillende blinde vlekken. Dat verschil is precies het punt — de een vangt op wat de ander mist.
Elke regel door AI gegenereerde code handmatig reviewen zou het grootste deel van de efficiëntiewinst tenietdoen. Dus de review zelf wordt ook aan een agent gedelegeerd. Mijn rol is om in te grijpen wanneer de agents vastlopen, wanneer de output afdwaalt van de werkelijke vereiste, of wanneer domeinkennis nodig is die geen van beide modellen heeft. De uiteindelijke beslissing over wat er geleverd wordt is altijd de mijne.
Plan, review, itereer, voer uit
De concrete workflow voor elke feature of taak verloopt als volgt. Eerst geef ik Claude Code een duidelijke beschrijving van de taak samen met relevante context: welke bestanden betrokken zijn, welke patronen de bestaande codebase volgt, wat het verwachte resultaat moet zijn. Claude produceert een uitvoeringsplan dat de architectuur, de specifieke bestandswijzigingen en de beoogde aanpak beschrijft.
Dat plan gaat naar Codex voor review. Codex identificeert problemen: ontbrekende foutafhandeling, incorrecte aannames over de bestaande code, te complexe abstracties, beveiligingsfouten, of gevallen waar het plan geen rekening mee houdt. De feedback van Codex gaat terug naar Claude, dat het plan herziet. Deze cyclus draait typisch twee of drie keer voordat beide agents convergeren op iets solides. Als het plan verschillende fasen of subtaken bevat, doorloopt elke fase dezelfde reviewcyclus voordat de volgende begint.
Pas nadat het plan stabiel is begint de implementatie. Na implementatie worden commits ook gereviewd — afhankelijk van de omvang en complexiteit van de wijziging vangt een extra agent-pass problemen op die door de planningsfase heen zijn geglipt. Het kernpunt is dat itereren op een plan veel goedkoper is dan itereren op geschreven code. De meeste problemen komen aan het licht voordat er ook maar één regel geïmplementeerd is.
Docker, VM's en NFS
AI agents genereren niet alleen tekst — ze voeren code uit, installeren dependencies, draaien tests en interacteren met het bestandssysteem. Dat binnen je hostmachine draaien is een fout die je één keer maakt. Mijn opzet gebruikt Docker containers die draaien binnen een virtuele machine. Projectbestanden worden via een NFS mount beschikbaar gesteld aan de containers. De agents werken op de echte codebase zonder directe toegang tot de host.
Deze gelaagde isolatie is in de praktijk belangrijk. Als een agent een onverwacht pakket installeert, een commando uitvoert met neveneffecten, of code produceert die luid faalt tijdens runtime, is de schade beperkt tot de container. De VM-grens is een tweede isolatielaag. Containers kunnen schoon worden herbouwd tussen sessies, zodat er geen opgehoopte staat is van de ene taak die de volgende vervuilt.
Met meerdere SSH-sessies naar de VM is het eenvoudig om meerdere agents parallel te draaien — verschillende agents op verschillende taken, of verschillende agents op verschillende projecten tegelijk. De NFS-opzet betekent dat elke container dezelfde bestanden ziet zonder duplicatie of synchronisatie-overhead.
Eén workflow, vele stacks
Het scala aan projecten waarop ik deze workflow toepas is breder dan je misschien verwacht: websites, Flutter/Dart mobiele applicaties, C programma's, Laravel backends, React en Vue frontends, studiemateriaalvoorbereiding voor het efficiënt doorwerken van grote hoeveelheden content, en het schrijven van teksten. De stacks zijn op bijna elk relevant vlak anders — taal, runtime, build tooling, testaanpak.
De plan-review-iteratie workflow is stack-agnostisch. De discipline zit in het proces, niet in de tooling. Wat ertoe doet is de agent duidelijke context geven over wat er al bestaat, wat de taak vereist en welke beperkingen er gelden. AI agents gaan beter om met het wisselen tussen stacks dan ik aanvankelijk verwachtte, mits die context expliciet wordt aangeleverd in plaats van verondersteld.
Dezelfde Docker-in-VM-over-NFS infrastructuur ondersteunt al deze stacks met minimale herconfiguratie. Het container-image verandert; de workflow niet.
Waarom twee modellen beter zijn dan één
De effectiviteit van de dual-agent review komt neer op het feit dat elk model verschillende trainingsdata, verschillende architectuurkeuzes en verschillende neigingen heeft in hoe het problemen benadert. Claude neigt naar grondigheid en over-engineert soms oplossingen. Codex is vaak directer en zal signaleren wanneer Claude complexiteit heeft toegevoegd die het probleem niet vereist. Het omgekeerde gebeurt ook: Codex kan randgevallen missen die Claude opvangt wanneer de posities worden omgedraaid.
De adversariële dynamiek — de ene agent bouwt, de andere zoekt actief naar problemen — weerspiegelt wat er gebeurt in een functionerend menselijk code review proces. Concreet vangt de reviewcyclus regelmatig het volgende op: ontbrekende foutafhandeling voor ongebruikelijke maar geldige invoer, te permissieve configuraties, incorrecte aannames over hoe bestaande code werkt, abstracties die technisch correct zijn maar moeilijker te onderhouden dan een eenvoudiger alternatief, en beveiligingsproblemen die makkelijk over het hoofd worden gezien als je op functionaliteit gefocust bent.
Dit is geen bewering dat het ene model superieur is aan het andere. De waarde zit in de combinatie. Twee agents met verschillende blinde vlekken, in een expliciete reviewrelatie, produceren sterker resultaat dan elk van hen alleen.
Een voor de hand liggende vraag is of het toevoegen van een derde agent de dingen verder zou verbeteren. In de praktijk nemen de opbrengsten snel af. Een derde agent die hetzelfde plan reviewt zou òf het eens zijn met een van de bestaande twee — wat geen nieuwe informatie toevoegt — òf een derde mening introduceren die een tiebreaker vereist, wat convergentie vertraagt in plaats van helpt. Twee agents dekken de constructieve en adversariële rollen al over meerdere reviewrondes. De enige uitzondering is commit-review na implementatie, die op andere context opereert (daadwerkelijke code in plaats van een plan) en oprecht baat heeft bij een vers paar ogen. Daarnaast verhoogt het stapelen van meer agents op dezelfde taak de tokenkosten en latentie zonder een evenredige kwaliteitswinst.
De ontwikkelaar blijft in de loop
Planning, implementatie en review delegeren aan AI agents betekent niet dat de ontwikkelaar verdwijnt. Ik blijf de uiteindelijke beslisser over elke output. De agents produceren voorstellen; ik beslis wat er gecommit wordt. Dat onderscheid is belangrijk.
In de praktijk grijp ik in op meerdere punten: wanneer agents in een lus blijven hangen op hetzelfde meningsverschil zonder te convergeren, wanneer het plan is afgedwaald van wat daadwerkelijk gevraagd was, wanneer een beslissing domeinkennis of bedrijfscontext vereist die de agents niet hebben, en wanneer de output er simpelweg niet goed uitziet zelfs als ik niet direct kan verwoorden waarom. Dat laatste is het serieus nemen waard — ontwikkelaarsintuïtie die over jaren werken in een codebase is ontwikkeld, is niet iets wat een agent heeft.
De rol verschuift van elke regel zelf schrijven naar aansturen, valideren en bijsturen. Het lijkt meer op een tech lead zijn die zeer snelle junior developers heeft, dan op vervangen worden door automatisering. De efficiëntie komt door gestructureerd toezicht, niet door het weglaten van toezicht.
Kwaliteit erin, kwaliteit eruit
De kwaliteit van wat een AI agent produceert is een directe functie van de kwaliteit van wat je het geeft. Vage taakbeschrijvingen produceren vage resultaten. Een instructie als “verbeter de authenticatie-flow” zal iets produceren — maar of het iets nuttigs is hangt geheel af van welke context je geeft over de bestaande flow, wat er specifiek moet verbeteren en welke beperkingen er gelden.
Goede context omvat: een precieze beschrijving van wat er gedaan moet worden, de relevante bestandspaden, de patronen die al in gebruik zijn in de codebase, eventuele beperkingen (prestaties, backward compatibility, codestandaarden), en hoe een succesvol resultaat eruitziet. Het schrijven van die context kost tijd, maar het is goed bestede tijd. Agents die duidelijke context hebben produceren plannen die minder revisiecycli nodig hebben.
Leren effectieve context te schrijven is een vaardigheid die verbetert met oefening. Vroege pogingen zijn doorgaans te weinig gespecificeerd, en je itereert meer. Latere pogingen zijn strakker, en de plan-review-cyclus convergeert sneller. Context structureren voor een AI agent is nauw verwant aan het schrijven van een goed ticket voor een menselijke ontwikkelaar: als je niet duidelijk kunt uitleggen wat je wilt, is het probleem niet de tool.
Wanneer AI het fout heeft
AI agents zijn niet onfeilbaar, en ze als zodanig behandelen is waar projecten misgaan. Ze hallucineren — beschrijven met overtuiging API's of bibliotheken die niet bestaan. Ze raken vast in lussen, passen dezelfde fix herhaaldelijk toe wanneer het niet werkt. Ze produceren code die er plausibel uitziet maar incorrect is, en ze zullen soms foutieve benaderingen met schijnbare overtuiging verdedigen.
Veelvoorkomende faalpatronen die ik ben tegengekomen: een agent probeert herhaaldelijk een fix die de oorzaak niet aanpakt; een agent verzint een functie of methode die niet bestaat in de bibliotheek waarmee het werkt; een agent begrijpt de bestaande codebase verkeerd ondanks dat relevante context is gegeven, omdat die context onvolledig of misleidend was. Het vroeg herkennen van deze patronen is belangrijk. Wanneer output geen vooruitgang meer boekt of in cirkels begint te draaien, is doorgaan met de lus voeden contraproductief.
Wanneer dit gebeurt, is de juiste reactie ingrijpen: de context resetten, het probleem herformuleren, de taak in een kleiner stuk breken dat makkelijker te beredeneren is, of dat deel soms gewoon handmatig doen. Als de output simpelweg slecht is, gooi het weg en begin opnieuw. Sunk cost-denken is niet van toepassing op gegenereerde code — er is geen vakmanschap in geïnvesteerd dat het waard is om te bewaren.
De planning-eerst workflow vermindert deze falen omdat de meeste problemen aan het licht komen tijdens de planreviewfase, voordat er implementatie heeft plaatsgevonden. Een slecht plan is veel goedkoper om weg te gooien dan slechte code.
AI agents veilig draaien
AI agents die code uitvoeren, pakketten installeren en naar het bestandssysteem schrijven moeten in een geïsoleerde omgeving draaien. Dit is niet optioneel. De Docker-in-VM opzet die ik gebruik biedt gelaagde containment: onverwacht gedrag van een agent treft de container, niet de host. De VM-grens biedt een tweede laag. Zelfs als er iets ernstig misgaat binnen een container, zijn de hostmachine en andere projecten niet aangetast.
Door AI gegenereerde code kan beveiligingskwetsbaarheden introduceren: SQL injection door onjuist geparametriseerde queries, onveilige standaardconfiguraties, te permissieve bestands- of netwerktoegang, ontbrekende invoervalidatie. De reviewcyclus helpt deze op te vangen, maar elimineert ze niet. Bewustzijn en een beveiligingsbewuste eindreview blijven noodzakelijk.
Eén praktijk die het expliciet benoemen waard is: voer geen gevoelige credentials, API-sleutels of productiedata in AI agent-contexten in tenzij de omgeving goed beveiligd is en je begrijpt waar die data naartoe gaat. Het gemak van een agent volledige context geven is reëel, maar het risico van het onzorgvuldig doen ook.
Een praktische tool, geen vervanging
AI agents zijn een force multiplier voor ontwikkelaars die structuur en discipline toepassen op het proces. Het beperkte contextvenster — vaak aangehaald als beperking — blijkt een discipline op te leggen die sowieso de moeite waard is: plan zorgvuldig, werk in goed afgebakende stukken, review voor je uitvoert. Dit zijn goede engineeringpraktijken met of zonder AI-betrokkenheid.
De workflow die in dit artikel beschreven wordt is niet theoretisch. Hij is toegepast op websites, Flutter mobiele applicaties, C programma's, Laravel backends, React en Vue frontends, studiemateriaalvoorbereiding en het schrijven van teksten. Het proces past zich aan de stack aan; de stack dicteert het proces niet.
De ontwikkelaar die het probleem begrijpt, het proces aanstuurt en de output valideert, is nog steeds degene die het resultaat levert. AI agents maken dat sneller. Ze maken het niet overbodig.
Vragen over het integreren van AI in je ontwikkelworkflow? Neem gerust contact op.
