Van Weekendproject naar Software Die Je Echt kunt Vertrouwen

Vorige week liet een founder me een werkende webapp zien die ze in één weekend had gebouwd met AI coding tools. Geen informaticadiploma, geen bootcamp — gewoon een duidelijk idee en een goede prompt. Eerlijk? Best indrukwekkend. Login-systeem, een dashboard, data die bleef opslaan. Allemaal binnen 72 uur.

Tot ze vroeg of ik kon helpen om het naar échte gebruikers te krijgen.

Daar werd het spannend.

Het prototype werkte omdat zij de enige gebruiker was. Zodra we een tweede persoon probeerden toe te voegen, kwamen er concurrency bugs om de hoek kijken. De database had geen schema migrations, dus bij een rollback zouden gegevens verloren gaan. Er waren geen tests, wat betekende dat elke refactor voelde als een bom ontmantelen terwijl je geblinddoekt bent. En de deployment was een handmatig proces met nul documentatie.

Haar weekendproject was een prima proof of concept. Het was geen productierijpe software.

Dit is het gat waar het "vibe coding" gesprek telkens overheen kijkt. De tools zijn er, de snelheid is er, en de democratisering van softwareontwikkeling is oprecht enthousmerast. Maar er is een verschil tussen code genereren en software engineeren. En dat verschil doet er meer toe dan de meeste mensen beseffen — tot ze om 3 uur 's nachts in een incident zitten.

De Metric Die Echt Telt

Dit is de vraag die ik blijf stellen bij AI-gegenereerde code: kan dit veilig worden gemerged in een gedeelde codebase?

Niet "draait het." Niet "werkte de demo." Veilig mergen. Dat woord "veilig" weegt zwaar. Het betekent dat de code reviewed kan worden door iemand die het niet geschreven heeft. Het betekent dat tests gedrag verifiëren, niet alleen dat de code niet crasht. Het betekent dat rollback mogelijk is zonder dataverlies. Het betekent dat de change smal genoeg is om te begrijpen en uit te leggen.

Wanneer een vibe coder succes meet, meten ze meestal de tijd tot de eerste werkende versie. Dat is een nuttige metric voor discovery en prototyping. Maar zodra software in een gedeelde omgeving komt, houdt die metric op nuttig te zijn. Nu meet je tijd tot veilig merge, en dat включает review kosten, test kwaliteit, deployment risico, coördinatie overhead, en toekomstige onderhoudslast.

Een software engineer denkt aan die hele lifecycle vanaf het begin. Een vibe coder ontdekt deze zorgen vaak later, wanneer ze duurder zijn om aan te pakken.

Code Genereren vs. Code Ownership

Er is een subtiele maar cruciale verschuiving die plaatsvindt wanneer AI jouw code genereert. De output is nog niet jouw werk. Het is een startpunt dat getransformeerd moet worden naar iets dat je werkelijk bezit.

Ownership betekent een paar dingen. Je kunt elke betekenisvolle beslissing in de change uitleggen. Je begrijpt waarom elk bestand bestaat en wat het doet. Je hebt de change beperkt tot precies wat nodig was, zonder extra boilerplate of ongerelateerde cleanup. Je hebt tests geschreven of geverifieerd die gedrag controleren, niet alleen coverage metrics. Je hebt nagedacht over het rollback pad.

Dit is het werk dat AI niet voor je kan doen. AI genereert. Jij beslist. En "beslissen" impliceert dat je over alternatieven hebt nagedacht, tradeoffs hebt afgewogen, en de consequenties begrijpt.

Wanneer ik AI-gegenereerde code zie die niet goed owned is, zie ik vaak dezelfde problemen. Changes die te groot zijn omdat het model meer genereerde dan nodig. Packages toegevoegd zonder duidelijke onderbouwing. Tests die lijken te zijn geschreven om een coverage tool tevreden te stellen in plaats van echte bugs te vangen. Boilerplate die er staat omdat het model default naar scaffolding in plaats van eenvoud.

