Waarom dit geen simpel “AI typt sneller” verhaal is

De verleiding is groot om te zeggen dat AI software gewoon sneller laat bouwen, punt. Dat is te grof. Het meest rigoureuze gecontroleerde onderzoek tot nu toe (METR, 2025) vond zelfs het tegenovergestelde bij complexe taken: ervaren ontwikkelaars werkten daar 19% trager met AI-hulp, niet sneller. Wie beweert dat AI alles automatisch versnelt, gaat voorbij aan wat dat onderzoek net liet zien.

Wat dan wel klopt, is preciezer en minder catchy: voor een afgebakende, goed geschetste taak verandert AI de manier van werken op een manier die tijd bespaart. Dat komt door de volgorde van bouwen om te draaien, minder door sneller te typen.

De volgorde draait om: eerst iets werkends, dan pas bijsturen

Het klassieke traject begint met specificaties: weken, soms maanden, om op papier te beschrijven wat er precies gebouwd moet worden, voor er één regel code geschreven is. Dat document veroudert vaak al voor het bouwen begint, omdat niemand vooraf alles juist kan inschatten. Tegen de tijd dat er iets werkends te zien is, zijn de eerste aannames vaak al voorbijgestreefd.

Met AI als gereedschap is het haalbaarder om die volgorde om te draaien: eerst een klein, werkend onderdeel bouwen op echte data, dan pas bijsturen op basis van wat blijkt te kloppen of niet. Dat is geen technisch trucje. Het is een andere manier van beslissen: niet vooraf alles proberen voorspellen, wel snel iets tastbaars hebben om op te reageren. Dat is ook waarom bij Niklu een traject start met een klein, werkend onderdeel binnen de eerste dagen, zie wat levert de eerste twee dagen concreet op?

Wat AI daarin precies overneemt

AI neemt vooral herhalend, standaard schrijfwerk over: de code die in bijna elk project nodig is, maar die zelden het interessante of risicovolle deel is. Denk aan een formulier dat gegevens netjes naar een systeem doorstuurt, of een eerste opzet van hoe twee schermen met elkaar praten. Dat scheelt tijd, omdat het veel voorkomend, voorspelbaar werk was, geen moeilijk werk.

Het moeilijke deel van software bouwen, het model (de opbouw van hoe gegevens en regels in het systeem samenhangen) juist ontwerpen, blijft mensenwerk. Dat is ook waar de METR-bevinding op complexe taken vandaan komt: op dat soort werk helpt AI minder, en soms zelfs averechts.

Waarom dit vooral bij afgebakende taken werkt

Deze snelheid is smal, niet algemeen. Ze geldt voor een goed geschetste, afgebakende bouwopdracht: één koppeling, één intern hulpmiddel, één gerichte automatisering. Voor zo’n taak wint itereren op echte data het van eerst alles vooraf uittypen. Voor een groot, onduidelijk afgebakend traject met veel onderlinge afhankelijkheden geldt dat niet automatisch, en soms het tegenovergestelde, precies wat het METR-onderzoek liet zien.

Dat is ook waarom Niklu in dagen werkt op kleine, afgebakende stukken in plaats van op één groot, vaag omschreven traject. Zie wanneer is maatwerksoftware een slecht idee? voor wanneer die afbakening zelf al niet lukt.

Wat dit niet betekent voor veiligheid

Sneller bouwen zegt niets over hoe veilig het resultaat is. Dat is een aparte vraag, met een apart antwoord: niet “iemand leest alles na”, wel een systeem van rechten, tests en zichtbare fouten eromheen. Dat staat uitgebreid uitgelegd in is software die met AI gebouwd is wel veilig?

Twijfelt u of uw eigen idee afgebakend genoeg is om op deze manier snel iets werkends te krijgen? Een gratis kennismaking van een half uur bekijkt dat graag mee.