AI-first-softwareontwerp vanuit eerste principes: een gids voor de praktijk

De meeste teams hebben AI ingevoerd zonder één aanname eronder te herzien, en daarom werd de uitvoer sneller en werden de systemen slechter.

Hier is de vraag die de meeste technische teams nog niet hardop hebben gezegd: als het model de code kan schrijven, waar horen wij nu precies goed in te zijn?

De antwoorden die ik hoor, zijn overwegend verdedigend. Vaardigheid met prompts. AI-uitvoer nakijken. Weten naar welk hulpmiddel te grijpen. Allemaal echte vaardigheden, allemaal een gevolg van de eigenlijke verschuiving, en geen ervan verklaart wat ik in de praktijk steeds zie: teams die dezelfde hulpmiddelen in hetzelfde kwartaal met dezelfde modellen hebben ingevoerd en op volstrekt verschillende plekken eindigen. De ene groep brengt sneller uit en de software houdt. De andere brengt sneller uit en besteedt het volgende kwartaal aan uitzoeken wat ze heeft gebroken.

Dezelfde hulpmiddelen. Tegengestelde uitkomsten. Dat verschil gaat niet over het model.

De versterker die niemand had ingerekend

Het DORA-rapport van 2025 over de stand van door AI ondersteunde softwareontwikkeling zette hier cijfers op. 90 procent van de mensen die in de techniek werken gebruikt nu AI op het werk, en meer dan 80 procent gelooft dat het hun productiviteit heeft verhoogd. Beide zijn niet verrassend. De uitkomst die telt is de derde: een hogere inzet van AI gaat samen met een toename van de leveringsproductiviteit en met een toename van de leveringsinstabiliteit, op hetzelfde moment.

Lees dat nog eens, want dat is het hele argument. Het hulpmiddel maakte teams sneller in het uitbrengen en slechter in het in de lucht houden. Niet het een of het ander. Beide.

De kadering van DORA is dat AI een versterker is: ze vergroot de praktijk waarop ze landt. Sterke systemen worden sterker. Zwakke systemen worden sneller zwak.

Wat betekent dat de interessante vraag nooit was «hoe voeren we AI in». Ze was «wat versterkt AI in ons». En om dat te beantwoorden moet je verder terug dan welke keuze van hulpmiddel ook.

Denken vanuit het probleem, niet vanuit het hulpmiddel

Denken vanuit eerste principes is een van die uitdrukkingen die tot betekenisloosheid zijn herhaald, dus laat me precies zijn over wat ik ermee bedoel en wat niet.

Denken naar analogie is hoe de meeste invoering van AI eruitzag. We hadden een manier van werken in de ontwikkeling. Er kwam een nieuw vermogen. We vroegen waar dat vermogen in de gang past, voegden het toe op het punt van de minste weerstand, meestal het schrijven van code, en lieten al het andere gelijk. Dagelijkse overleggen, tickets, werkrondes, revisies, alles behouden. De gang werd als gegeven behandeld en het hulpmiddel eraan aangepast.

Denken vanuit eerste principes stelt een moeilijkere vraag. Breng het proces terug tot wat werkelijk, feitelijk waar is over het bouwen van software. Vraag dan welke van die waarheden het model heeft veranderd, en welke het niet heeft aangeraakt. Bouw opnieuw op uit wat overblijft.

Doe dat eerlijk en je vindt dat AI precies één ding heeft veranderd, en het is niet het ding dat de categorie verkoopt.

De kosten van code opleveren zijn naar bijna nul gegaan. De kosten van beslissen wat de code zou moeten zijn, zijn niet bewogen.

Al het nuttige volgt uit die ene ongelijkheid. Hieronder staan de vier gevolgen die ik iedereen in de praktijk uit het hoofd zou willen laten noemen.

Een: het gegevensmodel is het product

Het scherm is het meest vluchtige deel van elke toepassing en de meest verleidelijke plek om te beginnen, omdat het het deel is dat je kunt zien. Het is ook het deel dat het goedkoopst zou moeten zijn om weg te gooien.

Het gegevensmodel is het tegendeel. Het bepaalt wat je kunt opvragen, wat je kunt indexeren, wat je later kunt veranderen zonder een migratie die iedereen bang maakt. Elk vermogen verderop wordt begrensd door keuzes die op die laag zijn genomen of geïmproviseerd.

