AI gebruiken om te programmeren zonder bugs op te leveren

Wie AI gebruiken om te programmeren wil, begint vaak op dezelfde manier. Je opent een ticket, plakt de beschrijving in een chatvenster en krijgt 200 regels code terug die er plausibel uitzien. Het compileert. Twee dagen later vraagt een reviewer waarom de code je retry-wrapper negeert, en niemand in het team kan dat uitleggen. Het genereren verloopt meestal goed. Wat eromheen gebeurt, gaat vaak mis.

Hier is de werkwijze die ik nieuwe engineers meegeef. Ze behandelt het model als een snelle, zelfverzekerde junior die je repo nog nooit heeft gezien. Ze is gebouwd rond reviewtijd, niet rond typetijd.

Maakt AI je echt sneller in programmeren?

Soms wel, en het eerlijke antwoord hangt af van de taak. De Stack Overflow Developer Survey 2025 laat zien dat 84% van de respondenten AI-tools gebruikt of dat van plan is, maar dat slechts 33% de output tot op zekere hoogte vertrouwt. De grootste klacht, genoemd door 66%, is code die "bijna goed is, maar niet helemaal". Daarnaast zegt 45.2% dat het debuggen van AI-gegenereerde code meer tijd kost dan verwacht.

Gecontroleerde data is minder vleiend. In een studie uit 2025 van METR werkten 16 ervaren open-sourceontwikkelaars aan 246 echte issues in repo's die ze goed kenden. Met AI waren ze gemiddeld ongeveer 19% langzamer klaar, terwijl ze dachten ongeveer 20% sneller te zijn geweest. METR heeft sindsdien nieuwere data gepubliceerd, dus lees dit getal als een momentopname van de tools van begin 2025, niet als eindoordeel.

De conclusie is niet dat AI traag is. Het gevoel van snelheid is een slecht meetinstrument. Meet in minuten van ticket tot gemergde PR, niet in hoe snel het eerste concept verscheen.

Wat schrijf je op voordat je iets prompt?

Een plan, in je eigen woorden, in minder dan tien regels. Sla dit over en het model vult de gaten in met eigen gissingen, en die zijn per definitie generiek.

Mijn sjabloon is kort:

1. De gedragsverandering, in één zin.

2. De bestanden die je waarschijnlijk aanraakt, ook als je het niet zeker weet.

3. De bestaande functie of het bestaande patroon dat de nieuwe code moet hergebruiken.

4. Eén ding dat het niet mag doen, zoals een nieuwe dependency of een schemawijziging.

5. Hoe je weet dat het werkt: een test, een curl, een screenshot.

Punt 3 wordt het vaakst overgeslagen, en daar komt de meeste "bijna goed"-code vandaan. Het model weet niet dat je helper withRetry bestaat, tenzij je die noemt of het model hem zelf kan lezen.

Sla de prompt "bouw me de hele app" over. Beginners en senior ontwikkelaars krijgen er hetzelfde van: een grote diff die niemand begrijpt, en een project dat niet af is.

Hoe ziet een goede prompt er in de praktijk uit?

Neem een echte klus: de webhook-sender laat events vallen wanneer de ontvanger een time-out geeft. Een zwakke prompt zegt "maak webhooks betrouwbaarder". Een bruikbare prompt leest als een ticket.

Voeg retry met exponential backoff toe aan sendWebhook() in src/webhooks/sender.ts.
Hergebruik withRetry() uit lib/http.ts. Maximaal 4 pogingen, jitter aan.
Wijzig de publieke signatuur niet en voeg geen dependencies toe.
Voeg een vitest-case toe voor een ontvanger die twee keer faalt en daarna slaagt.

Die prompt noemt het bestand, de helper die hergebruikt moet worden, een limiet en een controle. Het resultaat is een diff van misschien 30 regels die je in één zitting kunt lezen. Komt de diff terug op 150 regels, dan is het model afgedwaald, en verwerp je hem in plaats van hem te bewerken.

