En waarom dat precies het probleem is dat we moeten begrijpen.

Twee mensen. Dezelfde AI-tool. 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? Niet technisch niveau. Niet intelligentie. Niet ervaring. Sterker nog: degene die vastliep had meer van alle drie.

Welkom bij de expertise-paradox van vibe coding. Ik zie het inmiddels vaker om me heen — en het zit 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 iedere goede architect doet: hij begon met een gedetailleerd specificatiedocument. Architectuurkeuzes, databasevoorkeur (PostgreSQL), mapstructuur, technische constraints — allemaal vastgelegd in een Markdown-bestand dat hij als startpunt aan het AI-model voerde.

Het resultaat? Bestanden op het verkeerde niveau. Database-incompatibiliteit. Een reeks handmatige acties om de boel werkend te krijgen. Zijn conclusie: de tooling schiet tekort.

Ik heb dezelfde hosting-omgeving gebruikt voor meerdere projecten. Stapsgewijs, volledig AI-ondersteund, zonder noemenswaardige problemen. Mijn technische achtergrond? 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. Maar dat wist het AI-model niet, want het had een specificatiedocument gekregen waarin PostgreSQL als gegeven stond — niet als voorkeur. Het model deed braaf wat er gevraagd werd: een PostgreSQL-setup bouwen 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. Die matcht niet met hoe DirectAdmin — het controlepaneel van de hoster — bestanden verwacht. Vandaar: bestanden op het verkeerde niveau.

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

De architect-reflex

Wat hier gebeurt is subtieler dan “hij deed het fout.” Mijn collega deed wat iedere goede architect doet: eerst denken, dan bouwen. Architectuurkeuzes vastleggen. Design scheiden van implementatie. Een blueprint maken vóór de bouw. Jarenlange professionele discipline die in traditionele softwareontwikkeling een teken van kwaliteit is.

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

Ik zie hier 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, niet op implementatie. Dit is hoe ik werk, 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 vereist dat je alle downstream-implicaties van je keuzes overziet — inclusief deployment.

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. Dit is waar mijn collega terechtkwam, en het is de modus die de meeste frustratie oplevert.

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 ene 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 is mijn collega uiteindelijk uitgeweken naar Vercel — een gespecialiseerd deployment-platform dat populair is onder developers. De applicatie draait. Probleem opgelost, zou je zeggen.

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, maar kost wel meer. Hij past nu de omgeving aan op zijn keuzes, in plaats van zijn keuzes aan te passen aan de omgeving.

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

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. Maar voor Modus 1 — en dat is waar de meeste mensen die “vibe coden” zich bevinden — is het eerder andersom. Technische expertise creëert de neiging om te specificeren waar je zou moeten delegeren.

Dit is geen pleidooi tegen expertise. Het is een observatie dat effectief werken met AI-code-tooling een andere vaardigheid vereist dan software bouwen. Het verschuift het moment waarop architectuurkennis nodig is: niet meer tijdens het coderen, maar ervóór — bij het formuleren van de juiste constraints. Niet “hoe moet het gebouwd worden” maar “waarbinnen moet het gebouwd worden.”

Dat klinkt als een klein verschil. In de praktijk is het het verschil tussen een vlekkeloze deployment en 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.