Van vibe coden naar productie

Wat vibe coden oplevert

Een proof of concept die vroeger een week kostte, staat nu in een middag. Een idee testen, een user flow visueel maken, een stakeholder overtuigen met iets dat al werkt: dat is waar vibe coding sterk in is, en die winst is reëel. Wij gebruiken AI zelf dagelijks om prototypes te versnellen, documentatie te genereren en code-onderdelen op te leveren.

Software die in productie draait, moet blijven werken bij de gebruiker die drie keer op dezelfde knop klikt, bij de collega die een ongebruikelijk teken in een zoekveld typt, en bij honderd mensen die tegelijk inloggen op een maandagochtend. Dan hebben we het nog niet eens over het sterk groeiende aantal cyberaanvallen (Q1 2025: gemiddeld 2000 aanvallen per organisatie per week – bron: Dutch IT channel). De eisen die aan een digitaal product gesteld worden, worden bepaald door alles wat er om de gegenereerde code heen georganiseerd moet worden: authenticatie, foutafhandeling, monitoring, capaciteit.

Datzelfde prototype krijgt onderweg vaak al snel het label MVP, en dat label brengt verwachtingen met zich mee: een werkend inlogproces, foutmeldingen die iets betekenen en een manier om problemen te signaleren zonder dat een ontwikkelaar meekijkt. Maar hoewel een prototype en een MVP misschien wel veel op elkaar lijken, zijn ze toch niet hetzelfde.

Het onzichtbare deel van het werk

Het ijsbergbeeld dat op dit moment rondgaat brengt dat treffend in kaart. Wij gebruikten een vergelijkbaar beeld eerder al om te beschrijven wat er nodig is om van een AI-prototype naar een productierijp platform te komen. Onder de waterlijn zit werk dat zelden in een pitch wordt getoond: authenticatie die verder gaat dan een testaccount, een omgeving waarin secrets nooit in broncode belanden, een plan voor het moment waarop een AI-leverancier zijn model uitfaseert of de prijzen aanpast, GDPR-naleving zodra externe modellen bij bedrijfsdata kunnen, audit logging, rate limiting, en een architectuur die meerdere klanten of afdelingen tegelijk kan bedienen zonder dat de een de data van de ander kan zien.

Dit zijn bekende disciplines binnen softwareontwikkeling, met bekende oplossingen, en een AI-model kaart ze aan zodra je er expliciet naar vraagt. Een taakbeheer-app met eigen logins, rolgebaseerde rechten en een audit trail vraagt om een precieze omschrijving in de prompt, en die precisie vereist kennis die zelden vanzelf ontstaat door vaker te prompten.

Dezelfde observatie geldt voor databasekeuzes, foutafhandeling en de manier waarop data over het netwerk beweegt. Een AI-model kiest doorgaans een standaardoplossing die voor een demo prima werkt. Bewust nadenken over schaalbaarheid, kosten per gebruiker en gedrag onder duizend keer zoveel verkeer vraagt een aparte stap, een stap die een model niet automatisch zet.

Architectuur is geen luxe achteraf

Architectuur bepaalt of iets vandaag werkt, en of het over zes maanden nog uit te breiden is. Wie zonder plan begint te bouwen, botst vroeg of laat op een moment waarop een nieuwe functie of een structurele wijziging niet meer past in wat er al staat. Een herbouw op dat moment kost aanzienlijk veel tijd en budget; en ja, ook als je met AI ontwikkeld. Daarom start bij GlobalOrange elk traject met een Product Discovery Workshop. Een paar dagen nadenken over scope, gebruikers en toekomstige groei voorkomt dat je maanden later alles opnieuw moet doen.

Dit raakt aan een onderscheid dat we vaker maken: softwareontwikkeling en productontwikkeling. Vibe coding zet intentie om in code. Daar begint productontwikkeling, met keuzes over wat je wel bouwt en vooral wat je niet bouwt, onderzoek naar wat gebruikers daadwerkelijk nodig hebben, en een visie die verder reikt dan de eerstvolgende demo. Code die werkt is het startpunt van een product.

Sturing bepaalt het resultaat

Ervaren ontwikkelaars gebruiken AI om sneller te itereren, precies omdat ze weten welke vraag ze moeten stellen, welke oplossing ze moeten controleren en welke aanname ze moeten corrigeren voordat die zich vastzet in de codebase. Die sturing bepaalt het resultaat net zo goed als het model zelf.

Twee teams met dezelfde tools kunnen daardoor tot heel verschillende resultaten komen. Code schrijven/reviewen is minder dan een derde van het werk dat nodig is om software in productie te krijgen. De rest bestaat uit weten hoe je iets performant houdt onder belasting, hoe je een deployment inricht zonder verrassingen, en hoe je een incident oplost voordat het een storing wordt. Een verkeerd geconfigureerde workflow of een oneindige lus in een deployment kan in korte tijd tot onverwacht hoge cloudkosten leiden. Er circuleren inmiddels genoeg voorbeelden van om dit een voorspelbaar risico te noemen van bouwen zonder ervaren blik.

Wat het kost als je dit negeert

De risico’s van een prototype dat te snel als product wordt behandeld, zijn zelden theoretisch. Een organisatie ontdekt vaak pas na een succesvolle demo dat het interne beveiligingsbeleid geen extern AI-model toestaat op bedrijfsdata, en moet dan alsnog uitzoeken hoe een vergelijkbare oplossing lokaal of binnen de eigen infrastructuur draait. Een security-incident dat met een paar uur werk aan input-validatie te voorkomen was geweest, kost achteraf weken aan herstel en een deuk in het vertrouwen van klanten. Een team dat maandenlang doorbouwt op een fundament zonder structuur, merkt dat elke nieuwe functie meer tijd kost dan de vorige.

Dit scenario is herkenbaar bij organisaties in gereguleerde sectoren, waar compliance een voorwaarde is om te mogen bestaan. Zoals ComplianceWise die consultancy verving door een schaalbaar SaaS-platform, in een sector waar security en juridische correctheid net zo zwaar wegen als functionaliteit. De vraag was steeds of het platform stand zou houden onder toezicht, onder groei en onder een auditor die precies wil weten waar data vandaan komt en wie erbij kan.