And why that is the problem we need to understand.

Two people use the same AI tool on the same hosting environment. One deploys without problems, the other gets stuck on manual workarounds and concludes that “the tooling doesn’t support this.” The difference is not in technical level, intelligence or experience, because the one who got stuck had more of all three.

I call this the expertise paradox of vibe coding. I now see it more often around me, and I think it works differently from what you would expect.

The experiment nobody set up

A colleague of mine, an experienced IT architect, decided to build a web application with Claude Code and deploy it on a Dutch shared hosting environment. He did what a good architect does and started with a detailed specification document. Architecture choices, database preference (PostgreSQL), folder structure and technical constraints were fixed in a Markdown file that he gave the AI model as a starting point.

The result was a set of files at the wrong level, a database incompatibility and a series of manual actions to get everything working. His conclusion was that the tooling falls short.

I have used the same hosting environment for several projects, step by step and fully AI-assisted, without any notable problems. My technical background is considerably less deep than his.

Three things that went wrong (and why they made sense)

1. The database choice was an instruction, not a question.
The hosting environment offers MySQL on all packages, not PostgreSQL. The AI model did not know that, because the specification document gave PostgreSQL as a given and not as a preference. The model dutifully did what was asked and built a PostgreSQL setup for an environment that does not support it.

2. The deployment environment was an afterthought.
The specification document described the application at length, but not where it had to run. Without that context an AI model generates a generic project structure, and that does not fit how DirectAdmin, the host’s control panel, expects files. That is why the files ended up at the wrong level.

3. SSH access had not been set up.
Without an SSH connection between the working environment and the web server, Claude Code cannot deploy directly, and you fall back on copying files by hand over SFTP. At that point it feels as if the tooling does not support it, while in fact it is a connection that is missing, not the capability.

The architect reflex

What happens here is subtler than a simple mistake on his part. My colleague did what a good architect does: think first, then build. He fixed architecture choices, separated design from implementation and made a blueprint before the build. Years of professional discipline like that are a sign of quality in traditional software development.

In vibe coding it becomes a straitjacket. The model carries out what is written instead of thinking along on what works. The feedback loop, along the lines of “use MySQL because that is what your host offers”, cannot arise when the database choice is already fixed in a specification document.

I see three workable modes for using AI code tooling:

Mode 1: Delegating towards a goal. You describe what you want to achieve, including the deployment environment, and let the model make the technical choices. You steer on the result and not on the implementation. That is how I work myself, and it is effective precisely because I am not inclined to dictate technical choices.

Mode 2: Expert with assistant. You are an experienced developer who decides the stack, architecture and tooling and uses the model as a productive coding assistant. This works too, but then you have to oversee all the downstream implications of your choices, deployment included.

Mode 3: The hybrid trap. You specify some technical choices without fully understanding the downstream implications, and without giving the model room to challenge those choices. This is where my colleague ended up, and I think this mode produces the most frustration.

The one question that would have changed everything

My colleague did too much preparation on the wrong layer, architecture and database choices, and too little on the right one: deployment environment and access.

The question that would have changed his whole trajectory was not “which database do I want?” but: “What does my target environment offer, and how do I give the AI tool access to it?”

That is two minutes of research into the hosting specs and ten minutes of SSH configuration, twelve minutes that would have prevented hours of frustration.

Doubling down

The story has a postscript. After the frustrations with the shared hosting, my colleague moved to Vercel, a deployment platform that is popular among developers. The application runs, so the problem seems solved.

But look at what actually happened. The original hosting supported Node.js, Python, MySQL, SSH access and more, everything he needed. For his use case Vercel offers no extra functionality and does cost more. He is now adapting the environment to his choices instead of adapting his choices to the environment.

That is the expertise paradox in its purest form. Every step was rational: the specification led to a certain stack, the stack did not fit the hosting, so the hosting had to go. The overall picture is of someone moving further and further from the simplest solution, through an accumulation of choices that each followed from the previous one, and not through a lack of knowledge.

What this means for how we think about AI tooling

The common assumption is that technically stronger people get more out of AI tooling. That holds for Mode 2. For Mode 1 I think it is rather the other way round, and that is the mode most people who “vibe code” are in. Technical expertise makes you inclined to specify where you should delegate.

I am not arguing against expertise. Working effectively with AI code tooling takes a different skill from building software, and it shifts the moment at which architectural knowledge is needed: no longer during coding but before it, when formulating the right constraints. The question becomes “what must it be built within” instead of “how must it be built.”

That seems a small difference, but in practice it separates a flawless deployment from the conclusion that the tooling does not work.

Jan-Willem Rodenhuis is Managing Partner at Ductus B.V. and writes about the practice of AI-assisted building, financial technology and where the two meet.