De specificatie is het product
Als AI de code schrijft, verschuift het echte werk naar wat je vooraf vastlegt. Uit een platform dat we volledig spec-driven bouwen.
We bouwen op dit moment een cloudplatform waarvan tot nu toe geen enkele regel code met de hand is geschreven. Dat doen we omdat het zo sneller en beter gaat, niet om er een punt mee te maken. Wat wij schrijven zijn specificaties en standaarden. De code komt daaruit voort en wordt getoetst voordat hij mag blijven.
Voor wie software laat bouwen klinkt dat gek. Je betaalt toch voor code? Dit artikel legt uit waarom dat de verkeerde vraag is geworden, en wat ervoor in de plaats komt. Het begint eenvoudig en wordt daarna technisch, omdat de tweede helft bedoeld is voor wie het zelf wil inrichten.
Code is niet meer het schaarse deel
Jarenlang was code het dure onderdeel. Iemand moest het typen, en die iemand was duur en langzaam. De rest was ondergeschikt aan die ene flessenhals: bedenken wat je wilt, opschrijven hoe het moet werken, controleren of het klopt.
Die flessenhals is weg. Een AI-agent schrijft in een middag wat vroeger een week kostte. Daarmee verandert de vraag die ertoe doet. Die luidt niet langer wie het typt, maar hoe je zeker weet dat wat eruit komt ook is wat je bedoelde. Een agent doet namelijk precies wat je vraagt, inclusief de dingen die je impliciet liet. Wat niet vastligt, vult hij in met wat aannemelijk lijkt, en aannemelijk is iets anders dan juist.
Daarom is bij ons verschoven wat we opleveren. Werkende software leveren we nog steeds, daar merkt de klant geen verschil aan. Maar het artefact dat wij onderhouden, waar onze tijd in gaat en waar de kwaliteit vandaan komt, is niet langer de code. Dat is de specificatie geworden.
Wat een specificatie bij ons is
Een specificatie is bij ons een afgebakend document dat één ding beschrijft: welk probleem we oplossen, voor wie, en waaraan je afleest dat het klopt. Het is dus geen ticket en geen losse wensenlijst.
Dat laatste stuk weegt het zwaarst. Elke eis schrijven we op als een concreet geval. Gegeven deze situatie, wanneer dit gebeurt, dan hoort dat het gevolg te zijn. Dus niet “de invoer moet gevalideerd worden”, maar iets toetsbaars: gegeven een bestand met meerdere fouten, wanneer het gecontroleerd wordt, dan worden alle fouten in één keer gemeld. Meldt hij alleen de eerste, dan heeft een agent net zoveel pogingen nodig als hij fouten maakt.
Elk van die gevallen wordt minstens één test. Zo loopt de brug van tekst naar code. De specificatie zegt wat waar moet zijn, de test controleert of het waar is, en de code bestaat om die test groen te krijgen. Een specificatie met openstaande vragen keuren we niet goed. Een agent die zonder antwoorden begint gaat gokken, en een plausibele gok kost je later meer dan de vraag vooraf stellen.
Voor de klant heeft dat een prettig gevolg. Wat we bouwen staat in leesbare taal op papier voordat het bestaat. Dat is geen offerte-praat, het is de bron waar de software uit voortkomt. Wat er niet in staat, bouwen we niet, en juist daar wil je grip op houden.
Waarom dit een betere afspraak is dan uren code
Bij het oude model kocht je inspanning. Zoveel uur, zoveel code. De kwaliteit zat verstopt in het vakmanschap van degene die het typte, en die zag je pas als er iets misging.
Bij dit model koop je een beschreven, toetsbare uitkomst. Je leest de specificatie en vormt er een oordeel over voordat er een euro aan code is uitgegeven. Verandert de wens, dan verander je de specificatie en volgt de code. En omdat elke eis aan een test hangt, weet je niet alleen dat het ooit werkte, maar dat het vandaag nog werkt.
Tot hier is dit het ondernemersverhaal. De rest gaat over hoe je een agent zich hieraan laat houden, want zonder dat blijft het bovenstaande een mooi voornemen.
Sturing is data, geen tekst
De eerste vergissing die mensen maken is alle regels in één groot instructie bestand voor de AI proppen. Dat werkt tot het lang wordt. Daarna spreekt het zichzelf tegen en loopt het achter, en kiest de agent de regel die het dichtst bij zijn context staat. Dat is lang niet altijd de juiste.
Ons hoofd-instructiebestand begint daarom met de mededeling dat het zelf geen regels bevat. Het is een wegwijzer die zegt waar elke regel woont. De teststandaard staat op één plek, de architectuurregels op een andere. Elk feit bestaat in precies één bestand. Staat hetzelfde feit op twee plekken, dan is dat een defect dat we opruimen.
De toets is simpel. Als dit morgen verandert, hoeveel bestanden moet ik dan aanpassen? Het enige goede antwoord is één.
Het aardige effect zit in de laatste stap van elke wijziging. De reviewstap die het werk aan de standaarden toetst, leest die standaardenmap op het moment dat hij draait. Een regel aanpassen verandert daarmee automatisch wat er wordt afgedwongen. Je hoeft geen tweede lijst bij te werken en er is geen checklist die achterloopt. De regels zijn data, en de handhaving haalt ze live op. Dat lijkt een detail, maar het is het verschil tussen regels die kloppen en regels die ooit klopten.
De hekken staan in code, niet in tekst
Een standaard die alleen in een document staat, is een verzoek. Agents houden zich er grotendeels aan, tot het onder druk niet uitkomt, net als mensen. Wat echt niet mag, zetten we daarom in de machinerie in plaats van in tekst.
De kwaliteitspoort is één commando dat vier dingen achter elkaar draait: stijlcontrole, statische analyse op het strengste niveau zonder uitzonderingen, een controle die de architectuurlagen mechanisch afdwingt, en de volledige testsuite. Geen van die vier kun je overslaan. Een blokkade weigert bovendien elke poging om de controles bij het vastleggen te omzeilen. De enige weg langs een rode test is de test repareren.
Wat dit betrouwbaar maakt gaat nog een stap verder, en daar kijkt een ervaren engineer van op: de hekken zelf worden getest. De regel die de architectuurlagen afdwingt, controleren we met een test die nagaat of elke nieuwe map wel onder een regel valt. Zonder die test zou een laag die later wordt toegevoegd door niemand bewaakt worden, terwijl de poort vrolijk groen bleef. Een controle die stiekem niets meer controleert is gevaarlijker dan geen controle, want je vertrouwt erop. Dus testen we de bewakers zoals we de rest testen.
Onmogelijk maken werkt beter dan bewaken
De sterkste regel in het project vind je nergens als regel terug.
Er zijn velden die een gebruiker nooit zelf mag zetten, zoals rechten en eigenaarschap. De voor de hand liggende aanpak is een controle: komt dit veld binnen, weiger het. Maar een controle kun je vergeten, en een agent die snel een functie toevoegt vergeet hem net zo makkelijk als een mens.
Dus zit dat veld niet in de controle. Het zit ook niet in de verwerking. Het bestaat daar simpelweg niet, want er is geen tak in de code die het zou kunnen accepteren. Een bewaker kan een slechte dag hebben, een ontbrekende tak niet. Wat niet bestaat, kan niet verkeerd gaan.
Dat is de denklijn achter de hele opzet. Overal waar het kan, maken we het verkeerde onmogelijk in plaats van het te verbieden. Een verbod leunt op oordeel, en oordeel valt onder druk als eerste weg, of dat nu van een mens of een agent is.
Waar de mens zit
Het klinkt misschien alsof de mens overbodig is geworden. In werkelijkheid is zijn werk verschoven naar waar het het zwaarst weegt.
De mens beslist wat er gebouwd wordt en wat niet. De specificatie schrijven en goedkeuren is het echte werk, want daar zitten de dure vergissingen: een verkeerde aanname in een spec plant zich voort in alles wat eruit volgt. De mens ziet ook wat ontbreekt, de gaten die een agent liever plausibel invult dan meldt, en bepaalt wanneer een open vraag een gok is die je nog niet mag nemen.
De agent is uitstekend in uitvoeren. Een goedgekeurde specificatie omzetten in code, test-first, geval voor geval. Dat is geen kleine rol, maar het is uitvoering, en daar strandt een project zelden op. Projecten stranden op onbeschreven aannames. Die schrijf je op, of je laat de agent ze voor je verzinnen.
Wat dit kost, en waarom het toch de goedkoopste weg is
Even eerlijk over de prijs: dit is vooraf meer werk. Je schrijft specificaties en standaarden, maakt een testplan per eis, en bouwt hekken die je daarna ook nog test. Voor een klusje van twee weken zou dat onzin zijn.
Het meeste hiervan is alleen wel wat goede projecten altijd al hadden moeten hebben. Het verschil is dat je er nu niet meer omheen kunt, want een agent die zonder dit werkt maakt de rommel alleen sneller. De winst is dat de software niet aan één hoofd hangt. De specificatie is de waarheid en de code volgt eruit, dus over twee jaar begint de volgende, mens of agent, met exact hetzelfde afgebakende beeld als wij vandaag.
De code was nooit het waardevolle deel. Dat was altijd de helderheid over wat je precies wilde. Die schreven we vroeger niet op omdat de code het duurst was. Nu de code goedkoop is, blijkt die helderheid het product.
Hexxore bouwt software spec-driven, met AI-agents en strakke standaarden, en adviseert over hoe je dat verantwoord inricht. Speelt die vraag bij een project van jou? Vertel het ons.