Twee kleine trucs helpen. Vraag eerst om een plan en lees dat voordat er bestanden veranderen: een fout plan kost dertig seconden, een foute diff kost tien minuten. En als een antwoord niet klopt, herhaal dan de beperking die is geschonden in plaats van te discussiëren. "Je hebt een nieuwe dependency toegevoegd, de regel is geen" werkt beter dan een alinea uitleg.

Welk type AI-tool past bij welk werk?

Er bestaan drie vormen, en het verwarren ervan is de op één na meest voorkomende fout.

Inline completion voorspelt je volgende regels terwijl je typt. Dat werkt goed voor boilerplate en tests waarvan het patroon al op het scherm staat. Chat in de editor beantwoordt vragen over geselecteerde code en stelt wijzigingen voor die je per blok accepteert. Agents nemen een taak aan, lezen bestanden, draaien commando's en komen terug met een branch.

Kies op basis van hoe goedkoop je iets kunt verifiëren. Een completion die je in twee seconden leest, is laag risico. Een agent-run die 14 bestanden raakt, levert veel op maar kost veel reviewtijd.

Cursor is de editor-eerste keuze: een fork van VS Code met sterke Tab-completion en parallelle agent-sessies. Het loont als je de hele dag in een editor werkt. Sla het over als je team standaard op JetBrains zit en niet wil overstappen.

GitHub Copilot is de keuze met de minste wrijving voor teams die al op GitHub werken, omdat PR's, issues en review op één plek staan. Let op de kosten: sinds juni 2026 werkt het met op gebruik gebaseerde AI-credits, dus zwaar agentgebruik kost meer dan de prijs per stoel doet vermoeden.

Claude Code is terminal-native en agentisch: je delegeert een refactor of een bugjacht en beoordeelt daarna het resultaat. Er is geen inline autocomplete, en het werkt alleen met Claude-modellen. Dat is een redelijke ruil als je taakgewijs wilt delegeren.

Aider is de scriptbare, git-native optie. Het maakt bij elke wijziging automatisch een commit met een bericht, dus terugdraaien is git revert. Je betaalt alleen voor modeltokens, wat past bij mensen die de kosten zelf willen beheersen.

Hoe voorkom je dat het code schrijft die je repo negeert?

Geef bewust context. Het meeste slechte resultaat gaat terug op het feit dat het model het relevante bestand nooit heeft gezien.

Drie gewoontes helpen. Ten eerste: voeg de twee of drie bestanden toe die het patroon definiëren, niet de hele map. Ten tweede: plak de falende test of de foutmelding letterlijk in plaats van die te beschrijven. Ten derde: houd een kort regelbestand in de repo (naamgeving, foutafhandeling, verboden bibliotheken) dat de tool bij elke run leest. De meeste agent-tools ondersteunen zoiets.

# AI-RULES.md
- Fouten: geef een Result terug, gooi nooit een exception in services/
- HTTP-calls gaan via lib/http.ts (heeft retry en tracing)
- Geen nieuwe dependencies zonder toelichting in de PR-beschrijving
- Tests: vitest, naast de code als *.test.ts

Vier regels als deze schrappen een opvallend deel van de reviewopmerkingen. Ze helpen mensen net zo goed.

In een repo die je nog niet kent, stel je eerst vragen voordat je om wijzigingen vraagt. "Waar wordt sessie-expiratie afgedwongen, en wat roept dat aan?" is een betere eerste prompt dan "voeg een refresh token toe". Je leest het antwoord, opent de twee bestanden die het noemt, en beslist dan pas wat je verandert. Dit is dezelfde lus van zoeken, blame en iemand vragen die je al gebruikt, alleen sneller.

Hoe review je AI-gegenereerde code, en wat geef je nooit uit handen?

Langzamer dan je de code van een collega reviewt. Een collega heeft een trackrecord in jouw codebase. Het model niet.

