Schrijven ligt dichter bij denken dan code

Ik voer al een tijdje een soort debat met Matt Pocock over de beste manier om spec-driven development (ontwikkeling op basis van specificaties) aan te pakken.

Matt is een briljante, traditionele ontwikkelaar: een echte software engineer. Hij gebruikt AI om zijn capaciteiten tot een buitengewone mate te vergroten. Zijn ontwikkelingsvaardigheden zijn spectaculair; zijn skills-repo op GitHub is een van de meest 'gestarrede' repositories die er bestaan.

Waar gaat mijn meningsverschil over? Natuurlijk moeten we soms nog steeds betrokken zijn in het proces (human in the loop), maar absoluut niet in de mate die hij aanbeveelt.

In essentie denk ik dat hij het toppunt heeft bereikt van de 'oude manier' van werken. Hij beschikt over een enorme hoeveelheid vaardigheden en commando's die hij mensen aanmoedigt om handmatig uit te voeren. Het idee van een mens in de loop is een centraal thema voor hem, maar ik geloof dat dit inmiddels een anti-pattern is.

Zijn centrale idee vanouds is dat in een ontwikkelingsproject de code zelf het belangrijkste is. Specificaties zijn nuttig, maar de code is het belangrijkste artefact en de source of truth voor alles. Je kunt met zijn methode nog steeds absoluut uitmuntende projecten opleveren, om duidelijk te zijn.

Ik ben het hier echter sterk mee oneens. Ik denk dat de articulatie van wat je bouwt, en waarom, veel belangrijker is. In feite gaat het om het idee: je intentie.

Ik geloof dat het belangrijkste aspect van elk project dat je met AI bouwt (en zelfs zonder AI) — of het nu gaat om het bouwen van een webapplicatie, het starten van een bedrijf of het beheren van een federatie van planeten — is hoe volledig en nauwkeurig je precies articuleert wat je wilt.

Om duidelijk te zijn: ik zeg niet dat je een perfecte, gekristalliseerde articulatie nodig hebt voordat je begint. Niemand heeft dat. We zijn menselijk, en wat we willen wordt duidelijker terwijl we bouwen. Mijn argument gaat over waar die iteratie plaatsvindt: binnen de articulatie van de ideale staat, niet in cirkels rondom de code.

Er zijn twee loops, niet één:

  1. Je intentie en het geschreven woord gaan heen en weer terwijl je ontdekt wat je daadwerkelijk wilt.
  2. Het geschreven woord en de implementatie gaan heen en weer terwijl je bouwt.

Het echte probleem is articulatie

Ik denk dat de meeste problemen die we in 2026 met AI zien, verkeerd worden toegeschreven. AI is buitengewoon goed in uitvoering. Het wordt ongelooflijk goed in het doen van wat we vragen. Steeds vaker is het probleem dat de AI de taak perfect uitvoert, maar dat het resultaat verschilt van wat we in ons hoofd hadden.

Dit is een communicatieprobleem. Het is een articulatieprobleem. Wanneer een AI het verkeerde bouwt, controleer dan eerst wat je hebt gezegd voordat je het model de schuld geeft.

Auteurs hebben hetzelfde probleem. Dit wordt vaak Writer’s Blindness genoemd. Je denkt dat je perfect vastlegt wat er in je hoofd zit, maar dat is niet zo. De ontvanger of lezer mist daardoor informatie of krijgt een compleet andere interpretatie dan de auteur bedoelde. Writer’s blindness wordt ook wel de curse of knowledge genoemd: zodra je iets weet, is het moeilijk om je voor te stellen hoe het is om het te lezen zonder die kennis.

Code is een representatie, niet de bron

Het probleem met de positie van Matt is dat hij denkt dat code gezaghebbend is. In werkelijkheid is code een abstractie, op dezelfde manier als een schilderij een abstractie is van wat de schilder wilde overbrengen. Het is een uitvoering. Een facsimile. Een representatie.

Maar er is een hogere vorm hiervan, en dat is schrijven (en beelden). Schrijven is hetgeen dat het dichtst bij het menselijk denken komt. Voor mij is schrijven denken.

