Wanneer AI-codeerhulpen vastlopen: zo stuur je ze beter aan

Je kent het moment. Je AI-assistent werkt eerst nog prima aan kleine fixes en uitbreidingen. Maar zodra je vraagt om een grote refactor, verandert alles. De antwoorden worden vaag, het verbruik van tokens loopt hard op en de voortgang stopt bijna.

De oorzaak ligt meestal niet bij de tool zelf. Je stelt gewoon de verkeerde vraag.

Van kleine stappen naar grote sprongen

AI-codeerhulpen zoals Claude en GPT-4 zijn getraind op precieze, gerichte aanpassingen. Ze houden zich aan de bestaande stijl en respecteren de huidige tests. Dat werkt uitstekend zolang je kleine, incrementele wijzigingen vraagt.

Maar zodra je overstapt op structurele veranderingen, bots je tegen de beperkingen van diezelfde training. De agent probeert alles te behouden wat al bestaat. Dat is precies wat je niet wilt als je een architectuur opnieuw wilt opbouwen.

Dit noemen we vaak test hell: de tests die ooit bescherming boden, worden nu een blokkade.

De vicieuze cirkel van tokens

In de praktijk ziet het er vaak zo uit:

1. Je vraagt om een refactor van een module.
2. De agent probeert de bestaande tests intact te houden.
3. De nieuwe structuur past niet bij de oude tests.
4. De agent maakt minimale wijzigingen.
5. Je vraagt opnieuw, met meer nadruk.
6. Het tokenverbruik verdubbelt en daarna verdubbelt het opnieuw.
7. De antwoorden worden steeds onduidelijker.

De AI raakt niet in de war. Het systeem raakt verstrikt in tegenstrijdige opdrachten.

Waarom dit gebeurt

AI-codeerhulpen zijn getraind op het type wijzigingen dat je tegenkomt in echte pull requests: kleine, safe edits tegen een stabiele achtergrond. Dat is ook precies wat productiecode nodig heeft.

Maar als je midden in een architecturale transitie zit, heb je die training juist nodig om los te laten. De tijdelijke tests die je eerder schreef, zijn geen vaste contracten meer. Ze moeten meeveranderen.

Hoe je beter vraagt

De oplossing ligt niet alleen in betere prompts, maar vooral in duidelijke afbakening.

• Maak expliciet wat mag veranderen.
  Zeg niet alleen: “Refactor deze module en houd de tests groen.”
  Zeg liever: “We doen een architecturale refactor. Deze tests mogen verdwijnen. Dit is het nieuwe gedrag dat de module moet vertonen.”

• Scheid verkenning van uitvoering.
  Gebruik de agent voor korte prototypes in aparte branches. Bepaal daarna pas de definitieve structuur. Vraag nooit om tegelijkertijd oude tests te behouden en een nieuwe architectuur te bedenken.

• Pas je teststrategie aan.
  Geef de agent expliciete toestemming om tests mee te refactoren als de architectuur verandert. Tests beschermen bestaande code, maar mogen geen obstakel vormen als je iets nieuws bouwt.

• Werk met een ontwerpdocument.
  Schrijf eerst op wat er moet veranderen en waarom. Geef de agent context over de reden achter de nieuwe structuur,而不只是 de huidige code en tests.

En wat betekent dit voor vibe coding?

Vibe coding werkt het best wanneer je de AI vraagt om een duidelijk gedefinieerde taak uit te voeren. Je bent niet op zoek naar een zelfstandige engineer,而是 naar een systeem dat efficiënt werkt onder duidelijke voorwaarden.

De magie komt terug wanneer je je vragen aanpast aan de beperkingen van de tool — of die beperkingen expliciet loslaat met een duidelijke opdracht.

Conclusie

Je AI-codeerhulp is niet defect. Het systeem doet precies wat het is getraind om te doen: precieze, veilige, incrementele wijzigingen. Wanneer je iets anders nodig hebt, moet je dat ook anders vragen.

Kijk dus altijd kritisch naar je vraagstelling. Is je verzoek een kleine update tegen een stabiele achtergrond, of vraag je om een evolutie terwijl je doet alsof de basis al vastligt?

Dat onderscheid maakt meestal het verschil tussen frustratie en voortgang.