We Need to Kill the Term "Vibe Coding"

Kill the Term "Vibe Coding"

We need to kill the term "vibe coding".

Not because some people use AI badly. They do.

Not because careless prompting does not create bad software. It does.

We need to kill the term because it has become a lazy, loaded phrase that makes the whole conversation worse.

"vibe coding" now carries a bad connotation.

It sounds careless. It sounds unserious. It sounds like someone is not smart enough, disciplined enough, or technical enough to build real software.

And that is the problem.

The phrase was popularized in 2025 by Andrej Karpathy, but even that conversation kept evolving. By 2026, the better framing was already moving toward "agentic engineering", where humans still direct, review, and own outcomes.

The phrase gets used to describe almost everything involving AI and code. Sometimes it means someone blindly asked a model to build an app with no requirements, no architecture, no tests, and no idea what the code does. That deserves criticism.

But other times, the same phrase gets thrown at experienced engineers who are using AI thoughtfully: writing better specs, scaffolding faster, translating between frameworks, generating tests, exploring designs, refactoring code, and using the tool as an accelerator.

Those are not the same thing.

Part of the confusion is that the term itself got lost in the weeds of a fast-moving industry. Early on, "vibe coding" often meant asking AI to spin up an entire app with minimal direction and shipping it without real ownership. Today, people also use the same phrase for a very different workflow: generating a targeted fix, then reviewing it with a human in the loop through pull requests, code review, and testing.

That second workflow is not careless vibe coding. That is disciplined engineering with AI assistance.

The first thing we need to do is separate careless AI usage from serious, disciplined, AI-assisted engineering and supervised generation.

The False Fight

A lot of media coverage, conference commentary, and thought-leadership hot takes frame this moment as two loud camps.

That framing is useful for headlines, but it does the industry a disservice. Most teams are not living at either extreme. They are trying to find practical, responsible ways to use AI without abandoning engineering discipline.

On one side are people who hate all things AI. They see AI coding as a threat to craft, identity, and maybe even the profession itself. To them, anything generated by AI is suspect.

You can see this mindset in endless "gotcha" posts, like spending hours proving a model once miscounted the number of r's in "strawberries." That might score points for a day, but in a fast-moving field it becomes irrelevant almost immediately. Five days later, the model is better, the tooling has changed, and serious teams have moved on.

Outrage cycles may win attention for a day, but software engineering rewards the people and teams who adapt, test, learn, and ship.

On the other side are people who think AI can magically create great software on the first try: no specs, no review, no tradeoffs, no testing, no architecture, no ownership.

Both sides are wrong.

There is a middle ground, and that is where the industry will land.

AI is not going to make engineering disappear. It is going to change the way engineering gets done.

We still need people who understand problems, patterns, practices, tradeoffs, collaboration, scale, security, privacy, infrastructure, and production readiness, and who can create something new.

AI can help us move faster through accidental complexity. It can remove barriers, eliminate repetitive work, translate between languages and frameworks, explain unfamiliar syntax, scaffold features, and generate tests.

But it does not remove essential complexity.

Fred Brooks Is Still Right

In 1986, Fred Brooks wrote No Silver Bullet, one of the most important essays in software engineering.

His core argument was that software has two kinds of complexity: accidental complexity and essential complexity.

Accidental complexity is friction around the work: syntax, boilerplate, tooling, configuration, translation between languages, repetitive patterns, and all the little things that slow us down.

Essential complexity is the real problem: understanding what needs to be built, why it matters, how the pieces fit together, what tradeoffs are acceptable, what should scale, what should be secure, what should be simple, and what should not be built at all.

AI is very good at helping with accidental complexity. That is a big deal.

But AI does not magically solve essential complexity. It does not know your users, constraints, risk tolerance, compliance needs, privacy model, IP rules, or operational realities unless those things are clearly specified.

That is engineering. And that is not going away.

The Spec Becomes More Important, Not Less

The better AI gets at generating code, the more important the spec becomes.

When coding gets faster, bad direction gets more expensive. A vague prompt can produce a lot of code quickly. It may look impressive and even run, but if assumptions, architecture, security, or scale targets are wrong, all you have done is generate rework faster.

Serious AI-assisted engineering and supervised generation need strong direction. Those directions are engineering decisions:

• Use MVC or MVVM where appropriate.
• Keep the code DRY and coherent.
• Avoid over-engineering for prototype phases.
• Design for scale when growth is expected.
• Use explicit authentication and authorization patterns.
• Separate local, dev, test, and production environments.
• Respect HIPAA, privacy, IP, and security constraints.
• Generate tests before changing behavior.
• Design unit testing strategy for scale.
• Include cost analysis and cost controls from the start.
• Plan administration portals and operational controls.
• Define reporting and advanced reporting requirements early.
• Implement verbose logging, monitoring, and telemetry.
• Treat enterprise infrastructure and platform engineering as first-class concerns.
• Prefer safe refactors over unnecessary rewrites.

AI can speed up all of this enterprise-grade work. It helps teams deliver the capabilities great systems need in version one, instead of bolting them on months later after risks, incidents, and rework start piling up.

AI can execute, suggest, and accelerate. Humans still steer.

AI Doesn't Make You Smart, But You're Smart to Use It

One hard truth in our profession: we often teach programmers to write code before they learn to read it deeply.

Software engineering has always been about modeling the real world: deeply understanding it, conveying clear requirements, and only then writing code.

AI can help with explanations, but it cannot replace this discipline. It cannot substitute for earned judgment.

Great engineers will read AI output, challenge it, review it, refactor it, rewrite it, scrap it, or delete it. They do not outsource accountability.

In many cases, the best coders delete more code than they write.

This Has Happened Before: CASE Tools, 4GL, and Abstraction Cycles

In the 1980s, CASE tools promised to let non-programmers build systems. In the 1990s, 4GL platforms promised to eliminate the need for deep engineering. Both underdelivered in the same way: abstractions could accelerate implementation, but they could not remove the need for real understanding.

The teams that won were not the teams with the loudest claims. They were the teams with engineers who could inspect generated code, identify bad assumptions, and make disciplined design choices.

AI follows this same pattern. It creates leverage, not immunity from mistakes.

The Companies That Blend Will Win

The winners will not be the companies that ban AI. They also will not be the companies that turn everyone loose with a chatbot and call it strategy.

Winning companies blend human expertise with AI leverage. They define standards for architecture, review, testing, security, and deployment. They use AI for coding, documentation, analysis, migration, and operational workflows with appropriate guardrails.

They understand that different use cases carry different risk profiles, and they build ownership models around that reality.

AI-generated code is still code. It must be read, tested, reviewed, secured, deployed, operated, and maintained.

The Future Is "Agentic Engineering," "AI-Assisted Software Engineering," and "Supervised Generation"

If we are going to rename this moment, use better terms: "agentic engineering," "AI-assisted software engineering," and "supervised generation."

These are clearer, more precise, and more honest about what is happening: engineers using AI to build better software faster, with discipline and active human oversight.

The future is not "AI replaces engineers." The future is also not "real engineers do everything by hand." The future is people and teams shipping better systems through better specs, better prompts, better testing, better reviews, better architecture, better operations, and better judgment.

So yes, kill the term "vibe coding." Not because careless AI coding is harmless, but because the phrase is too sloppy for the moment we are in.

The opportunity is not to lower the bar for software engineering. The opportunity is to raise the bar and use AI to remove the friction - the accidental complexity - so we can spend more time on what matters most: the essence of engineering.