AI gebruiken als software developer is inmiddels normaal. Maar zonder duidelijke context, afspraken over kwaliteit en toetsbare verwachtingen ben je soms méér tijd kwijt aan het “goed krijgen” van de output dan wanneer je het zelf had gebouwd.
De winst zit dus in de aanpak: behandel AI als een extra collega die je strak aanstuurt. In dit artikel delen we Marco’s 7 manieren waarop hij AI effectief inzet: met voorbeelden en formuleringen die je direct kunt toepassen in .NET- en Azure-projecten.
TL;DR: laat AI vooral helpen met denkwerk (analyse, alternatieven, edge cases), knip werk op in kleine stappen, en koppel alles aan je normale engineering-discipline: done criteria, CI-guardrails, tests en review.
1) Begin altijd met een toetsbaar plan
Marco laat AI zelden meteen code schrijven. Hij start vrijwel altijd met een plan dat hij zelf kan lezen, bevragen en afkeuren als het niet klopt. Uiteindelijk bespaart dit tijd: je voorkomt dat je met overtuigend klinkende output een verkeerde richting op sprint.
“Eerst laat ik een plan maken. Dat lees ik zelf kritisch door. Pas als het klopt laat ik de uitvoering starten.”
Tip: vraag een plan met:
- aannames en openstaande vragen
- impactanalyse (breaking changes, migraties)
- teststrategie (unit/integration/contract)
- rollback-plan
Prompt: “Maak een stappenplan met een checklist per stap (done criteria) en noem de risico’s en tests die erbij horen.”
2) Hak werk op in kleine stappen en commit per stap
Grote opdrachten in één prompt leveren zelden controleerbare output op. Je krijgt veel tekst, veel code, en pas laat ontdek je dat er ergens een fundamentele aanname niet klopt. Marco werkt daarom liever in kleine, duidelijke stappen. Elke stap heeft een doel, een beperkte wijziging en een snelle verificatie.
“Bij nieuwe functionaliteiten knip ik het op in kleine brokken. Dan kan AI per stap heel gericht mee-implementeren.”
Tip: behandel AI-output alsof je pair-programt. Forceer kleine changes door:
- één functionele wijziging per PR/commit
- per stap een ‘verification’ (build + tests)
- expliciet vragen om diff output (“alleen de bestanden die wijzigen”)
3) Gebruik AI júist voor uitzoekwerk
AI is voor Marco niet alleen een versneller bij typen, maar vooral bij onbekend terrein: het begrijpen, analyseren en verkennen van alternatieven.
Een concreet voorbeeld uit zijn werk: een desktopapplicatie (WPF) waar een groot stuk van synchronous naar asynchronous moest. De UI blokkeerde zodra er data uit een API werd opgehaald. Klassiek probleem, maar in tooling waar je net niet dagelijks in leeft.
Marco is daar open over:
“Ik ben geen WPF-specialist. Zonder AI had ik hier waarschijnlijk niet uit gekomen. Het hielp me door het uitzoekwerk heen.”
Tip: maak onderzoek output-gedreven:
- laat AI 2–3 oplossingsrichtingen schetsen met trade-offs
- laat het edge cases benoemen (threading, deadlocks, retries)
- vraag om een minimal reproducible example
In .NET-context: vraag expliciet naar async/await pitfalls, UI-thread marshaling, en cancellation tokens waar relevant.
4) Leer door te lezen en door te vragen
Marco ziet AI ook als leermaatje. Maar alleen als je actief meedenkt en ‘waarom’-vragen stelt.
“Het is vooral discipline. Als je de output leest en doorvraagt, leer je enorm. Als je alleen kopieert, leer je weinig.”
Tip: laat AI zichzelf reviewen:
- “Welke delen van deze oplossing zijn het meest foutgevoelig en waarom?”
- “Waar zou een reviewer kritiek op hebben (readability, performance, security)?”
- “Welke aannames heb je gedaan die ik moet bevestigen?”
Een werkvorm die vaak goed werkt: laat AI één paragraaf uitleg schrijven alsof het een PR-review comment is. Dan zie je snel of het verhaal klopt (en of je later nog begrijpt waarom je iets zo hebt gebouwd).
5) Bewaak kwaliteit, je moet kunnen toetsen wat je accepteert
AI kan overtuigend klinken, ook als het niet klopt. Daarom heb je basiskennis nodig om te reviewen.
“Je moet wel genoeg basiskennis hebben om te kunnen toetsen wat je accepteert. Anders lijkt alles ‘prima’ tot het ergens stukloopt en je niet weet waarom.”
Tips:
- Laat AI code schrijven die door je CI gedwongen wordt: formatting + linting + tests.
- In .NET: zet analyzers aan (Roslyn analyzers / style rules) en fail de build op warnings waar passend.
- Vraag AI om tests mee te leveren: unit tests voor pure logic, integration tests voor API/DB, en contract tests waar je afhankelijkheden hebt.
- Vraag expliciet om input validation, logging, en error handling (en hoe dat past in jullie observability).
Security/PII & IP-guardrails
AI-assisted development werkt pas veilig als je ook hier duidelijke afspraken over maakt. In consultancy-context is dit extra belangrijk: je wilt nooit per ongeluk klantdata, PII of secrets in een prompt plakken.
Maak daarom teamafspraken die niet ter discussie staan. Deel geen keys, connection strings of tokens. Gebruik geen echte klantdata—anonimiseer of werk met synthetische voorbeelden. Plak geen complete logs of dumps zonder redactie. En laat AI geen “productieconfig” verzinnen: gebruik infrastructure-as-code en goedgekeurde templates.
In gevoelige context is het ook verstandig om alert te blijven op licentie/IP-risico’s bij externe snippets en gegenereerde code. Niet om paranoïde te worden, wel om professioneel te blijven.
6) Werk met rollen of ‘agents’
Marco experimenteert met workflows waarin meerdere AI-rollen samenwerken: een analist die doorvraagt, een ‘senior’ die naar architectuur kijkt, daarna implementatie, review en test.
“Ik start de workflow, laat die rollen hun werk doen, en kom terug om te reviewen. Pas dan gaat het door.”
Tip: ontwerp agent-rollen alsof het echte teamleden zijn:
- Analist: requirements, acceptatiecriteria, out-of-scope
- Architect: boundaries, dependencies, security, performance
- Developer: implementatie + tests
- Reviewer: naming, structure, duplication, edge cases
En: geef elke rol een duidelijke ‘interface’. Bijvoorbeeld: de architect levert ADR-achtige keuzes op, de developer levert code + tests + changelog.
Belangrijk: plan ook stopmomenten in waarop jij (of je team) beslist. Bijvoorbeeld na het plan, na de architectuurkeuzes en na het testresultaat/CI.
7) Leg fouten vast als instructies
Als AI iets doet wat hij niet wil (een terugkerende structuurfout, een stijl die niet past, een gevaarlijke shortcut), maakt Marco er direct een instructie van.
“Alles wat niet naar je zin is, moet je meteen als instructie vastleggen. Dan komt het niet steeds terug en bespaar je jezelf veel tijd in de toekomst.”
Tip: maak instructies concreet en toetsbaar:
- “Max 1 class per file” is helder.
- “Gebruik async all the way” is helder.
- “Gebruik structured logging met correlation id” is helder.
En als je dit team-breed wil maken: behandel instructies als code. Version ze, review ze, en wijzig ze bewust (net als coding guidelines).
Tot slot
Marco’s benadering is nuchter: AI is geen autonome developer, maar een versneller. Het niveau gaat omhoog als je AI koppelt aan je normale engineering-discipline: kleine changes, duidelijke done criteria, CI guardrails, tests en review.
Wil je dit als team aanpakken? Maak één gezamenlijke AI working agreement (prompts, stijl, testverwachtingen, security/PII-regels) en verwerk die in je Definition of Done.