De specificatie-valkuil: waarom AI-codeers beter exacte eisen nodig hebben

De specificatie-valkuil: waarom AI-codeers beter exacte eisen nodig hebben

Mei 14, 2026 agentic development ai coding software specifications development workflow code generation technical requirements product engineering startup development

Het specificatieprobleem is vanouds al oud – AI legt het bloot

Een ongemakkelijke waarheid in de wereld van slimme AI-ontwikkeling: de echte rem zit niet in het schrijven van code. Die zit in het uitdenken wat je precies moet bouwen.

Fred Brooks zag dit al in 1986, in zijn klassieker No Silver Bullet. Hij stelde vast dat doorbraken zoals object-georiënteerd programmeren of time-sharing slechts kleine winsten opleverden. Ze pakten de accidental complexity aan – het gedoe van het coderen zelf – maar niet de essential complexity: het denkwerk erachter. Softwarebouw draait om specificaties: belangen afstemmen, keuzes maken en eisen vastleggen voor iets dat nog niet bestaat.

AI genereert nu moeiteloos code, en plots denkt iedereen dat specificaties vanzelf goed komen. Fout. Dat probleem blijft.

Waarom 'gedetailleerde beschrijvingen' niet hetzelfde zijn als 'precieze specs'

Veel nieuwe tools – van AI-PRD-makers tot slimme validators – gaan uit van een misvatting: als AI maar de juiste vragen stelt, vullen gaten zichzelf op.

Ze denken dat gewone taal de scherpte van formele systemen kan evenaren. Maar dat is achterstevoren.

Formele notaties bestaan juist omdat natuurlijke taal vaag is. Je schrijft een prachtige productbeschrijving – het leest als een verhaal, iedereen knikt – maar zonder technische diepgang faalt de AI. "De dashboard moet in twee seconden laden" klinkt oké, maar "P95-latency onder 2000 ms, met 99e percentiel max 5000 ms" is een echte spec.

Voer een vage spec in bij een AI-agent, en je krijgt rommel:

  1. Vaagheid leidt tot rare code. Technisch werkend, maar architecturaal een ramp. Drie sprints later ben je aan het herschrijven.

  2. AI vult stilzwijgend in. Het haalt patronen uit trainingsdata – duizenden vergelijkbare projecten – en bouwt aannames in die jij nooit bedoelde.

Geen van beide is succes.

Waar AI-coding wél en níet werkt

Wees eerlijk: agentic development blinkt uit in simpele gevallen. Landing pages, CRUD-apps, standaard integraties, e-commerce flows. Dit zijn voorspelbare problemen met bakkenvol voorbeelden in de data. De AI matcht patronen, lost niks nieuws op.

Dat levert echte waarde. Een solo-ondernemer boost zijn output met 10x. Een klein team bouwt tools in uren, niet weken. Pure productiviteit.

Maar let op: dit werkt door kristalheldere specs, niet ondanks. Het domein is zo bekend dat de spec bijna vanzelfsprekend is.

Voor al het andere – unieke businesslogica, nieuwe koppelingen, slimme architectuur – moet je nog steeds menselijk denkwerk doen. AI versnelt het tikken. Niet het bedenken. Het kan niet weigeren met "dit is dom, doe eerst X". Dat is productdenken, en dat blijft uniek menselijk.

De echte knel: wrijving tussen mensen

Als specificatie het lastige deel is en AI het niet oplost, wat dan wel?

Eén woord: minder gedoe in menselijke afstemming.

Als een productmanager een briefing doorschuift naar een developer, en die weeklang moet vergaderen over edge cases, heb je een spec-probleem. Als ontwerpschetsen botsen met backend-limieten, spec-probleem. Als AI code bouwt op foute aannames, spec-probleem.

De fix? Niet een slimmere AI, maar scherpte tussen mensen, vóór de AI draait. Zo:

  • Specs als kernartifact. Geen bijlage, maar het contract waar code op leunt.
  • Keuzes zwart-op-wit. Waarom eventual consistency boven strong? Welk datamodel en waarom?
  • Formele tools voor precisie. SQL-schemas, API-contracts, performance-eisen – geen discussie mogelijk.
  • Vroegtijdse AI-loops. Genereer een klein stukje code, spot ambiguïteit en pas de spec aan.

Zo pas je het toe in je workflow

Bouw je met AI in productie? Stop niet met agents. Investeer juist méér in specs.

Tegenintuïtief in een 'snelheid eerst'-wereld. Maar hardlopen met een vage spec betekent alleen sneller missen. Succesvolle teams denken eerst hard na, en zetten AI in voor uitvoering.

Voor startups en kleine teams: je voorsprong zit niet in code spugen. Die zit in heldere specs. Als je businesslogica zo scherp formuleert dat AI het klopt uitvoert, heb je het zwaarste gedaan. Code is dan bonus.

De kern

Brooks had in 1986 gelijk, en in 2025 nog steeds. Software-essentie zit in het concept, niet de bouw. AI maakt het verschil tussen vaag denken en scherpe code alleen maar duidelijker.

De volgende productiviteitssprong komt niet van betere agents. Van teams die specs keihard aanpakken, requirements engineering als core discipline zien, en AI inzetten om helderheid te boosten – niet te verdoezelen.

Dát is de kans waar AI en software samenkomen. En het vraagt één ding dat geen AI kan: diep nadenken over je build.


Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB HU IT FR ES DE DA ZH-HANS EN