Snelheid is geen kwaliteit

AI maakt het makkelijk om snelheid met kwaliteit te verwarren. Een model levert in twee minuten een analyse, een prototype staat in een middag, en in de demo doet een agent precies wat hij moet doen. Wat je op het scherm ziet, bepaalt dan hoe je het werk beoordeelt.

Vibe coding versterkt dat. Je beschrijft wat je wilt, het model schrijft de code, en na een paar uur heb je iets dat werkt zolang jij de enige gebruiker bent.

Wat is het verschil tussen een vibe-coded prototype en een productiesysteem?

Een prototype laat zien dat iets kan; een productiesysteem blijft werken als veel mensen het elke dag gebruiken en de bouwer er niet bij is. Een prototype hoeft niet onder vijfhonderd echte gebruikers te draaien en geen uitzonderingen af te handelen. Logging, een rechtenstructuur, een fallback, een overdracht en een eigenaar kan het missen. Een productiesysteem niet.

Als ik de code van een prototype beoordeel, is de basis vaak beter dan verwacht. Wat ontbreekt is bijna altijd de productielaag: tests, een plek waar iemand anders dan de bouwer het systeem beheert, en een opzet die meer dan de eerste gebruikers aankan. Dat is geen verwijt aan wie het prototype bouwde. Het prototype had een andere taak.

Bij mijn eigen product Signal Match zag ik hetzelfde van de andere kant. In juli ging het meeste werk naar tests, facturatie en het automatisch herstellen van vastgelopen verwerking. Nieuwe functies kwamen die maand op de tweede plaats. Een gebruiker ziet dat werk nooit, maar merkt het meteen als het ontbreekt.

Opnieuw bouwen of versterken?

Versterk wat er staat als de basis klopt, en bouw opnieuw als die basis ontbreekt. Zijn beveiliging en opbouw in orde, dan gaat het werk naar de productielaag en blijft de rest staan. Ontbreekt de beveiliging of is de code niet te volgen, dan is opnieuw beginnen meestal goedkoper dan repareren.

Timing telt ook. Zolang er alleen testaccounts zijn, kun je het datamodel nog omgooien zonder dat iemand er last van heeft. Met echte gebruikers en echte gegevens wordt elke wijziging een migratie. Zet de stap naar productie dus voordat de eerste klant inlogt.

Wat kost de productiekloof?

De afstand tussen demo en dagelijks gebruik noem ik de productiekloof. Daar zit het werk dat snelle trajecten vaak doorschuiven: compliance, onderhoud, en zorgen dat mensen het systeem ook echt gebruiken.

Die rekening komt later. Bij de lancering, als compliance alsnog blokkeert: sinds 2 augustus 2026 moet een chatbot onder artikel 50 van de EU AI Act melden dat je met AI praat, tenzij dat al duidelijk is. Een prototype houdt daar zelden rekening mee. Wat er verder geldt, staat op mijn pagina over de EU AI Act. Na drie maanden komt de rekening als niemand eigenaar is. Of op een dinsdagochtend, als de enige bouwer weg is en het systeem stilvalt.

Gartner verwacht dat ruim 40 procent van de agent-projecten voor eind 2027 wordt gestopt, door oplopende kosten, onduidelijke bedrijfswaarde of gebrekkige risicobeheersing. Dat zijn precies de posten die in een demo niet zichtbaar zijn.

Hoe breng je een AI-prototype naar productie?

Begin met vastleggen wat “klaar” betekent, en test daarna op de data van de klant. Dit is de volgorde die ik aanhoud:

1. Een definitie van done in week één. Welke vragen beantwoordt het systeem, met welk foutpercentage, in welk systeem, en wie beoordeelt dat?
2. Een nulmeting. Hoe loopt het proces nu, in minuten per taak of fouten per batch? Zonder die meting is elk resultaat een mening.
3. Testen op echte gegevens. Een toepassing kan goed werken op de testset van de bouwer en anders uitpakken op gegevens uit het dagelijkse werk. De evaluatieset draait daarom op de machine van de klant.
4. De productielaag. Logging, rechten, een fallback, en momenten waarop een mens kan controleren en corrigeren voordat het systeem verdergaat.
5. Een eigenaar en een runbook. Eén naam in de organisatie, en één pagina over wat het systeem doet, wat het niet mag en waar je kijkt als het stilvalt.

Elke stap komt uit een les in mijn memo over 35+ implementaties, met de voorbeelden erbij.

Wanneer helpt snel bouwen wel?

Als je de snelheid gebruikt om eerder te leren. Dit is geen pleidooi voor maanden discovery: een kleine scope in vier weken is vaak beter dan een roadmap van honderd pagina’s.

Snel een hypothese testen is goed, en snel bouwen met de toekomstige eigenaar ernaast ook. Het gaat mis als een demo wordt verkocht als productiesysteem, of als er gebouwd wordt zonder overdracht. Dan blijft de klant afhankelijk van de bouwer.

Een vroeg beslismoment is goedkoper dan een verrassing in week drie. In mijn trajecten valt dat op dag vijf. Is de case simpel, dan bouwen we door in week drie en vier. Is hij gemiddeld, dan kiest de klant tussen een simpelere automatisering nu of een groter traject. Is hij complex, dan vervalt de korte vorm en start meteen een langer traject.

Stel bij elk snel traject dus de vraag wat de snelheid heeft weggelaten.

Waarom diepte vaak sneller is

Een systeem met een duidelijke scope, één eigenaar, documentatie en meetpunten komt sneller door de organisatie dan een glimmende demo waar niemand een besluit over neemt. Je verliest minder tijd aan herstelwerk, aan vertrouwen terugwinnen en aan uitleggen waarom iets dat “al werkte” opnieuw gebouwd moet worden.

Vertrouwen is daarbij de dure post. AI-agents draaien inmiddels 95 tot 99 procent van de tijd zonder fouten, maar mensen onthouden die ene fout. Krijgen ze daar geen uitleg bij, dan gaan ze om de tool heen werken.

Daarom bouw ik liever één workflow goed dan vijf prototypes half. Eén systeem dat gebruikt wordt zegt meer dan vijf ideeën die op Slack applaus krijgen.