Waarom Out-of-the-Box AI Ontwikkelaars Frustreren — en Wat Je Eraan Kan Doen

Met de meeste technologieën word je er naarmate je ze langer gebruikt rustiger van en ga je er meer op vertrouwen. Bij AI-tools is het tegenovergestelde waar: in hun jaarlijkse enquête van meer dan 49.000 ontwikkelaars, noteerde Stack Overflow een gebruik dat steeg tot 84%, terwijl het vertrouwen in de nauwkeurigheid van deze tools daalde van 40% tot 29% in de loop van één jaar.

Dat effect is mij bekend. Onze eerste ervaring met AI-tools in de ontwikkeling had weinig te maken met het wow-effect van sneller werk en minder saaiheid dat de technische pers bleef schrijven. Onze ontwikkelaars werden teleurgesteld: de AI produceerde matige code die lang duurde om te controleren en uiteindelijk opnieuw geschreven moest worden. Het team verwachtte dat AI tijd zou besparen en kreeg in plaats daarvan extra werk. Dus niet lang na die eerste pogingen om AI-tools in de dagelijkse workflow in te voegen, ging het team terug naar de manier waarop het altijd had gewerkt.

Vandaag versnellen diezelfde tools zowel het schrijven van code als het controleren ervan voor onze ontwikkelaars — niet omdat we een beter model vonden, maar omdat we de manier waarop we ermee werken veranderden. Hieronder volgt wat ons hielp om daar te komen.

Waarom AI-gegenereerde Code Ontwikkelaars Frustreren

AI steunt op een enorme hoeveelheid openbare code van over het hele internet, en die code is zelden voorbeeldig: de kwaliteit is gemiddeld, en het model reproduceert die gemiddelde.

Maar “gemiddeld” is niet het plafond van wat mogelijk is — het is gewoon wat het model produceert totdat het uw project kent: de conventies, de codestructuur, de architectonische beslissingen. In een enquête onder 600-plus ontwikkelaars, vond Qodo uit dat onder degenen die ontevreden waren over de kwaliteit van de AI-code, 44% dit toeschreven aan een gebrek aan context. Dat is wat de output op een matig niveau houdt.

Het goede nieuws is dat de context die de AI ontvangt de enige variabele is die een team volledig controleert. Hoe goed het instrument het project begrijpt, hangt niet af van het model, maar van wat je het voedt.

De tweede reden is mentaal — de aard van het werk verandert. Wanneer AI de meeste code schrijft, is de belangrijkste actie van de ontwikkelaar niet langer het schrijven, maar het controleren van wat is gegenereerd: het lezen van iemands anders oplossing, het wegen van de alternatieven, het beslissen wat klaar is om te verzenden. Dat is een andere vaardigheid dan zelf code schrijven, en voor iedereen die van het schrijven hield, komt het niet gemakkelijk.

In het Octoverse-rapport van 2025 van GitHub wordt exact deze verschuiving beschreven: de ontwikkelaars die het verst zijn gegaan met AI noemen zichzelf niet langer “auteurs van code” en worden iets dichter bij de “creatieve directeuren” ervan, waar de belangrijkste vaardigheid is om te sturen en te verifiëren. Maar de weg naar die rol loopt door fouten en frustratie, totdat iemand de opbrengst in zijn eigen werk ziet.

Wat AI Verandert van een Bron van Frustratie in een Werkend Instrument

Toen ons team voor het eerst AI begon te gebruiken, werkten sommige ontwikkelaars met Claude Code, anderen probeerden OpenAI Codex, GitHub Copilot of Gemini CLI, en elk instrument gaf een ander resultaat. Dus toen we orde wilden scheppen in de manier waarop het team met AI werkte, was de eerste stap dat we ons op één instrument richtten.

Dit is niet alleen onze praktijk. Neem het verhaal van het team bij Linear: tot begin 2026 werkten ze op basis van een “laat iedereen werken zoals het hem het beste uitkomt”-principe, en in januari liet het management die aanpak varen en ging iedereen over op één manier van werken — de keuze beperken tot twee AI-instrumenten en ontwikkelaars vragen om code alleen met die instrumenten te schrijven, in plaats van met de hand. Volgens het bedrijf steeg de gemiddelde productiviteit de volgende maand met 30% in samengevoegde PR’s en met 33% in taken die per ingenieur werden afgerond.

