“Als AI vanaf het begin had bestaan”: goedkoper code schrijven maakt het niet makkelijker om te beslissen wat te bouwen

Voor het grootste deel van de geschiedenis van software was de dure factor het bouwen ervan. Teams hebben maanden besteed aan het omzetten van ideeën in werkende code, en die schaarste heeft alles beïnvloed over hoe het werk werd georganiseerd.

Roadmaps werden gepland rondom de beschikbare engineeringscapaciteit; architecten verdienden hun plaats aan tafel omdat ze systemen begrepen die niemand anders deed; productmanagers hebben hun weken besteed aan het vertalen van vage bedrijfsverzoeken in iets dat een ontwikkelaar kon uitvoeren. Het schrijven van software was de bottleneck, en natuurlijk was het schrijven ervan waar de hefboom woonde.

Dat is niet langer waar, en de verschuiving gebeurde sneller dan de meeste engineeringsleiders de tijd hebben gehad om te verwerken.

AI-codingtools hebben de kosten van implementatie laten instorten. Dus werk dat een team van engineers weken kostte, kost nu een agent een paar uur. En de voor de hand liggende veronderstelling was dat snellere bouw rechtstreeks zou vertalen naar snellere waarde geleverd.

Wat er eigenlijk is gebeurd, is echter rommeliger: teams kunnen nu meer software produceren dan ze weten wat ze ermee moeten doen, en het ding dat ze vertraagt, is stil naar een andere plek verhuisd.

“Je kunt AI niet toepassen op een gebroken proces”, zei Pablo Gamba, hoofd van technologie Amerika’s bij de wereldwijde software- en AI-oplossingenstartup intive. “Het is alsof je een snellere schep geeft aan een werker. Hij zal sneller werken, maar alleen in de verkeerde richting.”

Snelere uitvoering, dezelfde oude beperking

Elke grote verandering in technologie – het internet, de cloud en uitbesteding – heeft een identieke vorm gevolgd. Iets dat eerst duur was, werd goedkoop bijna van de ene op de andere dag, en alles wat een bedrijf had gebouwd op de veronderstelling van die kosten, moest worden afgebroken en opnieuw worden opgebouwd.

Dit keer is het dat technische intelligentie zelf goedkoop wordt, wat toevallig precies is waarvoor dienstverleners en engineeringsteams decennialang in rekening hebben gebracht, beweert Gamba.

Goedkopere uitvoering maakt de beperking niet onzichtbaar, maar verplaatst deze naar een minder zichtbare plek. De coderingsbottleneck, bijvoorbeeld, in het migreren stroomopwaarts, heeft de implementatie versneld, maar het obstakel ligt nu in de codereview. Automatiseer de codereview en het verschijnt in testen en implementatie; automatiseer dat ook, en uiteindelijk komt het terecht bij de mensen die de specificaties schrijven waar de agenten mee werken.

Omdat een agent alleen kan bouwen wat precies genoeg is beschreven om zonder te gissen te kunnen uitvoeren.

Dat is de valkuil waarin veel teams nu lopen, vaak zonder het te merken. Als je bijna alles kunt bouwen in een fractie van de tijd die het vroeger kostte, neemt de kosten van het bouwen van de verkeerde dingen toe, niet af, omdat je erachter komt dat je fout was, sneller en met meer al geleverd.

Een veronderstelling die eerder langzaam aan het licht kwam, over weken van handmatig coderen, kan nu load-bearing infrastructuur worden voordat iemand eraan denkt om het in twijfel te trekken. Priorisatie, niet ruwe output, beslist uiteindelijk of de AI-investering zichzelf terugbetaalt.

In dit paradigma gelooft Gamba dat bedrijven niet de ontwikkelingsnelheid moeten volgen, maar de volledige cyclus van intentie tot productie. “Als je de ontwikkelingsnelheid verbetert, maar QA je bottleneck is, ben je nu sneller bij QA aangekomen. Dan los je QA op en verplaatst de bottleneck zich naar de vereisten”, zei hij.

De cijfers ondersteunen hem ook. Fortune 50-bedrijven die AI-geassisteerde ontwikkeling gebruiken, leveren commits 3x-4x sneller dan hun concurrenten, volgens onderzoek van de Cloud Security Alliance, maar introduceren nieuwe beveiligingsbevindingen met ongeveer tien keer de snelheid.

Snelheid zonder een duidelijke bestemming verkwist in dit opzicht niet alleen inspanningen; het verhoogt het risico sneller dan de meeste beveiligingsteams kunnen bijhouden.

Vereisten in een taal krijgen die AI daadwerkelijk kan gebruiken

Als de definitie nu de echte beperking is, is de oplossing niet meer documentatie. Het is andere documentatie, geschreven in een vorm die een AI-systeem kan uitvoeren zonder gaten zelf in te vullen.

Dat betekent het intrekken van het vereistendocument dat voor een mens is geschreven om te interpreteren met oordeel en het vervangen door gestructureerde acceptatiecriteria, expliciete domeinmodellen en contracttests die aangeven wat een functie nooit moet doen, even duidelijk als wat het wel moet.

Agents vullen ambiguïteit op dezelfde manier in als een junior-engineer, met een zelfverzekerde gok. Het verschil is dat de gok van de laatste wordt omhuld met enige aarzeling, een vlag voor een senior collega, een gevoel dat er iets mis kan zijn.

De gok van een agent ziet er niet zo uit. Het verschijnt als schone, vloeiende, volledig gevormde code, en er is geen voorbehoud in, zelfs als het fout is.

