Vier dagen bezig met iets dat normaal twee uur kost. Met AI.

Ik dacht dat ik vloog. Tot ik het zag: één draft-PR met 32 reviewrondes. En het stopte niet.

Ik werkte ondertussen in drie tot vijf worktrees tegelijk en gaf de AI steeds meer verantwoordelijkheid. Het duurde even voor ik doorhad dat deze ene volledig was ontspoord.

Een ontwikkelaar met het hoofd in de hand naast een pull request met tientallen reviewrondes
32 reviewrondes op één PR. Ik bleef symptomen fixen, terwijl de echte fout in de specs zat.

De "perfecte" setup

Op papier klopte alles:

  • 98% van de code AI-gegenereerd
  • strakke context-files
  • AI-review op elke commit

Wat ik toen niet doorhad: de AI deed precies wat ik vroeg. Alleen vulde hij mijn ontbrekende specs op met aannames.

Een voorbeeld uit die PR. Ik vroeg om een simpel dashboard dat de antwoorden van een vragenlijst samenvat voor meerdere deelnemers. In mijn hoofd: één eenvoudige webpagina. De AI nam aan dat uitbreidbaarheid belangrijk was en had er een complete plugin-structuur omheen bedacht. Drie reviewrondes later zat ik nog steeds de gevolgen van die ene aanname op te ruimen.

Zelfde verhaal bij de vraag wanneer een score "goed" is. Of wat je doet bij een hoge spreiding. Het zat allemaal in mijn hoofd. Het stond alleen niet in de specs. Dus de AI moest gokken.

Hoe werkte ik?

Ik begon met vage requirements. "Ongeveer dit, snel coderen, ik stuur wel bij." De AI-coder vulde de vaagheid op met aannames. De UI werkte prima.

De reviewers, GitHub Copilot en Claude Code, vonden symptomen. De aannames eronder zagen ze niet. Dus liet ik symptomen fixen. Nieuwe aannames, nieuwe symptomen. Pas toen ik zelf de code in dook, zag ik het: ontwerpfouten en onnodige complexiteit.

Waarom ging het mis?

De context was prima. De specs waren te algemeen. En de review keek vooral naar code, nauwelijks naar de aannames erachter.

Het verschil dat ik onderschatte:

Context = de kaders. Je codebase, je conventies, je guardrails.

Specs = het gedrag. Wat moet de feature precies doen?

Bij kleine changes is dat geen ramp. Bij grotere features mist er een systeem.

Wat ik nu anders doe

  1. Eerst de specs uitwerken en reviewen.
  2. Dan het implementatieplan reviewen, inclusief datamodel en architectuur.
  3. Pas dan code laten genereren, in logische chunks.
  4. Elke chunk committen en reviewen.

De review verschuift naar voren. Hoe eerder je een verkeerde aanname vangt, hoe goedkoper de fix.

Vuistregel: review begint al bij de spec, niet pas bij de PR.

En zie je drie of meer reviewrondes op code? Stop. Ga terug naar de specs en het plan. AI vult ontbrekende specs op met aannames. Op dat moment debug je geen code meer. Je debugt specs.

Tools of gewoonte?

De tooling die me nu helpt (Spec-kit, promptcards, de Claude-plugin Superpowers) is uiteindelijk minder belangrijk dan de gewoonte erachter: niet beginnen met genereren voordat het ontwerp scherp is.

AI versnelt de implementatie, en vergroot tegelijk de blinde vlekken in je ontwerp. Dezelfde dynamiek beschrijf ik als verification debt: je genereert sneller dan je kunt verifiëren. Mijn workflow staat inmiddels volledig op spec-driven development.

Hoe voorkom jij dat AI-snelheid omslaat in verification debt? En heb je al een werkwijze die de hoeveelheid output van AI aankan?