Vibecoding is not AI-assisted development

I have been programming for forty years. I do not write code anymore.

That sentence makes people assume I have retired from the craft. I have not. What I still have is the part that took forty years to build: an understanding of how computers actually work — programming, security, operating systems, networking, hardware. The code was never the point. The code was the medium. Today my medium is a prompt, and the understanding underneath it has not changed at all.

Which is why the current fashion of labelling every developer who uses AI a vibecoder is worth pushing back on. It collapses two completely different activities into one word.

Three eras of the same job

In the first era you wrote everything. Every file, every function, every constructor, every accessor. You typed all of it. Writing was slow, and debugging was slower — you read the code until you found the fault, or you added print statements until the machine told you where it hurt.

Then came the IDE, and things went considerably faster: completion, refactoring, jump-to-definition, a real debugger with breakpoints and a watch window. But note what actually changed. You still wrote most of the code yourself. The IDE removed friction from typing and made finding bugs tractable. It did not remove the requirement that you knew what you were building.

Now we have Claude Code, Lovable and the rest. Anyone can build an app. You describe something and working software appears. It looks good — genuinely good, better than most of us produced by hand on a first pass. Everyone feels like a developer.

Each era removed a layer of manual labour. Not one of them removed the understanding. That is the part being misread right now.

What vibecoding actually ships

The programs are terrible.

Not terrible on the screen. They demo beautifully. They are terrible underneath: no data model worth the name, authentication bolted on afterwards, secrets sitting in the client bundle, no error handling on the paths that matter, state scattered across five components that each believe they own it, and a dependency tree nobody has ever looked at. It works until it meets a real user, a real load, or a real attacker.

This is not a criticism of the tools. The tools did exactly what they were asked to do. That is precisely the problem — they were asked badly.

The difference is the specification

Here is the actual dividing line, and it has nothing to do with whether you type the code.

A vibecoder says: "add a button."

A developer says: which view, where in the layout, what does it read from, what does it write to, what does it show while it waits, what happens when the call fails, who is allowed to click it, what happens when someone clicks it twice, and what does it look like when the list behind it is empty.

Same tool. Same model. Two entirely different outputs — because in the first case the AI has to guess, and a guessing model returns the statistical average of everything it has ever seen.

Generic code. And generic code is exactly the code that does not fit your system, does not respect your invariants, and quietly becomes the incident you are debugging three weeks from now.

What the old habits were actually training

The developer who spent years in emacs or vim writing every line by hand is not valuable because of the typing. That person is valuable because they know what has to be specified. They know the failure modes are the design. They know what the machine is doing underneath — that a request crosses a network, that a network is unreliable, that memory is finite, that a process can be killed mid-write, that anything reaching the client is public.

You cannot prompt your way to that. You can only prompt from it.

Why the label is backwards

Calling every AI-using developer a vibecoder is not merely imprecise, it is inverted. The engineers getting the most out of these tools are almost always the ones with the deepest pre-AI experience. They direct rather than ask. They read what comes back. They recognise the answer that is plausible but wrong — which is the single most important skill of this era, because a language model's confidence is uncorrelated with its correctness.

The actual vibecoder cannot review the output, because reviewing requires the knowledge that generating was supposed to replace. They ship what compiles and looks right. It is not laziness — it is a missing feedback loop. Nothing ever tells them the code is bad until production does.

In fairness to vibecoding

It has a legitimate place. Prototypes, internal tools, one-off scripts, proving out an idea before committing budget to it, and letting people who are not programmers build the small thing they need instead of waiting six months in someone's queue. That is real value and I have no interest in gatekeeping it.

The failure is one of category, not of tooling: taking something built with no specification and no review, and putting it in front of customers, on the internet, holding other people's data.

What AI-assisted development actually looks like

• Architecture stated up front. The shape of the thing is decided before any code exists, by someone who has built one before.
• Explicit constraints. This language, this framework version, this pattern, these boundaries, this is where that lives. Every constraint you leave unstated is a coin flip you have delegated.
• Small steps, each one reviewed. Read the diff, not just the result. The result always looks fine.
• Rejecting output that works but is wrong for the system. This is the hardest one, because working code is very persuasive.
• The security model decided before the feature exists, not after the pentest.
• Owning the outcome, because the tool does not and cannot.

It is the same engineering judgement it always was, applied one level up.

The question people keep asking

The industry keeps asking whether AI will replace developers. Wrong question. It has already replaced typing, the same way the IDE replaced looking things up in a manual. What it has not replaced — what it has in fact made considerably more valuable, because there is now so much more code to be wrong about — is knowing what you are building and why.

Forty years in, I do not write code anymore.

I still build software.