AI-development: context, controle en vakmanschap

AI in softwareontwikkeling is in korte tijd veranderd van slimme autocomplete naar iets dat veel dieper in het ontwikkelproces zit. Het gaat niet meer alleen om een losse functie aanvullen of een stukje documentatie laten schrijven. AI-tools analyseren bugs, stellen tests voor, bereiden refractors voor en kunnen steeds vaker zelf een pull request openen.

Tekst: Samsor Wali

Dat is een forse verschuiving ten opzichte van een paar jaar geleden. Maar het legt ook iets bloot wat in softwareontwikkeling altijd al waar was: code schrijven is maar een deel van het werk. Goede software bouwen gaat over bedrijven wat een klant nodig heeft, keuzes maakt in architectuur, risico’s inschatten, testen, beveiligen, onderhouden en uitleggen waarom iets werkt. Juist nu AI sneller code kan genereren, wordt dat verschil belangrijker. Want code op commando is nog geen software.

Een paar jaar geleden ging het gesprek vooral over de vraag of AI bruikbare code kon schrijven. Anno 2026 is de vraag: hoe zorgen we dat AI-gegenereerde output past bij de bedoeling, de architectuur, de security-eisen en de manier waarop een team werkt?

Die verschuiving zagen Alex, Ben, Kimball en Samsor ook terug tijdens AI Engineer Europe 2026 in Londen. Daar ging het niet alleen over modellen en demo’s, maar juist over product-grade agents, demand-driven context en harness engineering. De nuchtere conclusie: snelheid mag nooit ten koste gaan van kwaliteit, veiligheid en controle.

Ook Microsoft zette die lijn centraal tijdens Build 2026. Niet het losse AI-model is de onderscheidende factor, maar het systeem eromheen: GitHub, context, deloyment, governance, security, evaluaties, traces en feedbackloops.2 Dat is een belangrijk signaal. AI-driven development is geen knop die je aanzet. Het is een manier van werken die je moet inrichten.

Dat vraagt om twee dingen tegelijk: vastleggen wat je bedoelt, en toegankelijk maken wat nu nog verspreid zit over tickets, documentatie en de hoofden van developers.

De prompt is te licht geworden

Een goede prompt kan helpen. Maar bij serieuze softwareontwikkeling is een prompt vaak te vluchtig. Hij verdwijnt in een chat, mist projecthistorie en is zelden een duurzame bron van waarheid. Voor kleine taken is dat prima. Voor grotere wijzigingen wordt het gevaarlijk.

Microsoft noemt dat in een recent blog over spec-driven development het probleem van prompt-first workflows. Als requirements, constraints en edge cases alleen in prompts staan, krijg je wel snelle output, maar geen stevig houvast. Het gevolg: architectural drift, inconsistente implementaties, moeilijkere reviews en rework zodra aannames verschillen tussen mensen of tools.

Daarom wordt het vastleggen van intentie belangrijker. Wat moet het systeem doen? Wat juist niet? Welke randvoorwaarden gelden er? Welke edge cases zijn belangrijk? Wanneer is het goed genoeg? AI kan pas echt helpen als die context expliciet is.

Context hoort niet alleen in iemands hoofd

In veel projecten zit belangrijke kennis verspreid. Een deel staat in tickets. Een deel in oude documentatie. Een deel in code comments. En een deel zit gewoon in het hoofd van de developer die ooit de eerste versie bouwde.

Voor mensen was dat al lastig. Voor AI is het nog lastiger. Een AI-assistent kent niet vanzelf de domeintaal van de klant, de uitzonderingen in een proces of de reden waarom een integratie ooit net anders is opgezet dan je technisch zou verwachten.

Thoughtworks zette daarom in de Technology Radar van april 2026 Curated Shared Instructions for Software Teams op Adopt. Hun punt is simpel maar sterk: teams moeten niet blijven leunen op losse prompts van individuele developers. AI-instructies moeten een gedeeld engineeringmiddel worden, bijvoorbeeld via instructiebestanden in de repository, service templates en organisatie brede promptbibliotheken.

Martin Fowler beschrijft dezelfde beweging als context engineering: bewust bepalen wat het model ziet, zodat het betere resultaten kan leveren. Daarbij gaat het niet alleen om instructies, maar ook om guidance, regels, specs, voorbeelden en workflows.

Dat klinkt misschien als een nieuwe term, maar de gedachte is herkenbaar. Goede teams werken al met standaarden, architectuurbesluiten, reviewcriteria en testafspraken. AI verandert dat niet. AI maakt alleen pijnlijk zichtbaar waar die afspraken ontbreken.

Stack Overflow bracht begin 2026 een interessante spanning onder woorden. In hun developer survey gebruikte of plande 84 procent van de respondenten AI-tools te gebruiken, maar slechts 29 procent zei AI-output te vertrouwen. Stack Overflow noemt dat de AI Trust Gap.

Dat is geen bewijs dat AI faalt. Het laat vooral zien dat developers hun werk serieus nemen. Een model kan een antwoord geven dat er overtuigend uitziet, maar toch net naast de vraag zit. Of code voorstellen die compileert, maar niet past bij de architectuur. Of een security-randgeval missen omdat het de context niet kent.

Juist daarom is blind vertrouwen geen volwassen AI-strategie. De waarde zit niet in “AI heeft iets gegenereerd,” maar in “we kunnen aantonen dat het klopt.”

