Vibecoden naar productie

Menig ontwikkelaar heeft de laatste tijd te maken gehad met vibecoders. Product mensen of business stakeholders die maar roepen dat je het gewoon ff moet vibecoden, of, erger nog, hun slop aanleveren bij jou met de vraag ‘of je het ff live kan zetten’.

Je verwacht nu dat ik een heel betoog ga houden over waarom dit een slechte ontwikkeling is. Helaas. Ik zeg: laten we deze mensen juist omarmen.

Vibecoded-spaghetti-slop-code

In veel bedrijven worden programmeurs gezien als tovenaars. Niemand weet precies wat ze doen. Zij hebben daarentegen wel alle macht, want zij bepalen uiteindelijk hoe het eindproduct werkt. Regelmatig heb ik in mijn beginjaren gewoon de UX slechter gemaakt omdat ik niet goed wist hoe ik het netjes in code kon doen. Ik had de macht om te bepalen wat er uiteindelijk geshipped werd. ‘Nee, sorry. Dit is zo niet mogelijk, dus heb ik het zo gedaan.’

Die macht brokkelt nu langzaam af. Doordat business lui aan het vibecoden zijn, weten ze nu wel degelijk dat er shit mogelijk is waarop voorheen altijd werd teruggeduwd door ontwikkelaars. Als Henk van de marketing aankomt met een werkende feature, kan jij moeilijk zeggen dat het niet kan.

Als UX engineer vind ik dit prachtig. Maar, de ontwikkelaars hebben wel het recht om terug te duwen. Zij zijn eindverantwoordelijk, en als je zomaar vibecoded-spaghetti-slop-code gaat toestaan, ontstaan er in no time problemen. En wie gaan ze ’s avonds appen als de site platligt door de nieuwe slop feature van Henk? Juist, dan ben jij de lul.

Maar wat mij betreft is het tijd om de rollen om te draaien. Henk weet namelijk veel beter wat er gemaakt moet worden. Het is tijd dat ontwikkelaars eens naar hem gaan luisteren.

Promotie

Elke ontwikkelaar is door AI gepromoveerd tot een senior die continu code krijgt aangeleverd van junioren (aka de agents). Wat mij betreft is de taak van een ontwikkelaar anno 2026: Hoe zorg je ervoor dat je dit goed en veilig kan uitrollen?

Allereerst denk ik dat er wel een mindset switch nodig is binnen je bedrijf. Als we toestaan dat we de features van Henk gaan uitrollen naar productie, dan ga je hoe dan ook inleveren op stabiliteit (voor nu). Het is een trade-off: je gaat akkoord met een snellere verificatie loop van features, en daarmee ook dat er af en toe fouten in zitten of dingen brak werken.

Dit is ook de strategie die de AI labs zelf toepassen. Ik maak dagelijks gebruik van Codex en Claude Code. Aan alles merk je dat deze partijen hard aan het vibecoden zijn. Hun workflows zijn helemaal gefocust op 1 ding: snel nieuwe features shippen en valideren. Om problemen tegen te gaan hebben ze daarom de doorlooptijd van het uitrollen van nieuwe updates zo kort mogelijk gemaakt. Er breekt regelmatig iets, maar doordat ze continu updates pushen zijn dingen heel snel weer gefixt. Dit is waarom je bijna dagelijks een update knopje te zien krijgt bij Claude of Codex. Soms zelfs meerdere keren per dag.

De codebase van Claude Code is wel eens uitgelekt, en veel senior ontwikkelaars zeiden toen dat de code niet erg goed was. Maar ja, moederbedrijf Anthropic is afgelopen week gewaardeerd op bijna 1 biljoen dollar. Je kunt je afvragen of het dan uitmaakt dat je codebase niet zo netjes is.

Ik ben groot voorstander van deze strategie. Zo snel mogelijk een werkbare versie releasen en laten testen door je doelgroep, en dan super snel verbeteringen doorvoeren, of zelfs de hele feature er weer uit slopen en doorgaan met de volgende feature die je wilt valideren.

Ik las eens op X over een bedrijf dat tijdens een product meeting in de ochtend iets had bedacht, het voor de lunch had uitgerold, en tegen het einde van de middag alweer had gevalideerd en teruggetrokken. Dit kan nu.

Krijgt Henk dan vrijspel?

Nee. Wat je wilt is een omgeving creëren waarin Henk veilig kan vibecoden. Je wilt kaders neerzetten die ervoor zorgen dat bepaalde dingen gewoon nooit fout kúnnen gaan.

Ik doe dit voornamelijk door de belangrijkste componenten zelf op te zetten, en zo in te richten dat ik tijdens een code review heel makkelijk kan zien of dit goed geïmplementeerd is. Je wilt het zo opzetten dat agents eigenlijk geen fouten kunnen maken. Vervolgens heb ik een aantal zelfgemaakte ‘Skills’ die de AI agents hierop controleren en ze verplichten volgens dit stramien te werken. Aan het einde gaat er nog een code review agent overheen die de feature valideert en alles nog eens naloopt.

Voordat een pull request bij ons als mens komt, zijn er dus al meerdere AI prompts overheen gegaan die de slop minimaliseren en veelgemaakte fouten eruit halen. Op die manier wordt reviewen meer een taak van: is dit veilig te shippen, zijn de basics qua security en kwaliteit op orde, en maken we hier keuzes waar we later makkelijk op door kunnen itereren, of snel kunnen terugdraaien.

Dit is niet feilloos. Sommige dingen blijven coding agents fout doen. Ze zijn gewoon niet deterministisch. In het begin ga je heel vaak het idee hebben dat je whack-a-mole aan het spelen bent.

Accepteer dit. Je hebt namelijk de wind mee. Elke maand komt er weer een beter model uit. Sure, de token prijzen gaan een keer omhoog maar voorlopig is er nog genoeg VC-geld dat dit voor je subsidieert. Leer samenwerken met de modellen. Zo weet je snel genoeg waar de flaws zitten, en waar je moet kijken tijdens het reviewen.

Een ding is namelijk zeker: deze modellen gaan niet meer slechter worden. Zelfs als de helft maar waar is van wat al deze AI labs ons beloven, is dit nog steeds een radicale verandering in hoe software ontwikkelaars te werk gaan.

Programmeurs verliezen hun macht, en dat is goed nieuws voor eindgebruikers.