Toen code duur was, dwong die volgorde zich zelf af. Niemand schreef met de hand honderd schermen tegen een schema waarover hij niet had nagedacht, want honderd schermen met de hand kostte een kwartaal. Het opleveren heeft die natuurlijke poort weggehaald. Je kunt nu een hele interface opleveren tegen een gegevensmodel dat geen mens ooit heeft nagekeken, en die zal er af uitzien.

De volgorde moet dus bewust worden. Eerst het model, dan het contract, dan de interface. Niet omdat het traditioneel is, maar omdat het de enige volgorde is waarin de dure beslissingen worden genomen terwijl ze nog goedkoop te veranderen zijn.

Twee: een uitgestelde beslissing wordt toch genomen

Dit is wat mensen in de praktijk onderschatten.

Elke beslissing die je niet uitdrukkelijk neemt, wordt toch genomen. Ze wordt genomen door de generator, op het moment van opleveren, uit een context die jouw bedrijf, jouw nalevingsoppervlak, jouw migratiegeschiedenis of jouw plannen voor het volgende kwartaal niet omvat. Het model weigert niet te beslissen. Het kiest iets aannemelijks en gaat verder.

Wat mag een gebruiker met een opgezegd abonnement nog zien? Wat gebeurt er wanneer twee mensen hetzelfde record bewerken? Is een e-mailadres uniek, en uniek ten opzichte van wat? Niemand heeft die vragen geprompt, dus niemand heeft ze beantwoord, en de toepassing heeft nu op alle drie een antwoord, gekozen door gevolgtrekking, alleen te ontdekken door er in productie tegenaan te lopen.

Dat is het mechanisme achter wat gemeenschappen van bouwers het 70-procentprobleem hebben genoemd. De voortgang loopt niet vast omdat het resterende werk moeilijk is, maar omdat het geblokkeerd wordt door beslissingen die stilzwijgend zijn genomen, enkele honderden generaties eerder, en die niet meer te veranderen zijn zonder het geheel uit elkaar te trekken.

De praktijk die dit verhelpt, heeft nu een naam: specificatiegestuurde ontwikkeling. Schrijf eerst de eisen, de randvoorwaarden en de succescriteria op. Behandel dat document als de bron van waarheid. Laat de agent daartegen bouwen. GitHub bracht Spec Kit uit, AWS bracht Kiro uit, en het samenvallen is geen toeval.

Drie: wanneer opleveren gratis is, moeten randvoorwaarden worden opgeschreven

Decennialang werd juistheid deels gedragen door de kosten van code schrijven. Wie een regel uitvoerde, moest de regel in gedachten houden. Stilzwijgende kennis in een menselijk hoofd was een aanvaardbare plek om een randvoorwaarde te bewaren, omdat er altijd een mens in de lus zat.

Die bewaarplek werkt niet meer. Als een randvoorwaarde niet ergens door machines leesbaar is uitgedrukt (een schemabeperking, een type, een validatieregel, een test, een uitdrukkelijke regel in een specificatie) bestaat ze voor de generator niet. Ze bestaat alleen in het geheugen van wie op het punt staat verrast te worden.

Dat is de praktische kern van AI-first-ontwerp, en het is volstrekt onglamoureus. Duw invarianten naar beneden, naar de laag die ze kan afdwingen. «Niet leeg» en «uniek» in de database in plaats van in een formulierverwerker. Typen op de grenzen in plaats van in een opmerking in de code. Autorisatie als beleid dat het systeem beoordeelt in plaats van als voorwaarde die iemand zich herinnerde in een toegangspunt te schrijven.

Elke randvoorwaarde die je naar buiten brengt, is een beslissing die het model niet meer verkeerd kan nemen.

Vier: je bouwt nu voor twee afnemers

De laatste is de nieuwste en de minst verinnerlijkte bij de meeste teams.

Jouw toepassing heeft nu twee soorten gebruikers. De ene is een mens die naar een scherm kijkt. De andere is een agent die een API aanroept, jouw interface nooit ziet en niet door goed ontwerp overtuigd kan worden. Als een vermogen in jouw interface bestaat maar niet in jouw API, dan bestaat het niet, voor zover het de economie van agenten aangaat.

