Don't retire vibe coding. Retire shipping it.

There's a claim making the rounds: the models now produce better architecture and more coherent code than the average software engineer, maybe better than top engineers too, because AI has a much larger context window. So, the argument goes, we should retire the term "vibe coding." This ain't vibe coding at all. It's precision engineering.

The models really have gotten better. That part is true. The conclusion is still wrong, because it confuses the tool's capability with the human's working mode. Vibe coding was never a claim about how good the model is. It describes how much the human cares about the implementation. A better model doesn't retire that mode. It makes the mode more dangerous, because the output now looks engineered even when nobody engineered it.

So no, don't retire the term. Sharpen it. We need two words, because there are two genuinely different activities, and mixing them up is how prototypes end up in production with no auth on the admin panel.

Vibe coding: the human opts out of the details

Vibe coding is when you give an AI vague instructions to test an idea or a hypothesis for an application or a feature, or to knock together a personal productivity tool. You don't care about the details of implementation, and you don't care about the key factors: security, maintainability, robustness, availability. You're not planning to push this code into production for thousands or millions of users, so those factors genuinely don't matter yet.

That's not a slur. It's a legitimate, useful mode. Testing whether an idea works before investing in it is good engineering judgment. The throwaway script that saves you an afternoon is a win. Vibe coding only becomes a problem when the code quietly changes jobs, from experiment to product, without anyone changing how it was built.

Agentic engineering: the human stays in the loop

Agentic engineering is the other activity. A software engineer works closely with an AI coding agent to produce a very specific implementation of a piece of software. The design, the specs, and the constraints are either provided in detail up front or worked out iteratively with the agent. The engineer reviews what comes back the way they'd review a colleague's pull request, because the result is intended to be pushed into production.

Same models. Same tools, often. Completely different discipline. In one mode the human has delegated the thinking. In the other the human has delegated the typing.

The one question that separates them

You don't need a framework to tell which mode you're in. Ask one question: is this going in front of users who depend on it?

If the honest answer is no, vibe away. Speed is the point, rigor is waste.

If the answer is yes, or "probably, eventually," you're doing engineering whether you call it that or not, and the bill for skipping the boring parts arrives in week one. We keep a running file of launches that learned this in public. The pattern is never "the model wrote bad code." The pattern is "nobody checked the code the model wrote," because checking wasn't part of the mode they were in.

Some quicker tells:

• Specs: vibe coding starts with a sentence. Agentic engineering starts with constraints: stack, data model, threat surface, what "done" means.
• Review: vibe coding ends when it runs. Agentic engineering ends when someone with scars has read the diff and tried to break it.
• Context: vibe coding hopes the model guesses your conventions. Agentic engineering writes them down, in context files the agent actually reads, before the first prompt.
• Ownership: in vibe coding, a bug is the model's fault. In agentic engineering, the agent has no production access and no on-call rota. You do.

But the context window, though

The strongest version of the "retire the term" argument is the context window: the model can hold the whole codebase in mind at once, no human can, so the model's architecture must be better. There's a real advantage buried in there. Agents do catch cross-file inconsistencies a tired human would miss.

But context is not judgment. The model doesn't know which of your users is a hospital. It doesn't know your threat model, your compliance obligations, or which shortcut becomes a 2 AM incident in your specific system. It holds more of the code in memory and less of the situation in mind, because the situation was never in the training data. That's exactly the gap the engineer is for. A larger context window raises the ceiling of what the agent can do; it doesn't transfer ownership of the outcome.

And here's the uncomfortable flip side: as models improve, the vibe-coded output gets prettier, the architecture diagrams look sensible, the naming is clean, and the missing rate limit, the absent transaction, the unindexed query get harder to spot. Better models don't end vibe coding. They disguise it.

Keep both words

Words are tools, and this one earns its keep as a warning label. "Vibe coded" on a prototype means: fast, unverified, don't build on this yet. That's honest and useful. The failure isn't the label, it's shipping the thing the label describes and calling the launch "precision engineering" because the code looked clean.

So keep vibe coding for what it is: exploration at machine speed, details deliberately ignored. And use agentic engineering for the work where the details are the job, where a human specifies, supervises, reviews, and owns what ships.

Vibe the prototype. Engineer the product. Use AI for both. Just don't ship slop.