Het schrijven van een specificatie die precies genoeg is om te overleven, begint te voelen als het opstellen van een contract. Je noemt elke actor, kaart elke statustransitie die het systeem mag maken, en houdt rekening met de randgevallen in plaats van ze stilzwijgend te laten vallen, op het gelukkige pad, zoals de meeste vereistendocumenten nog steeds doen.

Teams die dit behandelen als een documentatieklus leren op de harde manier dat vage intentie alleen maar vage software produceert op machinesnelheid.

De teams die de productiviteitswinsten daadwerkelijk vastleggen, zijn diegenen die het schrijven van dergelijke specificaties behandelen als een eigen ingenieursdiscipline, met dezelfde versiebeheer, reviewcycli en testrigor die eerder waren gereserveerd voor de code zelf.

In de woorden van Gamba is AI-natief geen toestemming om het proces over te slaan, maar een eis om van scratch te ontwerpen. “Veel organisaties proberen AI toe te passen op oude processen. Dat is geen transformatie. AI-natieve organisaties beginnen met een andere vraag: als AI vanaf het begin had bestaan, hoe zouden we dit proces vandaag ontwerpen?”

Backlogbeheerders, curators van intentie

Product, architectuur en engineeringsfuncties liepen vroeger als drie afzonderlijke functies met schone overdrachten tussen hen: product bepaalt wat te bouwen, architectuur figureert uit hoe, engineeringsfunctie levert het.

Als de implementatie goedkoop en snel wordt, worden die overdrachten het langzaamste deel van de hele keten. Wat er uiteindelijk toe doet, is wie de hele afbeelding tegelijk kan vasthouden, intentie kan vertalen in iets dat een agent kan uitvoeren, en een slechte veronderstelling kan vangen voordat het in geleverde code verandert die niemand wilde.

Die herontwerp beïnvloedt stil wie de definitie doet en wat de functie überhaupt nog is.

“Denk aan wat er gebeurt met de rol van de software-engineer. Ze schrijven niet langer alleen code. Ze zijn verantwoordelijk voor de output van agents, definiëren specificaties, bereiden tests voor, valideren resultaten. Dat is het samenvoegen van wat eerder drie afzonderlijke rollen waren in één”, zei Gamba.

Met andere woorden, wat nu waardevol is, is niet weten hoe je een ticket moet schrijven of een sprint moet uitvoeren. Het is weten wat “goed” lijkt voordat het werk zelfs maar begint, in staat zijn om het verschil te zien tussen wat intellectueel interessant is en wat klanten echt nodig hebben, en de moed hebben om een idee snel te doden als het duidelijk de lat niet haalt.

Die oordelen werden eerder verdeeld over een productmanager, een architect en een techlead die nota’s vergelijken. Steeds vaker komen ze terecht bij degene die het dichtst bij de definitie van het werk staat.

En het is ook de moeite waard om te onthouden: geen van dit alles doet de titels verdwijnen. Maar de lijnen tussen hen worden moeilijker te verdedigen, terwijl de mensen die in die waas gedijen, zijn diegenen die als curators van intentie handelen.

Snel uitvoeren zonder wachters is geen overwinning

Er is een risico dat gemakkelijk te verliezen is als de intentie duidelijk is en de AI-pijplijn echt loopt: snelle, goed gedefinieerde uitvoering kan nog steeds fouten introduceren die een langzamere, meer door de mens gemedieerde procedure bijna per ongeluk zou hebben opgevangen.

De cijfers hier zijn niet eens in de buurt. Veracode’s lentetesten van 2026 over de toonaangevende modellen toonden aan dat slechts 55% van de codegeneratietaken veilige output produceerden wanneer geen expliciete beveiligingsrichtlijnen werden verstrekt, een cijfer dat in twee jaar nauwelijks is veranderd, zelfs terwijl de functionele nauwkeurigheid aanzienlijk is gestegen.

Het is duidelijk dat het krijgen van de syntaxis goed een tijdje geleden niet langer het moeilijke deel was. De oordelen die een menselijke engineer instinctief maakte terwijl hij typte, rond beveiliging, naleving en welke gegevens wel of niet met welk systeem in contact mochten komen, zijn de delen die moeilijk te vervangen zijn.

Dit betekent dat dezelfde rigor die werd toegepast om te definiëren wat te bouwen, moet worden uitgebreid tot het definiëren van wat niet is toegestaan, zoals nalevingsgrenzen, gegevensbehandelingsregels en ethische beperkingen die met dezelfde zorg worden opgesteld als functionele vereisten.

Het laten impliciet en hopen dat een agent het correct afleidt, is dezelfde fout als het laten van productvereisten vaag en het kruisen van vingers in de hoop dat de build op de een of andere manier goed uitpakt.

Hoe leiderschap eruitziet

Niets van dit alles spreekt tegen AI-versnelde ontwikkeling; het bouwen is nooit sneller of goedkoper geweest, en er is geen manier om dat terug in de fles te krijgen.

Maar wat niet makkelijker is geworden, en misschien wel moeilijker, is met echte precisie beslissen wat de moeite waard is om te bouwen, het beschrijven op een manier die een machine trouw kan uitvoeren, en de lijnen trekken die het niet is toegestaan om over te steken tijdens het doen.

Op ondernemingsniveau zijn de teams die voorop lopen, niet degene met de snelste coderingsagenten, dat deel is duidelijk. Het zijn degene die hebben uitgewerkt, voordat hun concurrenten dat deden, dat de definitie altijd het moeilijkere probleem zou zijn – en zijn begonnen het zo te behandelen.