Dat heeft een ontwerpgevolg: pariteit is geen prettig extra. Alles wat een mens via de interface kan doen, zou bereikbaar moeten zijn via een bepaald, gedocumenteerd, vindbaar oppervlak. Daarom past ook GraphQL beter dan REST voor gebruik door agenten: een schema dat zichzelf beschrijft is iets wat een machine kan verkennen zonder dat eerst een mens integratieaantekeningen schrijft.

Bouw voor de agent en de menselijke interface wordt als bijwerking eenvoudiger. Bouw alleen voor de mens en je zult onder tijdsdruk achteraf een API aanbrengen, wat het slechtst mogelijke moment is om er een te ontwerpen.

Hoe het eruitziet in de cijfers wanneer je dit overslaat

GitClear analyseerde 623 miljoen codewijzigingen van 2023 tot 2026, en het beeld van de onderhoudbaarheid past bij alles wat hierboven staat.

Tegenover de basislijn van 2023 zijn verdubbelde codeblokken 81 procent gestegen. Kopiëren en plakken binnen dezelfde inzending steeg van 9,4 procent in 2022 naar 15,7 procent in de eerste helft van 2026. Constructies die fouten verhullen zijn 47 procent gestegen. Tegelijk zijn functieaanroepen over bestanden heen, het duidelijkste beschikbare teken van hergebruik van code, 35 procent gedaald, en is het herstructureringswerk ingestort van 21 procent van de wijzigingen in 2022 naar tot nu toe 3,8 procent in 2026.

Wie ontwikkelt kopieert en plakt nu ongeveer vijf keer zo vaak als hij herstructureert. In 2022 liep die verhouding de andere kant op.

Niets daarvan is een kwestie van modelkwaliteit. Verdubbeling in plaats van hergebruik, foutbehandeling die verzwelgt in plaats van naar boven brengt, herstructurering die ophoudt te gebeuren: dat krijg je wanneer opleveren goedkoop is en structuur uitdrukkelijk niemands taak. De uitvoer is plaatselijk aannemelijk en in het geheel onsamenhangend, en dat is precies de manier van falen die een gang die bij het scherm begon niet kan opmerken.

Hoe je zo werkt, vanaf deze week

Niets hiervan vraagt een reorganisatie. Het vraagt de volgorde van vier of vijf gewoonten te veranderen.

1. Schrijf het gegevensmodel vóór het eerste scherm. Entiteiten, relaties, kardinaliteit, wat een rij uniek maakt, wat bij verwijderen doorwerkt. Een uur hier is het uur met de meeste hefboom van het project, en het is het uur dat de hulpmiddelen je actief uitnodigen over te slaan.
2. Maak de specificatie het artefact dat je nakijkt, niet de diff. Als de specificatie goed is en het opleveren haar trouw volgt, is duizenden regels opgeleverde code nakijken theater. Kijk het document na dat ze heeft opgeleverd. Discussieer over de specificatie terwijl discussiëren nog weinig kost.
3. Breng elke randvoorwaarde naar buiten die je kunt benoemen. Zet vóór het opleveren de regels op een rij die nooit geschonden mogen worden en leg elk daarvan neer waar het systeem die afdwingt. Alles wat in het gesprek blijft, wordt vroeg of laat geschonden door iets wat nooit aan het gesprek heeft deelgenomen.
4. Ontwerp de API als het oppervlak van het product. Behandel de menselijke interface daarna als één afnemer daarvan. Dat is meer een keuze over volgorde dan een technische, en die laat inplannen is wat haar duur maakt.
5. Meet instabiliteit, niet alleen productiviteit. De uitkomst van DORA is dat snelheid en brakheid samen stegen, dus als je alleen snelheid meet, zie je de goede helft van je eigen trend. Het foutpercentage van wijzigingen en de tijd tot herstel zijn de cijfers die je vertellen of de versterker voor jou werkt.

Wat dit kost

Ik wil openhartig zijn over de afweging in plaats van te doen alsof er geen is.

Zo werken is langzamer in de eerste week van een project en wezenlijk sneller in elke week daarna. Dat zijn echte kosten, vooraf betaald, precies op het moment dat aanloop het meest waardevol lijkt en een concurrent iets zichtbaars uitbrengt. Er zullen werkrondes zijn waarin het team dat dit allemaal oversloeg lijkt voor te lopen.

