Van vibe-coding naar productie: risico's en tips uit de praktijk

Kunnen we deze app met het hele kantoor gebruiken? Als die vraag gesteld wordt, is er al iets gebouwd. Meestal niet door een ontwikkelaar, maar door iemand die dacht dat het beter kon en gewoon is begonnen met een AI-tool. Maar hoe krijg je zo’n app in productie?

Google ondervroeg vorig jaar vijfduizend ontwikkelaars. Teams die AI gebruiken leveren sneller, maar hun software valt vaker om. Hoe loopt dat als een ambitieuze medewerker de software heeft gemaakt?

Die manier van bouwen heet vibe-coding: je beschrijft wat de app moet doen, de AI schrijft de code en je leest die zelf niet. Stuurt een ontwikkelaar de AI aan op architectuur en op waar code terechtkomt, dan heet het agentic engineering. Dit artikel gaat vooral over vibe-coding, maar een deel van de risico’s geldt voor allebei.

TL;DR

• AI maakt bouwen sneller, maar zonder structuur eromheen wordt software instabieler. Bij vibe-coding volgt op de snelle start een dal zodra de app naar productie moet.
• Wij nemen de app niet over en bouwen hem niet opnieuw. We leggen de fundering eronder: gescheiden omgevingen, migraties, een pipeline, tests, monitoring en backups.
• De grootste risico’s van vibe-coding zijn lekkende autorisatie, database-drift, secrets die overal staan en stille fouten in productie.
• Vijf dingen kun je vandaag zelf al regelen, zonder ontwikkelaar.
• Onze aanpak heeft drie fasen: inventarisatie, fundering en onderhoud.

Wat er gebeurt als AI het bouwen versnelt

Teams die AI gebruiken leveren sneller op, maar er gaat vaker iets mis. Dat ontdekte Google met DORA, een onderzoeksprogramma onder ontwikkelteams. De uitkomst: AI versnelt het ontwikkelen, maar die versnelling veroorzaakt verderop in het proces gebreken. Teams zonder geautomatiseerde tests en versiebeheer krijgen door AI vooral meer wijzigingen, en dus meer dingen die kapotgaan. Het verschil zit hem dus in wat er rondom de code geregeld is.

Voor ontwikkelteams beschrijft Google dat als een J-curve. Na de start met AI zakt de opgeleverde waarde eerst: mensen moeten de tools leren, alles wat AI maakt moet gecontroleerd worden en de pipeline moet mee veranderen. Pas daarna groeit de waarde ver boven het oude niveau uit.

Bij vibe-coding zien wij in de praktijk een ander patroon: eerst een heuvel, dan een dal, zoals in de grafiek bovenaan.

Met een tool als Lovable staat in een paar dagen een complete app. Zodra die naar productie moet, zakt de snelheid: omgevingen, migraties, tests en monitoring moeten alsnog opgezet worden, en de kleine dingen blijken ineens veel tijd te kosten. Staat die fundering eenmaal, dan kun je weer net zo snel doorontwikkelen, maar nu zonder dat het omvalt. Wie het dal overslaat, kan wel blijven doorbouwen, maar elke wijziging wordt riskanter.

Werkt een ontwikkelaar vanaf het begin mee, dan groeit de fundering gelijk op met de app. De eerste versie staat dan iets minder snel, maar het dal blijft grotendeels uit.

We zijn niet de enigen die dit zien. Addy Osmani van Google noemt dit het 70%-probleem: AI brengt je snel tot 70%, maar de laatste 30%, met randgevallen, security en de koppeling met productie, kost meer tijd dan het begin.

De bouwer bouwt door, wij leggen de weg eronder

In de praktijk zien we nog iets: het klassieke gat tussen wat de opdrachtgever nodig heeft en wat de ontwikkelaar bouwt, verdwijnt, omdat de klant de functionaliteit zelf bouwt.

Deze nieuwe manier van werken zorgt dat de eerste versie ongekend snel staat. Maatwerksoftware, en daarmee procesoptimalisatie, wordt toegankelijker. Het vertaalverlies tussen wat nodig is en wat gebouwd wordt, verdwijnt, en dezelfde software kost minder dan op de klassieke manier. Die snelheid gaat wel ten koste van stabiliteit, tenzij de structuur eromheen meegroeit.

Wat wij toevoegen is alles wat nodig is zodra andere mensen afhankelijk worden van de software. We nemen de applicatie niet over en bouwen hem niet opnieuw. We zorgen dat de structuur rond de code meegroeit.

Wanneer is het productieklaar?

Productieklaar betekent bij ons dat deze acht dingen geregeld zijn:

1. Gescheiden omgevingen voor ontwikkelen, testen en productie
2. Databasemigraties als enige bron van waarheid
3. Een pipeline die elke uitrol automatisch controleert
4. Automatische smoke-, end-to-end- en securitytests
5. Monitoring en alerting in een kanaal waar mensen echt kijken
6. Gedocumenteerde toegang en secrets in een kluis
7. Een pentest door een ethisch hacker
8. Backups met een afgesproken en geteste hersteltijd

Waarom juist deze acht? Die komen voort uit wat wij in de praktijk zien.

Het gevaar van vibe-coding

Een aantal dingen zien we in de praktijk vaak fout gaan. Die moeten absoluut afgedekt zijn.

Vijf dingen die je vandaag zelf kunt doen

Heb je zelf een applicatie gebouwd met AI? Dit kun je regelen zonder ontwikkelaar, en het voorkomt de duurste problemen.

1. Zet de code in een eigen Git-account. Niet alleen in de bouwtool. Dan blijft het product van jou, ook als de tool verdwijnt of duurder wordt.
2. Test nooit op de echte data. Maak een tweede database of omgeving waarin je nieuwe functies eerst uitprobeert.
3. Haal sleutels uit de code en de chat. Wachtwoorden en API-sleutels horen in een wachtwoordkluis. Staat een sleutel ooit in een chat of document, vervang hem dan.
4. Zet één keer een backup terug. Een backup die je nooit hebt teruggezet, is een aanname. Probeer het, en houd bij hoe lang het duurde.
5. Maak een lijst van wie toegang heeft. Tot de code, de database, de hosting en de beheeraccounts. Haal iedereen weg die er niet meer bij hoeft.

Hoe pakken wij dit aan?

Bij Squins volgen we drie fasen.

1. Inventarisatie

De eerste stap is kijken wat er al staat. Hoe is het gebouwd, waar draait het, welke data zit erin en wie kan erbij? Die laatste vraag levert vaak al verrassingen op: toegang is meestal minder goed geregeld dan gedacht. Daarna zetten we de risico’s op een rij en plannen we de verdere aanpak.

2. Fundering

Vervolgens bouwen we wat ontbreekt: gescheiden omgevingen, een pipeline, volledige migraties en geautomatiseerde tests. Dat kost tijd, maar het maakt van een prototype een bruikbare applicatie.

3. Blijvend betrokken

Ook als alles draait, blijven we betrokken. We signaleren risico’s voordat ze een probleem worden, bouwen koppelingen met externe applicaties en reviewen wijzigingen die kritische onderdelen raken. En we wijzen je op nieuwe mogelijkheden met AI, zodat je zo efficiënt mogelijk kan werken.

Herken je dit?

Staat er al een app die met AI gebouwd is? Dan kijken we graag met je mee wat er nodig is om hem van prototype naar bruikbare maatwerksoftware te tillen.

Sta je nog aan het begin? Schakel ons dan vanaf de start in. Jij blijft bouwen, wij leggen de fundering er gelijk onder, en zo sla je het dal grotendeels over.

Neem contact op of mail naar info@squins.com.