Hoe je het maximale uit AI-assisted development haalt

Leestijd: 8 minuten

Samenvatting. AI-tools maken het schrijven van code eenvoudig en snel. Maar ze werken met beperkte context en zonder geheugen: elke sessie begint opnieuw. Zonder supervisie ontstaan sluipende afwijkingen die een codebase langzaam inconsistent maken. Het maximale haal je uit AI-assisted development met vier dingen: guardrails die context laten meereizen, slim begeleiden van de agent, review op abstract niveau in plaats van regel voor regel, en een werkwijze die past bij het probleem en het type applicatie. De snelheid komt van de tool. De richting en samenhang blijven mensenwerk.

Dit artikel is gebaseerd op intensief experimenteren met AI-assisted workflows sinds de opkomst van grote taalmodellen. Verschillende tools, verschillende werkwijzen, verschillende typen applicaties. Wat hier staat is geen theorie, maar wat overbleef na veel proberen. Inclusief wat niet werkte.

Code maken is eenvoudig geworden

Laten we beginnen waar het goed nieuws zit. AI-assisted development levert echte winst op. Routinewerk dat vroeger een dag kostte, is in een uur klaar. Een koppeling volgens een bekend patroon, de zoveelste variant van een formulier, testwerk, migraties: een goed aangestuurde agent doet het sneller dan een mens, en vaak netter.

Die winst is geen belofte maar praktijk. Wie het goed organiseert, bouwt aantoonbaar sneller en goedkoper. Dat voordeel hoort te landen waar het thuishoort: bij de opdrachtgever, in doorlooptijd en in prijs.

Maar wie er het maximale uit wil halen, moet eerst begrijpen waar het misgaat. De tool heeft twee eigenschappen die zelden hardop worden benoemd.

De tool ziet maar een stukje

Een AI-model voorspelt wat waarschijnlijk past. Niet wat juist is voor jouw systeem. Dat is geen tekortkoming van een specifieke tool. Het is de aard van het mechanisme.

Het model kent je conventies niet. Het kent de afweging niet die je vorig jaar maakte, of de reden achter die ene uitzondering in je datamodel. Het ziet het stuk code dat je aanwijst, plus wat het aan context meekrijgt. Daarbinnen maakt het iets dat eruitziet als de juiste oplossing.

Het gevolg zijn zelden grote fouten. Het gevolg zijn sluipende afwijkingen: net een ander patroon dan de rest van het systeem, net een andere naamgeving, een tweede oplossing voor iets dat elders al was opgelost. Elke afwijking is op zichzelf onschuldig en passeert elke oppervlakkige review. Opgeteld leveren ze een codebase op die niemand meer helemaal kent. Elke wijziging wordt langzamer, elke nieuwe ontwikkelaar heeft langer nodig.

De cijfers bevestigen dat beeld. Onderzoek van Veracode liet zien dat bijna de helft van AI-gegenereerde code zakt voor securitytests, en dat een ruime meerderheid ontwerpfouten bevat. Ontwikkelaars weten het zelf ook: de overgrote meerderheid gebruikt de tools dagelijks, maar minder dan een derde vertrouwt de uitkomst zonder controle.

Elke sessie begint opnieuw

De tweede eigenschap is minstens zo bepalend, en wordt vaker over het hoofd gezien: de context is nooit twee keer dezelfde.

Wat je gisteren aan de agent hebt uitgelegd, is vandaag weg. Elke sessie start blanco, met een net iets andere selectie van je codebase in beeld. Het is alsof er elke ochtend een briljante nieuwe medewerker binnenloopt: razendsnel, breed onderlegd, eindeloos productief. En zonder enig geheugen van het bedrijf.

Tien sessies zonder structuur betekenen tien interpretaties van jouw systeem. Niet omdat de tool slecht is, maar omdat niemand de interpretatie heeft vastgelegd. Consistentie ontstaat niet vanzelf. Die moet je organiseren.

Guardrails: consistentie moet je borgen

De oplossing is niet harder controleren achteraf. De oplossing is de context vastleggen, zodat hij elke sessie meereist. In de praktijk werken vier guardrails:

1. Architectuurprincipes en conventies als levend document. Een compact bestand dat beschrijft hoe het systeem in elkaar zit, welke patronen gelden en waarom. Niet voor de la, maar als vaste context die elke sessie meekrijgt. De agent van vanochtend hoort hetzelfde verhaal als die van gisteren.
2. Bewezen bouwstenen in plaats van vrije stijl. Vaste patronen, vaste bibliotheken, vaste manieren om veelvoorkomende problemen op te lossen. Hoe minder vrijheidsgraden in de uitvoering, hoe minder ruimte voor afwijking. Creativiteit hoort in de oplossing van het probleem, niet in de honderdste variant van hetzelfde.
3. Klein werken, en werkend bewijzen. Afgebakende taken, elk stuk aantoonbaar werkend voordat het volgende begint. Een afwijking in een kleine stap is een correctie. Een afwijking in een week ongecontroleerd genereren is een verbouwing.
4. Review op afwijking, niet alleen op fouten. De vraag is niet alleen: werkt het? De vraag is: past het bij hoe de rest van het systeem werkt? Een stuk code kan foutloos zijn en toch het systeem ondermijnen.

Één kanttekening bij het eerste punt, want daar gaat het vaak alsnog mis. Zo'n document, of een agent die het draagt, lost het probleem alleen op als het klein blijft. Hoe meer diverse en uiteenlopende instructies je in één context stopt, hoe groter de afwijkingen worden. Het model moet bij elke taak wegen welke van de honderd regels nu gelden, en die weging gaat subtiel mis.

