En waarom dat het probleem is dat we moeten begrijpen.

Twee mensen gebruiken dezelfde AI-tool op dezelfde hosting-omgeving. De een deployt zonder problemen, de ander loopt vast op handmatige workarounds en concludeert dat “de tooling dit niet ondersteunt.” Het verschil zit niet in technisch niveau, intelligentie of ervaring, want degene die vastliep had van alle drie meer.

Dit noem ik de expertise-paradox van vibe coding. Ik zie het inmiddels vaker om me heen, en volgens mij zit het anders in elkaar dan je zou denken.

Het experiment dat niemand opzette

Een collega van mij, een ervaren IT Architect, besloot een webapplicatie te bouwen met Claude Code en te deployen op een Nederlandse shared hosting-omgeving. Hij deed wat een goede architect doet en begon met een gedetailleerd specificatiedocument. Architectuurkeuzes, databasevoorkeur (PostgreSQL), mapstructuur en technische constraints stonden vast in een Markdown-bestand dat hij als startpunt aan het AI-model gaf.

Het resultaat was een set bestanden op het verkeerde niveau, een database-incompatibiliteit en een reeks handmatige acties om de boel werkend te krijgen. Zijn conclusie was dat de tooling tekortschiet.

Ik heb dezelfde hosting-omgeving voor meerdere projecten gebruikt, stapsgewijs en volledig AI-ondersteund, zonder noemenswaardige problemen. Mijn technische achtergrond is aanzienlijk minder diep dan de zijne.

Drie dingen die fout gingen (en waarom ze logisch waren)

1. De databasekeuze was een voorschrift, geen vraag.
De hosting-omgeving biedt MySQL op alle pakketten, geen PostgreSQL. Dat wist het AI-model niet, want in het specificatiedocument stond PostgreSQL als gegeven en niet als voorkeur. Het model deed braaf wat er gevraagd werd en bouwde een PostgreSQL-setup voor een omgeving die dat niet ondersteunt.

2. De deployment-omgeving was een afterthought.
Het specificatiedocument beschreef de applicatie uitgebreid, maar niet waar die moest draaien. Zonder die context genereert een AI-model een generieke projectstructuur, en die past niet bij hoe DirectAdmin, het controlepaneel van de hoster, bestanden verwacht. Daarom stonden de bestanden op het verkeerde niveau.

3. SSH-toegang was niet ingericht.
Zonder SSH-verbinding tussen de werkomgeving en de webserver kan Claude Code niet rechtstreeks deployen, en val je terug op handmatig bestanden kopiëren via SFTP. Op dat moment voelt het alsof de tooling het niet ondersteunt, terwijl er eigenlijk een verbinding ontbreekt en niet de capability.

De architect-reflex

Wat hier gebeurt is subtieler dan dat hij het fout deed. Mijn collega deed wat een goede architect doet: eerst denken, dan bouwen. Hij legde architectuurkeuzes vast, scheidde design van implementatie en maakte een blueprint vóór de bouw. Die jarenlange professionele discipline is in traditionele softwareontwikkeling een teken van kwaliteit.

In vibe coding wordt ze een keurslijf. Het model voert uit wat er staat in plaats van mee te denken over wat werkt. De feedbackloop, in de trant van “gebruik MySQL want dat biedt je hoster”, kan niet ontstaan als de databasekeuze al vastligt in een specificatiedocument.

Ik zie drie werkbare modi voor het gebruik van AI-code-tooling:

Modus 1: Doelgericht delegeren. Je beschrijft wat je wilt bereiken, inclusief de deployment-omgeving, en laat het model de technische keuzes maken. Je stuurt bij op resultaat en niet op implementatie. Zo werk ik zelf, en het is effectief juist omdat ik niet de neiging heb om technische keuzes te dicteren.

Modus 2: Expert met assistent. Je bent een ervaren developer die de stack, architectuur en tooling bepaalt en het model gebruikt als productieve codeer-assistent. Dit werkt ook, maar je moet dan alle downstream-implicaties van je keuzes overzien, deployment inbegrepen.

Modus 3: De hybride val. Je specificeert sommige technische keuzes zonder volledig te begrijpen wat de downstream-implicaties zijn, en zonder het model de ruimte te geven om die keuzes te challengen. Hier kwam mijn collega terecht, en deze modus levert volgens mij de meeste frustratie op.

De ene vraag die alles had veranderd

Mijn collega deed te veel voorwerk op de verkeerde laag, architectuur en databasekeuzes, en te weinig op de juiste laag: deployment-omgeving en toegang.

De vraag die zijn hele traject had veranderd was niet “welke database wil ik?” maar: “Wat biedt mijn doelomgeving, en hoe geef ik de AI-tool daar toegang toe?”

Dat is twee minuten research naar de hosting-specs en tien minuten SSH-configuratie, twaalf minuten die uren aan frustratie hadden voorkomen.

De vlucht naar voren

Het verhaal heeft nog een staartje. Na de frustraties met de shared hosting week mijn collega uit naar Vercel, een deployment-platform dat populair is onder developers. De applicatie draait, dus het probleem lijkt opgelost.

Maar kijk naar wat er feitelijk gebeurde. De oorspronkelijke hosting ondersteunde Node.js, Python, MySQL, SSH-toegang en meer, alles wat hij nodig had. Vercel biedt voor zijn use case geen extra functionaliteit en kost wel meer. Hij past nu de omgeving aan op zijn keuzes in plaats van zijn keuzes aan de omgeving.

Dat is de expertise-paradox in haar zuiverste vorm. Elke stap was rationeel: de specificatie leidde tot een bepaalde stack, de stack paste niet op de hosting, dus de hosting moest wijken. Het totaalplaatje is dat van iemand die steeds verder van de eenvoudigste oplossing af beweegt, door een opeenstapeling van keuzes die elk uit de vorige volgden en niet door gebrek aan kennis.

Wat dit betekent voor hoe we over AI-tooling denken

De gangbare aanname is dat technisch sterkere mensen meer uit AI-tooling halen. Dat klopt voor Modus 2. Voor Modus 1 is het volgens mij eerder andersom, en dat is de modus waarin de meeste mensen zitten die “vibe coden”. Technische expertise geeft de neiging om te specificeren waar je zou moeten delegeren.

Ik pleit hiermee niet tegen expertise. Effectief werken met AI-code-tooling vraagt een andere vaardigheid dan software bouwen, en het verschuift het moment waarop architectuurkennis nodig is: niet meer tijdens het coderen maar ervoor, bij het formuleren van de juiste constraints. De vraag wordt “waarbinnen moet het gebouwd worden” in plaats van “hoe moet het gebouwd worden.”

Dat lijkt een klein verschil, maar in de praktijk scheidt het een vlekkeloze deployment van de conclusie dat de tooling niet werkt.

Jan-Willem Rodenhuis is Managing Partner bij Ductus B.V. en schrijft over de praktijk van AI-ondersteund bouwen, financiële technologie en de raakvlakken daartussen.