Vibe Coders Aren't Doomed. Engineers Aren't Being Replaced.

There are two stories doing the rounds right now, and I think both are wrong.

The first says vibe coders are doomed. People with no engineering background are building things with AI, and the story goes that it will all end in tears: security holes, unmaintainable code, a pile of prototypes nobody can support.

The second says engineers are being replaced. If a domain expert can describe what they want and an AI writes it, why pay for an engineer at all?

Both stories assume the same thing. They assume the old model, where one person writes the code and owns it end to end, is the only model. It isn't. What I'm seeing in practice is a different shape of work, and it suits both groups.

The new shape

The engineer sets up the environment and the workflow. That means the repo, the hosting, the deploy path, the guard rails, the checks that run without anyone thinking about them. It means deciding what can go wrong, how badly, and what has to happen before anything goes live.

The builders get the tools and a long lead. A builder is someone who knows the domain: the business, the customers, the content, the purpose of the thing. They work with an AI assistant like Claude to build what they need. They don't need permission for every change, and they don't need to understand every line. They need a safe place to work and someone who has their back.

Oversight scales with risk and complexity. A copy change on a marketing page doesn't need the same scrutiny as a change to how data is handled. The engineer decides where the line sits, and the line moves depending on what's at stake.

Quality is watched in the background, or when it's needed, rather than as a gate on every keystroke: automated checks, review when something looks off, a closer look when the work touches something sensitive.

And the engineer steps in to enable, or to sort out the complex problems. When the builder hits something the AI can't untangle, or something that needs real judgement about architecture, security or operations, that's where engineering earns its keep.

It's a risk driven approach. The builder moves fast where speed is safe. The engineer spends their time where it actually matters.

Three places I'm running it

This website. The Pairti website is built with an AI assistant, and I sit over the top of it. The assistant drafts, edits and builds. I set up how it works: where changes go, how they get reviewed, how they get deployed, and what it's never allowed to touch. Most of the time I'm not in the detail. When something matters, I am.

The SAVA-P website. On SAVA-P, Anna works with Claude directly. She knows the subject and the audience far better than I do, so she leads. My job is to make sure the environment is sound, that what goes live is safe, and that nothing is quietly going wrong underneath. She gets a long lead. I keep an eye on quality and step in when it's needed.

The Kokoro Collective website. Kokoro Collective, which I co-founded, runs the same model. Leis and I build there together with AI, and I look after the foundations and the risk.

These are small sites so far, and none of them needed a team of developers.

I'll know it when I see it

Most people can't fully describe what they want until they see it. That has always been the hard part of software. Specs get argued over, opinions pile up, and nobody really knows until something exists.

Working with an agent changes that. You build the thing, look at it, and react. A rough version on screen often settles what meetings couldn't.

It's also a safe place to think. There's no one in the room with a position to defend, so you can try an idea without running into opinions first. The model's habit of agreeing with you sounds like a flaw, and in a review it would be. Here it helps. It lets you build the bad idea, and then you see for yourself that it's bad. That only works if you look at it honestly, and it's one more reason to show the result to someone else before it goes live. You argue less and decide on what you've seen.

That's where the engineer still matters. Building your way to an answer is safe when the environment around it is sound.

Why vibe coders aren't doomed

The criticism of vibe coding is mostly a criticism of vibe coding with nobody watching. Someone builds a thing, ships it straight to the world, and has no idea what's in it. That can go badly. But the fix isn't to tell domain experts to stop building. It's to give them an environment where the obvious mistakes are hard to make and the serious ones are far more likely to get caught.

A builder with a good environment and an engineer in the background is in a very different position from a builder on their own. They can move quickly on the parts they understand, because they understand the domain.

The people who know what the thing should do are finally able to build it. That's a good thing. It just needs a structure around it.

Why engineers aren't being replaced

The engineering job doesn't go away. It moves.

Less time writing routine code. More time on the environment, the workflow, the risk model, the deploy path, the review rules, and the hard problems that land on the desk when the builder and the AI get stuck. That's still engineering. Arguably it's the part of engineering that always mattered most, and it's the part that's hardest to automate, because it's about judgement and accountability.

In over 30 years of delivery, the projects that went well weren't the ones with the most code written. They were the ones where someone had thought about how the work would run, what could go wrong, and who would catch it.

The tool changed. Running the work properly is still the job.

What it takes to get right

If you want to run work this way, a few things have to be true.

Someone has to own the environment. In practice. Where does code live, how does it get deployed, what's off limits.

The risk has to be understood. What's the worst thing that could happen on this system, and how much oversight does that justify?

The builders need real room. If every change needs sign off, you've just rebuilt the old bottleneck.

And there has to be a clear way to call for help. The builder needs to know when to stop and bring in the engineer, and the engineer needs to be available when they do.

Get those right and you get the speed of people building their own tools, with the safety of someone who knows what they're doing keeping watch.