Nauwkeurigheid verslaat precisie

Ik begrijp waarom Matt zo gefascineerd is door code. Code bezit iets wat zelfs schrijven niet heeft: precisie. Schrijven heeft echter meer nauwkeurigheid (accuracy). Het is dus een afweging tussen nauwkeurigheid en precisie.

We willen natuurlijk beide, maar bij het bouwen van zaken met AI denk ik dat nauwkeurigheid veel belangrijker is. De klassieke illustratie hiervan is een boogschutter die op een roos richt:

  • Nauwkeurigheid zonder precisie: Een reeks pijlen die allemaal vlak rond de roos landen, maar elke pijl op een andere plek.
  • Precisie zonder nauwkeurigheid: Elke pijl landt in een zeer compacte groep, maar die groep bevindt zich aan de rand van het doel, ver van waar je eigenlijk op probeerde te schieten.

Wanneer we met AI bouwen, willen we dat het resultaat overeenkomt met wat er in ons hoofd zat. Dat is nauwkeurigheid. En er is geen betere manier om de 'roos' van onze menselijke gedachten te vangen dan door te schrijven.

Het Ideal State Artifact (ISA)

Wat betekent dit in de praktijk? Het betekent dat het articuleren van wat je wilt, in schriftelijke vorm, het belangrijkste is dat je kunt doen voor elk AI-project. En ik bedoel hier niet alleen in een rigide specificatie-formaat of een PRD-formaat, maar op veel holistischere en creatievere manieren.

Aan het eind van 2025 stapte ik over op iets wat ik een Ideal State Artifact (ISA) noem. Dit is een nieuw document en een nieuwe benadering voor interactie met AI. Het is een veel diepere vastlegging van wat we proberen te bouwen en maakt gebruik van meerdere secties voor verschillende soorten articulatie:

  • De gearticuleerde Ideale Staat: Dit is proza. Dit kunnen een paar paragrafen zijn, of 4.000 woorden aan stream of consciousness en diepe introspectie over een onderwerp.
  • Constraints (Beperkingen): Zaken die we niet willen bouwen, enzovoort.
  • Decisions (Besluiten): Beslissingen die zijn genomen terwijl we de ideale staat van het project bijwerkten. Omdat het bouwen je vaak iets leert of omdat het herlezen van de ISA je mening verandert, schrijf je dit terug in de ISA met datum en reden. Zo vindt de iteratie plaats in de articulatie in plaats van dat deze verloren gaat in de code.
  • Ideal State Criteria (ISCs): Dit is de belangrijkste sectie na de definitie van de ideale staat. Dit zijn zaken die we daadwerkelijk bouwen en testen in de applicatie. Het zijn extreem atomaire en testbare stukjes functionaliteit. Elk criterium heeft een bijbehorende evaluatie (eval), variërend van een eenvoudige assert tot complexe multi-fase evaluaties met een LLM als jury.

Het krachtige aan deze aanpak is dat de ISCs tegelijkertijd de basis zijn waar we vanuit bouwen én het testkader vormen.

De uil tekenen

Hier zijn drie voorbeelden van wat ik bedoel. In elk voorbeeld is de fout hetzelfde: de middelste stap (de articulatie) wordt overgeslagen en de implementatie wordt als de waarheid behandeld.

De uil

Stel dat je een perfect plaatje van een uil wilt tekenen. Je hebt een prachtig beeld in je hoofd, maar je kunt niet goed tekenen. In deze analogie is de tekening de code. Wat eruit komt is een stokfiguurtje dat nauwelijks als uil herkenbaar is.

In de versie waar "code de bron van waarheid is", is dat stokfiguurtje nu het gezaghebbende artefact. We analyseren het, documenteren het en besteden veel tijd aan het itereren op basis van deze tekening. We draaien in cirkels rond een slechte tekening.

Wat we oversloegen was de zuivere vertaling van het brein naar een vastgelegde staat via schrijven. Die schriftelijke beschrijving is hetgeen de tekening probeert te implementeren. Met een ISA wordt elke nieuwe tekening getoetst aan de beschrijving in plaats van aan de vorige tekening. Als een schets je doet beseffen dat je de uil eigenlijk in vlucht wilt, dan wordt dat als een Decision in de ISA gezet.