Geen van deze zijn AI's schuld. Ze zijn het resultaat van een auteur die gegenereerde output als vooruitgang behandelde in plaats van als ruw materiaal.

Het Review Probleem Waar Niemand Het Over Heeft

Iets wat mij 's nachts bezighoudt: AI-gegenereerde code verandert de review vergelijking.

Wanneer een menselijke engineer code schrijft, is er meestal een decision trail. Je kunt het oneens zijn met hun keuzes, maar er zijn in ieder geval keuzes. Je kunt vragen waarom ze die abstractie gebruikten, waarom de validatie daar zit, waarom ze die library kozen. De antwoorden kunnen "daar heb ik niet over nagedacht" of "leek destijds redelijk" zijn, maar er is in ieder geval iemand om te vragen.

Met AI-gegenereerde code zijn sommige van die "beslissingen" helemaal geen beslissingen. Het zijn completions. Het model koos een patroon omdat het statistisch waarschijnlijk was, niet omdat het de juiste fit was voor jouw probleem. En als de auteur die completion niet heeft omgezet naar owned werk, wordt de review een stuk lastiger.

Je kunt het model niet vragen waarom het voor die aanpak koos. Je kunt de auteur niet vragen waarom ze die beslissing maakten als ze het eigenlijk niet weten. Dus de review komt ofwel issues aan het licht via pijnlijke trial and error, of het gebeurt helemaal niet.

Dit is waarom ik geloof dat de belangrijkste skill in het AI-assisted development tijdperk niet prompting is. Het is het vermogen om gegenereerde output te nemen en om te zetten naar code die je diep genoeg begrijpt om te ownen, uit te leggen, en te onderhouden.

Wat Dit Betekent Voor Je Team

Als je een prototype bouwt om een idee te testen, is vibe coding een legitieme aanpak. Snelheid van leren matters wanneer je nog assumptions aan het valideren bent. Gebruik de tools, beweeg snel, en bouw iets om aan mensen te laten zien.

Maar als dat prototype een echt product wordt, moet de gegenereerde code op een gegeven moment door de filter van iemand die als een engineer denkt. Niet om te gatekeeppen. Niet om dingen te vertragen. Maar om te zorgen dat wat je shipped wordt code is die begrepen, onderhouden, en vertrouwd kan worden door een team.

Bij NameOcean zien we dit patroon de hele tijd. Startups die snel bewegen met AI tools om hun ideeën te valideren, en dan tegen een muur aanlopen wanneer ze moeten opschalen. De goede ones halen op dat moment engineering hulp in. De slechte ones blijven features stapelen op een codebase die niemand werkelijk begrijpt.

Het doel is niet om AI-assisted development te vermijden. Het doel is om eerlijk te zijn over waar het werk begint en waar het eindigt. AI kan code genereren. Jij moet software engineeren.

De Conclusie

Vibe coding is een fantastisch startpunt. Het is een manier om ideeën snel te testen, te leren wat mogelijk is, en van concept naar iets tastbaars te gaan zonder maanden traditionele ontwikkeling.

Maar software engineering gaat over de volledige lifecycle. Het gaat over code die je team kan reviewen, onderhouden, en vertrouwen wanneer dingen misgaan om 2 uur 's nachts. Het gaat over changes die smal genoeg zijn om te begrijpen en te rollbacks als dat nodig is. Het gaat over verantwoordelijkheid nemen voor beslissingen, zelfs wanneer die beslissingen beïnvloed zijn door AI suggesties.

De beste developers die ik ken gebruiken AI tools volop. Ze doen het alleen met hun ogen open. Ze weten dat gegenereerde code ruw materiaal is, geen afgewerkt product. En ze weten dat op een gegeven moment iemand het engineering werk moet doen dat het verschil maakt tussen een coole demo en software die je werkelijk kunt shippen.

Dus vibe code gerust. Bouw snel, experimenteer vrij, en gebruik elk beschikbaar gereedschap. Maar weet wanneer het tijd is om te schakelen van vibe naar engineering. Je toekomstige zelf, en je toekomstige team, zullen je dankbaar zijn.