Waarom je code-assistent teleurstelt (en hoe je dat oplost)

Laten we eerlijk zijn. Je hebt vast wel eens een code-assistent geprobeerd. Je keek toe terwijl het een functie schreef en dacht: "Best cool." Maar toen je het echt nodig had—voor iets dat ertoe deed—liep het vast.

Misschien begon die AI maar wat te verzinnen. Misschien loste het ene probleem op en creëerde het er drie nieuwe. Of misschien bleef het gewoon draaien, wachtend tot jij uitlegde wat je eigenlijk bedoelde. Herkenbaar?

Hier is de ongemakkelijke waarheid: de tool is niet stuk. Jij gebruikt hem verkeerd.

Meer specifiek: je trekt aan één hendel terwijl er drie beschikbaar zijn.

De drie hendels die niemand noemt

Elke code-assistent—of je nu werkt met Claude Code, Cursor, Copilot of iets anders—werkt volgens hetzelfde principe. Hij krijgt informatie binnen, doet iets daarmee, en krijgt terugkoppeling. Meer is het niet. Dat is het hele systeem.

Maar hier gaat het mis: de meeste mensen optimaliseren één of twee van deze hendels en negeren de derde. En in echte productie-omgevingen wordt die ontbrekende hendel jouw plafond.

Laat me uitleggen wat ik bedoel.

ZIEN: Wat weet je agent eigenlijk?

Standaard ziet je agent alleen je code en je terminal. Dat is alles. Het heeft geen idee van de编码standaarden van je team. Het weet niet van die vreemde workaround die je senior engineer drie jaar geleden toevoegde voor een oude integratie. Het weet niet wat "klaar" betekent voor jouw specifieke project.

Als ik praat met teams die worstelen met AI-ondersteunde ontwikkeling, is het probleem bijna altijd context. De agent vliegt blind. Hij schrijft code die technisch werkt maar niet past bij de patronen in je codebase, negeert je naamgevingsovereenkomsten, of lost problemen op die je team allang had opgelost.

De oplossing? Verpak je context alsof je werk overdraagt aan een nieuwe junior developer. Welke bestanden moet hij eerst lezen? Welke conventies zijn belangrijk? Hoe ziet je architectuur eruit? De meeste tools hebben manieren om dit te injecteren—system prompts, documentatie-referenties, skill-bestanden. Gebruik ze.

DOEN: Wat kan je agent eigenlijk?

Hier wordt het interessant. Een basisagent kan bestanden bewerken en tests draaien. Een goed ingestelde agent kan API's bevragen, CI-status controleren, Slack-gesprekken lezen, of communiceren met je cloud-infrastructuur.

Hoe meer acties je agent kan uitvoeren, hoe minder jij handmatig hoeft te overbruggen. Wil je dat je agent checkt of een deployment echt gelukt is voordat een ticket wordt gesloten? Dan moet hij je cloud-console kunnen bereiken. Wil je dat hij overlegt met teamleden? Dan heeft hij toegang nodig tot je communicatiekanalen.

Het gaat hier niet om het bouwen van een sciencefiction AI-Overlord. Het gaat om het wegnemen van handmatig schakelen tussen tools. Elke alt-tab is een overdracht waarbij context verloren gaat. Hoe meer je agent autonoom kan doen binnen je workflow, hoe strakker die lus wordt.

CORRIGEREN: Hoe weet je agent dat het misging?

Dit is de hendel die de meeste teams compleet negeren, en het is de reden dat hun agents onbetrouwbaar aanvoelen.

Je agent heeft terugkoppeling nodig. Niet alleen "deze code werkt niet" maar genuanceerde signalen over kwaliteit, stijl en intentie. Linters vangen syntaxfouten. Tests vangen functionele fouten. Code review vangt architectuurproblemen. Maar je agent kan niet handelen op feedback die het nooit ontvangt.

Denk er zo over: elke automatische correctie die je agent tegenkomt is een leermoment. Elke genegeerde fout is een gemiste kans. Hoe strakker je feedback-lussen, hoe sneller je agent verbetert.

Hierin schieten veel teams tekort. Ze draaien tests handmatig, checken lints af en toe, en reviewen code wanneer ze eraan denken. Maar voor betrouwbare AI-ondersteuning moeten deze checks automatisch en snel zijn. CI pipelines die 45 minuten duren zijn de dood voor agent-productiviteit. Instant feedback? Daar gebeurt de magie.

Het zwakste-schakel-principe

Hier is het mentale model dat mijn kijk op dit onderwerp veranderd heeft:

Stel je drie balken voor. Eentje voor Zien, eentje voor Doen, eentje voor Corrigeren. De totale capaciteit van je agent wordt begrensd door de kortste balk.

Ik heb teams gezien die resources staken in het beter laten schrijven van code door hun agents (Doen), maar die nooit de juiste context gaven (Zien), waardoor dezelfde fouten bleven terugkomen. Ik heb teams gezien die uitgebreide feedbacksysteem bouwden (Corrigeren), maar waar de agent de informatie ontbrak om die feedback toe te passen (Zien). In elk geval was de bottleneck de hendel waar niemand aan dacht te trekken.

Dit is niet zomaar intuïtie. Het is een structurele beperking van elk systeem dat een omgeving waarneemt, erop reageert, en zich aanpast. Denk aan reinforcement learning-systemen—die hebben observatie (ZIEN), action space (DOEN), en beloningssignalen (CORRIGEREN) nodig. Haal er één uit, en het systeem degradeert. Jouw code-agent is hetzelfde.

Wat dit betekent voor je team

Als je code-agents evalueert voor productiewerk, test ze dan niet alleen met speelgoedproblemen. Laat ze scenarios doorlopen die alle drie de hendels belasten:

• Kan de agent de context bereiken die hij nodig heeft om je codebase te begrijpen?
• Kan de agent acties uitvoeren die passen in je daadwerkelijke workflow?
• Krijgt de agent snel genoeg feedback om bij te sturen?

Als het antwoord op een van deze vragen "niet echt" is, dan is daar je investering nodig.

Voor engineering leads en architecten: dit gaat niet over het vinden van het juiste gereedschap. Het gaat over het bouwen van het juiste systeem. De tool is de motor. De hendels zijn de transmissie, het brandstofsysteem, het koelsysteem. Een Ferrari met een ontbrekend wiel is geen supercar—het is een kapotte auto.

De grotere foto

We zijn nog vroeg in het tijdperk van AI-ondersteunde ontwikkeling. Teams ontdekken dat een code-agent ergens op gooien niet genoeg is. De teams die er het meeste uithalen zijn niet degenen met de slimste modellen—het zijn degenen die de strakste lussen bouwen tussen zien, doen en corrigeren.

Dus voordat je de tool de schuld geeft voor teleurstellende resultaten, kijk eerlijk naar je hendels. Welke is de kortste? Daar ligt je kans.