De webapplicatie

Een vriendin runt een kleine yogastudio en wil dat vaste klanten lessen kunnen boeken zonder haar te sms'en. Iemand geeft een AI een prompt van één regel, en de AI bouwt een boekingsapp met een login-muur, een kalendergrid dat onleesbaar is op een telefoon, bevestigingsmails waar niemand om vroeg, en een klassecapaciteit van 20 voor een kamer waar er maar 12 in passen.

Als de code de bron van waarheid is, is die app nu de specificatie. Er worden tests geschreven voor het kalendergrid, de login-flow wordt gedocumenteerd en het e-mailsysteem wordt gerefactord. Elk toeval in versie één wordt een vereiste omdat het in de code staat.

Met een ISA faalt de login-muur op het eerste criterium (ISC-1) en de verkeerde capaciteit op het tweede (ISC-2). De code wordt vervangbaar. Als versie één slecht genoeg is, gooi je hem weg en bouw je opnieuw tegen dezelfde ISA.

De keuken

Dit werkt ook buiten software. Stel dat je je keuken verbouwt. Het idee is: zondagochtenden met z'n tweeën koken, vrienden op krukjes aan het aanrecht, iedereen in één gesprek. Je geeft de aannemer een ruwe schets, en zij bouwen de keuken met het fornuis tegen de muur, waardoor degene die kookt met de rug naar iedereen staat.

De implementation-first versie is om de volgende drie maanden te besteden aan het aanpassen van wat er is gebouwd. Je verschuift een kastje, wisselt de afzuigkap, en discussieert over kastjes in plaats van over zondagochtenden.

Met een schriftelijke ISA faalt het plan "fornuis tegen de muur" op papier, nog voordat er één plank wordt gezaagd. De aannemer was niet het probleem; zij zijn uitstekende uitvoerders, net als AI. Wat ontbrak was een schriftelijk doel om naar te streven.

Conclusie: Waarom dit belangrijker wordt naarmate AI slimmer wordt

Terugkomend op Matt: broncode in een computertaal zoals TypeScript of Python is bij lange na geen zo getrouwe representatie van het oorspronkelijke idee als een Ideal State Artifact.

Wat we moeten leren van Richard Sutton’s Bitter Lesson is dat naarmate AI slimmer wordt, het in staat zal zijn om precies te doen wat we willen op een manier die ons zal delighten. De kern van Suttons punt is dat algemene methoden die leunen op meer rekenkracht, steevast winnen van methoden die gebaseerd zijn op menselijke slimheid over het specifieke probleem.

Te veel focussen op legacy spec-driven development en de exacte vorm die code op een bepaald moment aanneemt, is inspanning op de verkeerde plek zetten. Hoe slimmer de AI wordt, hoe meer we onze inspanningen moeten verplaatsen naar het garanderen dat de AI precies weet wat we willen, en hoe minder we moeten micromanagen hoe dat precies gebeurt.

***

Notities

  1. Geformuleerd door Matt in zijn post van 22 oktober 2026: "The code, not the spec, should be the center of your universe." In een reactie voegde hij toe: "Code is executable, spec is not."
  2. De skills-repo van Matt had op 23 oktober 2026 meer dan 301.000 GitHub-stars.
  3. In een andere wereld is spec-driven development precies wat ik bepleit met de ISA. Als je de ISA "de spec" zou noemen, zouden we spec-driven development doen. Maar traditionele spec-driven development produceerde documenten die heel anders waren dan een ISA: lijsten met vereisten en templates die één keer aan het begin werden geschreven, gescheiden bleven van de tests, en zelden werden bijgewerkt tijdens het bouwproces. Deze legacy-versie is wat ik hier bedoel.
  4. Spec-driven development, test-driven development en alles wat Matt doet is fantastisch. We staan op de schouders van de mensen die deze praktijken de afgelopen decennia hebben opgebouwd. Mijn argument is niet dat dit fouten waren, maar dat de ISA de beste weg vooruit is vanaf dit punt.