Als AI meer output maakt, schuift de bottleneck. Het probleem is dan niet meer alleen code schrijven, maar vooral code beoordelen. Kunnen we de wijziging begrijpen? Is het gedrag getest? Past het binnen de bestaande architectuur? Is de security gecontroleerd? Kunnen we het straks ook onderhouden?

OpenAI beschreef in februari 2026 hoe hun engineers met Codex werkten in een agent-first omgeving. Een opvallende les: als iets misging, was de oplossing meestal niet “probeer nog eens.” De vraag was eerder: welke capability ontbreekt, en hoe maken we die zichtbaar en afdwingbaar voor de agent? Naarmate de output toenam, werd menselijke QA-capaciteit de bottleneck. Daarom maakten ze onder andere logs, metrics, UI-states en tooling beter leesbaar voor Codex.

GitHub beweegt in dezelfde richting. De Copilot Coding Agent krijgt steeds meer functies rond self-review, security scanning, custom agents, planning before coding en het behouden van context tussen cloud en lokale workflows. Dat laat zien waar de markt heen gaat: niet alleen sneller genereren, maar beter sturen en verifiëren.

Controle is dus geen rem op snelheid. Controle is wat snelheid veilig maakt.

Een van de meest onderbouwde conclusies komt nog steeds uit het DORA-onderzoek naar AI-assisted softwaredevelopment. Hoewel dat rapport uit 2025 komt, is het op dit moment nog steeds een van de weinige concrete onderzoeken naar AI in softwareteams. De kern: AI is vooral een amplifier. Het vergroot de bestaande sterktes en zwaktes van een organisatie.

Dat verklaart waarom dezelfde tool bij het ene team veel waarde oplevert en bij het andere team vooral ruis veroorzaakt. Heeft een team heldere afspraken, goede tests, duidelijke ownership en korte feedbackloops, dan kan AI daarop meeliften. Ontbreekt die basis, dan versnelt AI vooral de chaos.

AI-driven development begint daarom niet bij een toolkeuze. Het begint bij de vraag of je team goed genoeg georganiseerd is om AI-output te sturen, te controleren en te verbeteren.

De rol van de developer verandert hierdoor wel degelijk. Maar niet op de simpele manier die vaak wordt voorspeld. De developer verdwijnt niet omdat AI code kan schrijven. Het zwaartepunt van het werk verschuift.

Minder waarde zit in het handmatig uitschrijven van boilerplate. Meer waarde zit in probleembegrip, domeinkennis, ontwerpkeuzes, security, testbaarheid, review en communicatie. De developer wordt meer iemand die context organiseert, keuzes onderbouwt en kwaliteit bewaakt.

Anthropic zag in hun Economic Index van maart 2026 dat ervaren Claude-gebruikers de tool vaker collaboratief inzetten, voor complexere en meer werkgerelateerde taken, en met meer succes. Ze noemen dat learning-by-doing: wie beter leert samenwerken met AI, haalt er meer waarde uit.

Dat is ook relevant voor development. Goed werken met AI is geen trucje. Het vraagt om vakkennis. Je moet genoeg begrijpen om goede vragen te stellen, de output te beoordelen en te zien wanneer een antwoord logisch lijkt maar toch verkeerd is.

AI-driven development betekent niet dat we zo veel mogelijk code door een model laten schrijven. Het betekent dat we AI bewust inzetten in de hele ontwikkelcyclus. Bij het aanscherpen van requirements. Bij het bedenken van scenario’s. Bij het vergelijken van ontwerpopties. Bij code, tests, refactoring, reviews, documentatie en beheer.

Maar de verantwoordelijkheid blijft bij het team. AI kan helpen met snelheid, varianten en eerste versies. Mensen blijven nodig voor richting, oordeel, context en eigenaarschap. Voor een professioneel softwareteam draait AI-driven development daarom om drie vragen:

1. Is de bedoeling duidelijk genoeg vastgelegd om AI goed te laten helpen?
2. Is er genoeg context beschikbaar voor mens en machine?
3. Is de controle sterk genoeg om met meer output om te gaan?

Het antwoord op die vragen bepaalt niet alleen of AI vooral snelheid oplevert of ook zekerheid. Het bepaalt ook wie straks het verschil maakt. Niet het team dat de meeste code kan genereren, want die strijd is al bijna niet meer interessant, maar het team dat AI zo weet in te zetten dat software betrouwbaarder, veiliger en beter onderhoudbaar wordt.

Daarvoor is vakmanschap nodig. Misschien zelfs meer dan voorheen. Want hoe sneller code beschikbaar komt, hoe belangrijker het wordt om te begrijpen wat die code doet, waarom die nodig is en of hij past binnen het grotere geheel.

AI maakt code sneller beschikbaar. Maar vakmanschap bepaalt nog steeds of die code waardevol, veilig en onderhoudbaar is. Code op commando is nog geen software. Maar met de juiste context, controle en mensen die blijven nadenken, kan AI wel helpen om betere software te bouwen.

Bij Garansys passen we deze aanpak ook zelf toe. Binnen Reliable Scrum, onze resultaatgerichte manier van werken, leggen we context vast in heldere afspraken en specs, organiseren we controle via reviews en tests, en blijft de verantwoordelijkheid bij het team liggen. AI is daarbij een hulpmiddel, geen vervanging van dat proces.
Benieuwd hoe we dat in de praktijk toepassen? Ontdek hier onze AI-dienstverlening.