Mijn checklist, in volgorde:

• Draai het voordat je het leest. Een test die je zelf schreef en die slaagt, is meer waard dan een zelfverzekerde uitleg.

• Lees de imports. Verzonnen pakketten en onbekende helpers vallen daar als eerste op.

• Kijk naar wat ontbreekt. Foutpaden, null-afhandeling, opruimen. Modellen schrijven het happy path goed.

• Controleer de diffgrootte. Vroeg je om een fix van 10 regels en kreeg je er 120, dan is er iets herschreven wat je niet vroeg.

• Verwijder wat je niet kunt uitleggen. Als je een regel in review niet kunt verdedigen, gaat hij niet mee.

Houd de commit klein en het bericht eerlijk. "Retry toegevoegd aan webhook-sender (met AI geholpen, tests toegevoegd)" is prima. Verbergen helpt niemand en maakt later debuggen moeilijker.

Wat geef je nooit aan AI? Alles waar een fout stil en duur is. Auth-logica, betaalflows, datamigraties en permissiecontroles zijn plekken waar "bijna goed" de tests haalt en in productie faalt.

Je kunt AI daar nog steeds gebruiken, maar in een andere modus: vraag het om je code te reviewen en risico's op te sommen, in plaats van de code te laten schrijven. Een lijst met vijf mogelijke problemen lezen kost drie minuten. Een gegenereerde migratie lezen kost de middag die je besteedt aan twijfelen.

Als je nog leert, geldt er een tweede uitsluiting. Schrijf eerst zelf de eerste versie en vraag het model die daarna te bekritiseren. Een junior die altijd de gegenereerde versie accepteert, leert prompten in plaats van programmeren, en het gat komt aan het licht bij de eerste storing.

Hoe verandert dit voor een team?

Het verschil tussen individuen en teams zit in de reviewbelasting. Eén ontwikkelaar met agents kan per dag meer PR's openen dan de reviewers kunnen lezen. Spreek daarom vroeg drie dingen af:

1. Een maximale omvang. PR's met meer dan een paar honderd gewijzigde regels worden gesplitst, ongeacht wie of wat ze schreef.

2. Een afspraak over openheid. Meld wanneer een wijziging met AI is gemaakt, zodat reviewers hun aandacht aanpassen.

3. Een gedeeld regelbestand. Eén bron van waarheid voor conventies verslaat vijf persoonlijke prompts.

Voor onboarding is het beste gebruik dat ik heb gezien vraaggestuurd lezen. Nieuwe collega's vragen de assistent waar dingen staan en controleren het antwoord daarna in de code. Dat verkort de eerste week van "wie is hier eigenlijk eigenaar van?" zonder dat ze code krijgen die ze niet kunnen onderhouden.

Een eerste week plan dat je kunt overnemen

Dag 1: gebruik alleen inline completion, voor tests en boilerplate. Dag 2: stel drie codebasevragen per dag in de chat en controleer elk antwoord. Dag 3: laat de chat per taak één kleine wijziging voorstellen en lees elk blok. Dag 4: probeer een agent op een klus met laag risico, zoals het hernoemen van een configuratiesleutel in meerdere bestanden, op een branch. Dag 5: schrijf je regelbestand op basis van wat je in review irriteerde.

Volg één getal gedurende de week: minuten vanaf het starten van een ticket tot een gemergde PR, inclusief reviewfixes. Als dat getal niet is gedaald, heb je geleerd waar de tool niet bij je werk past, en dat is ook een resultaat.

Het snelste eerlijke voordeel dat ik zie, zit niet in generatie. Het zit in begrip: een onbekende module in tien minuten doorgronden in plaats van een uur. Code schrijven was nooit het trage deel van het werk. Lezen, beslissen en verifiëren wel. Richt de tool op die onderdelen, houd zelf de hand op de merge-knop, en de rest volgt vanzelf.