Het is dezelfde wet die geldt in automatisering en procesoptimalisatie: opbreken in kleinere taken en verantwoordelijkheden maakt het resultaat sterker. Dus geen allesomvattend instructiebestand, maar een compacte kern die altijd geldt, met per soort taak de specifieke kaders erbovenop. De agent die een koppeling bouwt, hoeft de stijlregels voor schermen niet te kennen. Elke regel die er voor deze taak niet toe doet, is ruis die meeweegt.

Het gemeenschappelijke aan deze guardrails: er is iemand die het geheel bewaakt. De tool versnelt de uitvoering. De samenhang is, juist nu, mensenwerk.

Het nieuwe vakmanschap: begeleiden en abstract reviewen

Guardrails zijn het systeem. Daarbovenop komt een vaardigheid. Die bepaalt het verschil tussen teams die met AI versnellen en teams die met AI verdwalen.

Slim begeleiden. Een agent stuur je zoals je een capabele nieuwe medewerker stuurt. Niet "maak dit", maar eerst het waarom en de kaders. De taak afgebakend. Tussenresultaten laten zien voordat de volgende stap begint. En de agent laten verwoorden wat hij van plan is, voordat hij bouwt. In dat plan zie je een verkeerde aanname eerder dan in duizend regels code. Wie goed delegeert, haalt een veelvoud uit dezelfde tool.

Reviewen op abstract niveau. Regel voor regel reviewen van AI-output is dweilen met de kraan open. Er is te veel code, en hij oogt altijd plausibel. De review die ertoe doet zit een niveau hoger, op de essentiële elementen van de oplossing. Klopt de structuur? Liggen verantwoordelijkheden op de juiste plek? Volgt het de afgesproken patronen? Raakt het de juiste grenzen, van data tot koppelvlakken tot security? En de vraag die de tool zichzelf nooit stelt: had dit überhaupt gebouwd moeten worden, of was er een eenvoudiger weg?

De details mag je steekproefsgewijs vertrouwen. De vorm en de keuzes nooit ongezien.

Geen werkwijze past op alles

De laatste les uit jaren experimenteren is misschien de belangrijkste: er bestaat geen beste AI-workflow. De werkwijze volgt het probleem en het type applicatie, niet andersom.

• Een prototype of intern hulpmiddel. Geef de agent ruim baan. Snelheid boven structuur, weggooien mag. Hier is de versterking puur winst.
• Een koppeling in een productieomgeving. Strak gekaderd en klein. Elk stuk bewezen voordat het volgende begint, want hier kost een sluipende afwijking echt geld.
• Een bestaande codebase met geschiedenis. Eerst de context vastleggen: principes, patronen, de redenen achter de uitzonderingen. Pas dan genereren. Anders krijg je een elfde interpretatie naast de tien die er al waren.
• Nieuwbouw met een lange levensduur. Architectuur en patronen eerst, en de agent vult in. De keuzes van de eerste week worden door de versnelling duizendvoudig gerepliceerd. Ze moeten kloppen.

Wie één werkwijze op alles toepast, betaalt altijd. Of te veel structuur voor een wegwerpprototype, of te weinig voor een systeem dat tien jaar mee moet.

Conclusie: beter kaderen, hoger kijken

AI-assisted development versterkt wat je erin stopt. Een heldere structuur wordt sneller en consistenter uitgebouwd. Een onduidelijke wordt sneller een wirwar. Het maximale haal je er dan ook niet uit door meer te genereren, maar door beter te kaderen en hoger te kijken: context die meereist en klein blijft, een agent die wordt begeleid in plaats van losgelaten, review op de essentie in plaats van op de regels, en een werkwijze die past bij wat er op het spel staat.

De snelheid komt van de tool. De richting komt van mensen. Wie beide organiseert, krijgt het beste van twee werelden: de productiviteit van nu, en een systeem dat ook over vijf jaar nog één geheel is.

---

Veelgestelde vragen

Wat zijn sluipende afwijkingen in AI-gegenereerde code? Kleine, op zichzelf onschuldige verschillen die ontstaan doordat een AI-model de conventies en geschiedenis van een systeem niet kent: een afwijkend patroon, andere naamgeving, een dubbele oplossing voor een bestaand probleem. Opgeteld maken ze een codebase inconsistent en duur in onderhoud.

Waarom is elke AI-sessie anders? AI-coding-tools hebben geen geheugen tussen sessies en zien telkens een andere selectie van de codebase. Zonder vastgelegde context interpreteert elke sessie het systeem opnieuw, met inconsistentie als gevolg.

Lost een agent-instructiebestand het contextprobleem op? Deels. Het werkt alleen als de context klein en taakgericht blijft. Hoe meer diverse instructies in één bestand, hoe groter de afwijkingen: het model weegt bij elke taak alle regels mee, ook de irrelevante. Opbreken in kleinere taken en verantwoordelijkheden maakt het resultaat sterker.

Wat zijn guardrails in AI-assisted development? Afspraken en structuren die consistentie borgen: compacte architectuurprincipes als vaste context bij elke sessie, bewezen bouwstenen en patronen, klein werken met werkend bewijs per stap, en review die toetst op afwijking van het patroon in plaats van alleen op fouten.

Moet je AI-gegenereerde code regel voor regel reviewen? Nee. Effectieve review gebeurt op abstract niveau: structuur, verantwoordelijkheden, patronen en raakvlakken zoals data en security. Details controleer je steekproefsgewijs. De essentiële keuzes controleer je altijd.

Wordt softwareontwikkeling goedkoper door AI? De uitvoering wel, en dat voordeel hoort bij de opdrachtgever te landen in doorlooptijd en prijs. De totale winst hangt af van richting en bewaking. Zonder die twee produceert AI vooral sneller onderhoudslast.