Het is ook niet gratis in discipline. Randvoorwaarden opschrijven is minder prettig dan een interface zien verschijnen. Een specificatie nakijken is minder bevredigend dan code nakijken. Die gewoonten vervallen onder tijdsdruk, en dat is dezelfde druk die ze belangrijk maakt.

En een deel hiervan geldt werkelijk niet. Als je dit weekend een idee toetst en het resultaat wilt weggooien, gooi het weg: niets van het bovenstaande is de moeite waard voor software met twee dagen levensduur. Het argument hier gaat over toepassingen die hun eigen demonstratie overleven.

Het deel dat nooit te automatiseren was

Sommige rollen die rond het opleveren van code zijn gebouwd, zullen krimpen. Sommige zullen verdwijnen. Het tegendeel beweren helpt niemand zich voor te bereiden, en de mensen die je vertellen dat elke plek in de techniek veilig is, doen je geen plezier.

Maar kijk naar wat die ongelijkheid werkelijk heeft gedaan. Ze heeft het uitdrukken van beslissingen geautomatiseerd en de beslissingen zelf volstrekt onaangeroerd gelaten. Wat te bouwen. Wat niet te bouwen. Welke invarianten gelden. Wat het systeem nooit mag doen. Waar de grenzen liggen en wie ze mag overschrijden.

Dat werk was altijd het moeilijke deel. Het lag alleen verborgen onder de moeite van het typen, die duur genoeg was om op het werk te lijken.

Typen was nooit het werk.

Verwante lectuur

De praktijk in de diepte: specificatiegestuurde ontwikkeling. Als je een hulpmiddel kiest: de beste AI-appbouwers in 2026.

Veelgestelde vragen

Wat betekent «AI-first-softwareontwerp»? Een toepassing ontwerpen vanuit de aanname dat de meeste code wordt opgeleverd in plaats van met de hand geschreven, en dat sommige afnemers agenten zijn in plaats van mensen. In de praktijk betekent het dat gegevensmodel, randvoorwaarden en API-contract vooraf uitdrukkelijk worden bepaald, omdat dat de beslissingen zijn die het opleveren niet voor je kan nemen.

Waarin verschilt AI-first-ontwerp van simpelweg AI-hulpmiddelen voor code gebruiken? AI-hulpmiddelen gebruiken voegt een vermogen toe aan een onveranderde gang. AI-first-ontwerp verandert de volgorde van de stappen in de gang: model en contract vóór de interface, specificatie als het nagekeken artefact, randvoorwaarden geduwd naar lagen die ze afdwingen. Het DORA-onderzoek van 2025 vond dat de invoering van AI productiviteit en instabiliteit samen verhoogde, en dat is wat gebeurt wanneer het hulpmiddel verandert en de praktijk niet.

Wat zijn de eerste principes van softwareontwerp in het AI-tijdperk? Vier houden stand: het gegevensmodel is het product en het scherm is een weergave ervan; elke beslissing die je niet uitdrukkelijk neemt, wordt stilzwijgend door de generator genomen; randvoorwaarden moeten ergens door machines afdwingbaar leven in plaats van in iemands hoofd; en jouw toepassing bedient nu zowel een menselijke interface als een API voor agenten, die pariteit nodig hebben.

Vertraagt zo ontwerpen teams? Het haalt werk naar voren in plaats van eraan toe te voegen. De beslissingen die een gegevensmodel en een specificatie vastleggen, worden toch door iemand genomen: of bewust aan het begin, of stilzwijgend door een model dat later gokt. De tweede weg is de bron van het herstelwerk, en herstelwerk is niet sneller.

Is specificatiegestuurde ontwikkeling hetzelfde als AI-first-ontwerp? Specificatiegestuurde ontwikkeling is de praktijk; AI-first-ontwerp is de ruimere verzameling architectonische gevolgen. De eerste dekt de specificatie schrijven en daartegen opleveren. AI-first-ontwerp dekt ook de volgorde van het modelleren van gegevens, de plek waar randvoorwaarden worden afgedwongen en het ontwerpen voor afnemers die agenten zijn naast afnemers die mensen zijn.

Wanneer is het prima dit allemaal over te slaan? Bij prototypes, demonstraties, interne eenmalige stukken en alles wat je van plan bent te verwerpen. Het extra gewicht is alleen de moeite waard voor software die echte gebruikers, echte gegevens en verandering in de tijd moet overleven.