Why I've Stopped Calling It Vibe Coding

The creator of Claude Code is sick of the phrase "vibe coding." Boris Cherny said so publicly in May 2026, calling it dismissive and inaccurate. His preferred term: "intent-driven development."

He's right. And I think the terminology fight reveals something real about what's actually changing in how software gets built — and what it means for developers who want to build AI agents that actually work in production.

The Problem With "Vibe"

When you call something "vibe coding," you're implying a certain recklessness. You're winging it. You're not really in control. And honestly, for a lot of how people use AI tools right now, that's accurate.

But it's accurate in the same way that calling a car "a motorized horse carriage" was accurate in 1905. It's describing the new thing through the frame of the old mental model.

The developers who are actually shipping production AI systems aren't vibing. They're doing something more structured, and the word "vibe" makes it harder to talk about seriously.

Boris Cherny's framing is better: you provide intent, the AI handles implementation. The developer's job shifts upward — from writing functions to designing systems, specifying constraints, reviewing architectural decisions.

That's not vibing. That's a different kind of engineering.

What "Intent-Driven" Actually Looks Like in Practice

Here's where it gets concrete. Simon Willison wrote something in May 2026 that stuck with me. He admitted he's been treating Claude Code as a "semi-black box" — asking it to build JSON API endpoints with SQL and tests, and not reviewing every line of code.

He called this a "normalization of deviance." Every time the AI succeeds without close oversight, you trust it a little more. Until you've drifted so far from careful review that when something goes wrong, you can't tell where.

This is the real challenge of intent-driven development: you move fast, but you have to build new habits around what you do review, and what you let the AI own.

The developers figuring this out on Hacker News in 2026 are shipping four features simultaneously across multiple projects because fixing issues is "basically free if you pay for tokens." Test coverage is hitting 70–90% because generating tests is cheap. But none of that works if you've completely lost track of what the system is doing.

The Trust Calibration Problem

The people getting this wrong are treating intent-driven development like they used to treat a junior developer: hand them a task, check back in a week. The people getting it right are treating it more like air traffic control: high automation, but structured checkpoints, clear handoffs, and explicit rules about what the agent is allowed to touch.

One developer on HN shared a workflow that captures this well. When a bug appears, they don't just paste it into Claude Code and say "fix this." They:

1. Dogfood the bug first — understand it in their own words
2. Ask Claude Code to identify three potential root causes
3. Take those root causes to a Claude Project that holds architecture docs, and evaluate which fits the system's design
4. Write a detailed task spec from that evaluation
5. Give the spec back to Claude Code for implementation

The AI does the implementation work. But the developer controls the diagnosis and the spec. That's where the intent lives.

Why This Matters If You're Building AI Agents

If you're trying to build AI agent systems in Next.js or any other stack, the distinction matters more than it does for CRUD apps. Agents make decisions. They call tools. They can take actions that are hard to undo.

An agent built with a "vibe" mindset — just get it working, review later — will work great in demos. It will fail in ways that are genuinely hard to debug in production, because nobody on the team has a clear model of why the agent makes the choices it does.

An intent-driven agent system looks different:

• Explicit intent at every layer. What is this agent trying to do? What's it allowed to do? What should trigger a human checkpoint?
• Testable sub-goals. Not just end-to-end tests, but tests for each decision point the agent makes. This is where that 70–90% coverage stat starts to matter.
• Documented failure modes. Before you ship, you should be able to say: here are the three ways this agent will fail, and here's how we'd know. Not "it probably works."

The developers who build AI agent architecture this way ship slower at first. Then they ship much faster, because they're not constantly debugging black boxes.

The Terminology Is Actually Worth Fighting Over

I know this sounds like a semantic argument. Does it matter what we call it?

I think it does, because the words we use shape the habits we build. "Vibe coding" gives permission for sloppiness. "Intent-driven development" demands that you stay at the controls — not over every line of code, but over the intent that drives every decision the AI makes.

Boris Cherny built Claude Code. When he says the name matters, I'm inclined to listen.

The developers who thrive in this era won't be the ones who figured out how to vibe the hardest. They'll be the ones who got precise about what they wanted, communicated it well, and kept their hands on the wheel — even when the AI was doing most of the driving.

That's a skill worth developing. And it starts with calling the thing what it actually is.