Een recent onderzoek van METR zette me aan het denken. Ze lieten zestien ervaren open-source developers — gemiddeld vijf jaar ervaring met hun eigen codebase — werken met en zonder AI-tools. Het resultaat: met AI waren ze 19% tráger. Maar het opvallendste? Ze dáchten 20% sneller te zijn.

Onderzoekers van de Universiteit van Tilburg vonden iets vergelijkbaars: AI helpt minder ervaren programmeurs sneller code schrijven, maar ervaren developers verschuiven naar reviewen en corrigeren — en worden per saldo niet productiever.

Dit is geen argument tegen AI-tools. Het is een argument voor een betere manier van samenwerken. Want het verschil tussen developers die er wél sneller van worden en developers die er niet veel aan hebben, zit niet in de tool. Het zit in de aanpak.

1. Denk eerst, prompt daarna

Het grootste anti-pattern dat ik zie — ook bij mezelf in het begin — is meteen code laten genereren. “Maak een notificatiesysteem.” En dan verbaasd zijn dat het resultaat technisch werkt, maar totaal niet past bij je architectuur.

Addy Osmani, engineering lead bij Google, noemt zijn aanpak “waterfall in 15 minuten”: schrijf eerst een korte spec met de AI, beschrijf edge cases, en laat het daarna pas bouwen. De planning duurt een paar minuten, maar bespaart je een uur aan correcties.

In Claude Code betekent dit: begin in Plan Mode. Laat Claude je codebase lezen, je architectuur begrijpen, en een aanpak voorstellen vóórdat er één regel code wordt geschreven.

Zonder plan:

“Bouw een notificatiesysteem voor statuswijzigingen.”

Claude maakt een eigen NotificationService, een nieuwe tabel, en een polling-mechanisme. Technisch correct. Totaal niet hoe jullie het doen.

Met plan:

“We willen notificaties bij statuswijzigingen. Kijk eerst hoe we events afhandelen in /Application/EventHandlers. Maak een plan dat past bij onze bestaande architectuur.”

Claude ziet dat jullie al een IEventHandler<T>-pattern hebben en stelt voor om daarop voort te bouwen. Geen nieuw systeem, maar een uitbreiding van wat er al staat.

2. Geef context, niet alleen een opdracht

Onderzoekers van UC San Diego en Cornell bestudeerden 99 professionele developers en observeerden er dertien in hun dagelijkse werk. Eén ding viel op: ervaren developers geven altijd bestandsnamen, functienamen en foutmeldingen mee. Ze laten de AI niet raden.

Het verschil:

Vaag:

“De build faalt. Fix het.”

Scherp:

“De build faalt met deze error: [foutmelding]. Check de validatielogica in OrderValidator.cs. Fix de oorzaak, niet het symptoom. Run dotnet test na de fix.”

In de vorige post schreef ik over CLAUDE.md als structurele context — de dingen die Claude altijd moet weten. Maar even belangrijk is de ad-hoc context die je per vraag meegeeft. Hoe specifieker je bent over welke bestanden, welke patronen en welk eindresultaat je verwacht, hoe beter het resultaat.

3. Stuur op richting, niet op elke regel

Er zijn twee uitersten. Aan de ene kant: alles dicteren, elke regel code voorschrijven. Dan kun je het net zo goed zelf typen. Aan de andere kant: alles accepteren zonder te kijken. Dat is wat ze “vibe coding” noemen — en uit de Stack Overflow-enquête van 2025 blijkt dat 72% van professionele developers dat bewust níét doet.

De sweet spot zit ertussenin. Datzelfde UC San Diego-onderzoek laat zien: geen enkele ervaren developer liet AI volledig autonoom werken. Maar ze stuurden gemiddeld per twee stappen bij — niet per regel.

Denk aan het aansturen van een collega. Je zegt niet: “Type op regel 14 een if-statement met deze exacte conditie.” Je zegt: “De validatie moet ook rekening houden met inactieve gebruikers. Kijk hoe we dat bij orders doen.” Richting geven, niet dicteren.

Addy Osmani verwoordt het zo: “Every engineer is a manager now.” Je orkestreert en valideert. Je hoeft niet alles zelf te schrijven, maar je moet wel alles begrijpen.

4. Weet wanneer je opnieuw begint

Dit is misschien de belangrijkste les die ik heb geleerd: soms is bijsturen duurder dan opnieuw beginnen.

De vuistregel die ik hanteer: als je Claude twee keer corrigeert op hetzelfde punt, is je context vervuild met mislukte pogingen. Begin opnieuw. In Claude Code: /clear, revert naar je laatste goede commit, en schrijf een betere prompt waarin je meeneemt wat je de eerste keer hebt geleerd.

John Lindquist van egghead.io zegt het simpel: “Starting over works every time.” En hij heeft gelijk. Een schone sessie met een scherpe prompt levert bijna altijd een beter resultaat dan een lange sessie vol correcties.

De signalen dat je beter opnieuw kunt beginnen:

  • Je herhaalt dezelfde correctie voor de derde keer
  • De antwoorden worden circulair
  • De code wordt met elke iteratie complexer in plaats van simpeler
  • Je merkt dat je gefrustreerd raakt

Dat laatste is serieus. Frustratie is een signaal dat je aan het worstelen bent met de context, niet met het probleem.

5. Vertrouw, maar verifieer altijd

Een onderzoek van Sonar onder 1.100 developers leverde een veelzeggende paradox op: 96% vertrouwt AI-gegenereerde code niet volledig. Maar 48% checkt het niet altijd voor ze committen.

Dat is alsof je een collega niet vertrouwt, maar ook niet naar zijn code kijkt.

Anthropic’s eigen documentatie is hier glashelder over: “Give Claude a way to verify its work. This is the single highest-leverage thing you can do.” Verifiëren is niet optioneel — het is het belangrijkste dat je kunt doen.

Concreet in een .NET-project:

“Implementeer de endpoint, schrijf tests voor het happy path en de belangrijkste edge case, en run dotnet test. Fix eventuele failures.”

Door verificatie onderdeel te maken van je prompt, bouw je een feedbackloop in. Claude schrijft code, test het zelf, en fixt wat niet werkt — voordat jij er überhaupt naar kijkt.

Kent Beck — de bedenker van Test-Driven Development — zegt dat TDD juist belangrijker wordt met AI, niet minder. Het is het vangnet dat ervoor zorgt dat snelheid niet ten koste gaat van kwaliteit.

Het is een vaardigheid, geen knop

Uit de Stack Overflow-enquête van 2025 blijkt dat 66% van developers meer tijd kwijt is aan het fixen van “bijna-goede” AI-code dan het zou kosten om het zelf te schrijven. Dat cijfer klinkt als een aanklacht tegen AI-tools. Maar ik denk dat het eerder een signaal is dat de meeste developers nog bezig zijn deze samenwerking te leren.

Effectief samenwerken met AI is een vaardigheid die je ontwikkelt. Net als pair programming, code review, of het aansturen van een team. Het gaat niet om de perfecte prompt of de juiste tool. Het gaat om een manier van werken: plannen voordat je begint, context meegeven, bijsturen op het juiste moment, en altijd — altijd — het eindresultaat zelf beoordelen.

Begin met één ding. De volgende keer dat je een prompt typt, stel jezelf eerst de vraag: weet Claude genoeg om dit goed te doen? Als het antwoord nee is, geef het wat het nodig heeft. Je zult het verschil merken.