Dat gezegd hebbende, verbetert een gedeeld instrument op zich de code niet — het moet worden geconfigureerd: regels instellen, zoals een rules.md, die uitleggen hoe code moet worden geschreven — welke benaderingen te volgen, wat te vermijden. Vervolgens komen aangepaste vaardigheden voor de taken die typisch zijn voor uw project, zodat u niet steeds hetzelfde moet uitleggen. En ten slotte is het de moeite waard om de agent naar uw bestaande codebase te wijzen: het analyseert hoe het project is geschreven en produceert nieuwe code in dezelfde stijl, in plaats van in een generieke stijl. Hoe meer context het instrument ontvangt, hoe minder u handmatig hoeft te herschrijven.

Maar het moeilijkste deel is niet technisch. De overgang van auteur van de code naar evaluator gebeurt niet vanzelf — die overgang heeft hulp nodig. De meest directe route is training en certificering. In ons geval gaan tien ontwikkelaars bijvoorbeeld een partnerprogramma van de instrumentenleverancier door, terwijl naast hen iemand werkt die verantwoordelijk is voor de adoptie, die uitlegt waarom het instrument een bepaald resultaat produceerde en hoe het kan worden verbeterd.

Zodra het team op een gecoördineerde manier werkt, blijft één bottleneck over — controle — en het is de moeite waard om die met AI te versterken. De agent gaat door elke pull-aanvraag heen en neemt de voor de hand liggende dingen voor zijn rekening: routinefouten, stijl, herhaling, beveiligingslekken. De menselijke reviewer kijkt dan niet langer naar alles zonder onderscheid, maar alleen naar de architectuur en de kritieke beslissingen. Het effect is merkbaar, zelfs binnen de bedrijven die deze instrumenten bouwen: bij Anthropic steeg het aandeel pull-aanvragen dat een inhoudelijke controle ontving van 16% naar 54%, en ingenieurs waren het met minder dan 1% van de opmerkingen van de agent oneens.

Voor ons verkortte dit een controlecyclus die eerder twee of drie dagen over meerdere ronden duurde, en het tilde de routine van onze senior-ingenieurs, waardoor ze alleen de echt moeilijke punten overhielden. Zodra het instrument eindelijk resultaten produceerde die niet opnieuw hoeven te worden geschreven, verscheen het vertrouwen erin ook.

Waar Vertrouwen in AI-Instrumenten Zich Uitbetaalt

Allereerst — bij het schrijven van code: wanneer het instrument het project kent en de agent de eerste controle doet, schrijft het team meer en beter in dezelfde tijd. In ons geval versnelden AI-instrumenten het werk met ongeveer 30-40%.

Verder heeft AI de inwerktijd vereenvoudigd. Wanneer iemand nieuw bij een project komt, moet iemand met ervaring meestal tientallen vragen over de code van het project beantwoorden. Nu neemt de agent die rol op zich: als het project goed is gedocumenteerd, richt de nieuwkomer tot 95% van die vragen tot de agent in plaats van tot collega’s.

Hetzelfde verhaal gaat op voor documentatie: een ruwe architectonische schets die eerder uren in beslag nam, wordt nu voor het grootste deel door de agent zelf geschreven — naar onze schatting ongeveer 80% van de schets, als je hem voldoende context geeft. Wat overblijft voor de mens is wat niet in het repository zit — de beslissingen, de compromissen, de expertise.

Net zo belangrijk is het om eerlijk te zijn over de beperkingen van wat AI kan doen, omdat het zijn de opgeblazen verwachtingen die teleurstelling in de eerste plaats veroorzaken. AI neemt geen compliance voor zijn rekening — een mens ondertekent medische of financiële gegevens, en het bedrijf, niet het model, is verantwoordelijk voor een lek. Het versnelt geen integraties met partners, waarbij tientallen uren in gesprekken en coördinatie gaan zitten.

Out-of-the-box AI is echt irritant — maar alleen wanneer het als een afgerond oplossing wordt gebruikt. Het hele verschil tussen frustratie en opbrengst ligt in wat je eromheen bouwt: een gedeelde standaard, de context van uw project, en de nieuwe rol van de ontwikkelaar.