Everyone is writing off vibe coding right now. Apple pulled apps from the store. Bram Cohen called the whole movement insane. Medium is running a dozen “Vibe Coding Is Over” think pieces from people who tried it once, shipped something that broke, and now want credit for the backlash.

They’re all wrong. Not because vibe coding is fine. It’s not. But the thing that’s dying isn’t what the writeoff crowd thinks it is.

What the Writeoff Crowd Gets Right

The failures are real. Nobody is making them up.

Apple blocked Replit and Vibecode from pushing App Store updates in March, citing Guideline 2.5.2: apps can’t download or execute code that changes their own functionality post-review. A few weeks later, Apple pulled the app “Anything” entirely. Its co-founder Dhruv Amin submitted an update that would preview vibe-coded apps in a browser instead of natively. Apple blocked the update and pulled the app anyway.

The trigger wasn’t one bad submission. Vibe coding drove an 84% quarterly surge in App Store submissions. Apple’s rules didn’t change. The volume of violations did.

Bram Cohen, the inventor of BitTorrent, published “The Cult of Vibe Coding Is Insane” in early April. The subtitle puts it plainly: bad software is a choice you make. The output of the mega-prompt approach, Cohen argued, is hard to maintain, hard to debug, and hard to reason about.

He’s not wrong. The code that comes out of a single mega-prompt is a pile of solutions to individual instructions, not a coherent system. The economics are ugly too: the $20 subscription doesn’t replace the engineer; it defers the bill until the code needs to change, which is always.

But the writeoff crowd is making a different mistake. They’re burying AI-assisted coding when the body on the table is something much more specific.

What Actually Died

The mega-prompt died.

The approach where you write a giant natural-language description of what you want, press enter, and expect working software on the other side. That’s what Apple is blocking. That’s what Cohen is attacking. That’s what produced the flood of broken App Store submissions.

What replaced it isn’t a retreat to typing every line by hand. It’s something more specific, more disciplined, and for engineers who already had discipline, significantly more powerful.

The man who coined the term said it himself.

Andrej Karpathy introduced “vibe coding” in February 2025 to describe weekend projects where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” One year later, February 2026, Karpathy declared vibe coding passé for professional work and replaced it with a different term: agentic engineering.

His definition: “You are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight.”

The person who coined “vibe coding” replaced it with a term that has “engineering” in the name. That’s not a death. That’s a maturation.

Read the definition carefully. “Orchestrating.” “Oversight.” These are not vibes. These are engineering practices with decades of precedent. The vibes are gone. The engineering stayed. And the person who started the movement is the one who made the distinction.

The Proof Nobody Quoted Correctly

In January 2026, Google Principal Engineer Jaana Dogan posted that Claude Code prototyped in one hour a distributed agent orchestration system her team had spent a year working on. The post went viral, millions of views in the first day. The headlines wrote themselves: AI replaces a year of Google engineering in sixty minutes.

But Dogan’s clarification, which traveled about one-thousandth as far, is the sentence that actually matters.

“It takes years to learn and ground ideas in products, then come up with patterns that last for a long time. It’s totally trivial today to take your knowledge and build it again, which wasn’t possible in the past.”

Dogan herself called it a “toy version based on existing ideas.” Not production code. Not a shipped system. A compressed proof of concept built on top of a year’s worth of ideas that had already survived scrutiny.

That’s not vibe coding. That’s the opposite. The prompt worked because the person behind the prompt already knew what good looks like.

A junior engineer with the same tool and the same three-paragraph prompt would not have gotten the same result. They wouldn’t have known what to ask for. They’d have gotten something that ran, possibly even something impressive on first glance. But it wouldn’t have survived contact with production, because the prompt was load-bearing and the person behind it didn’t have the structural intuition to make it bear weight.

That’s the pattern hiding inside every “AI built this in an hour” story. The tool didn’t replace the expertise. The tool consumed the expertise and converted it into velocity. Without the expertise, the same tool produces the output Bram Cohen is describing: code that runs but can’t be maintained, debugged, or evolved.

This is the distinction the writeoff pieces keep missing. They see the failures (bad App Store submissions, unmaintainable codebases, the absence of any production-grade systems built this way) and conclude that AI-assisted coding doesn’t work. What actually failed was AI-assisted coding without engineering judgment. With the judgment, the same tools compress a year into an hour.

The same trap caught me the night Opus 4.5 launched. A personal Svelte project, Friday after working hours, the kind of moment when you tell yourself you can one-shot a feature and ship it before bed. The model wrote the feature. The feature did not work. The fix required truncating a table locally to recover. The parts that did run shipped with duplicated scoped styles across three components when the project already had a global stylesheet ready to absorb them, plus a stack of hard-coded values where the design tokens were sitting unused. The model had been told to use the tokens. It didn’t.

The Discipline Nobody Is Writing About

What does the post-mega-prompt discipline actually look like in practice?

It starts with strategic decomposition: breaking a problem into small, reviewable, testable units before giving any of them to an AI agent.

The difference is concrete. The mega-prompt version of building a feature is one giant natural-language request that describes everything at once and hopes for the best. The disciplined version decomposes the feature into pieces small enough that a human can read, test, and reject each one independently before moving to the next. Same tool. Same AI. Entirely different output, because the decomposition forced the human to think before the machine built.

One observation from the agentic coding discourse puts the stakes plainly: good task decomposition is the difference between multiple agents multiplying your output and multiple agents multiplying your problems.

It continues with reviewing every line. Not because you don’t trust the tool, but because your name is on the commit. Simon Willison drew this distinction a year ago when he separated “vibe coding” (don’t look at the code) from what he called “vibe engineering” (use AI for speed, review everything). The engineering version survived. The vibes-only version is the one Apple is pulling from the store.

And it requires knowing what you’re building before you ask the AI to build it. Architecture first. Interface design first. Failure mode analysis first. Then, and only then, using the tool to accelerate implementation of a plan you already understand.

This isn’t spec-driven development. It’s not a fifty-page document an AI agent then implements. It’s the few decisions you make for yourself before any of the implementation work begins, so the prompts you write later are anchored to something you actually understand.

The discipline that makes AI output useful is the discipline good engineers always had. Decomposition. Review. Architecture. The tools changed. The craft didn’t.

None of this is new. Decomposition is how experienced engineers have always worked. Reviewing your own output is table stakes. Understanding the system before writing the code is not a novel idea. What’s new is that these old practices now determine whether you get 10x amplification or 10x technical debt from the same tools. The practices are the same. The consequences of skipping them just got an order of magnitude worse.

The Compounding Gap Nobody Noticed

The writeoff crowd is celebrating the wrong outcome.

Vibe coding dying isn’t a win for traditional engineering. It’s a win for the disciplined AI users. The engineers who already knew how to decompose problems, review code, and think architecturally just had their advantage amplified. They went from “productive engineer” to “productive engineer who ships at 3x speed because they know how to direct AI with the same precision they direct a junior teammate.”

The engineers who were waiting for vibe coding to fail so they could go back to writing everything by hand? They’re not winning. They’re standing still while the disciplined AI users pull away. Six months from now, when performance reviews land, the engineer who ships twice as much with disciplined AI use will look indistinguishable from an engineer who is simply better. The tooling won’t show up in the evaluation. The output will.

And the engineers who were vibe coding without judgment? They’re the ones Apple is blocking and Cohen is attacking.

Both extremes lose. “Ignore AI entirely” loses to the engineers who use it with discipline. “Use AI without judgment” loses to basic quality gates. The compounding happens in the middle: AI plus engineering discipline, where the tool handles velocity and the human handles direction.

This is why the “vibe coding is dead” celebration misreads the moment. The practice dying is the undisciplined extreme. The disciplined middle didn’t die. It just stopped calling itself vibe coding. It started calling itself engineering with better tools, which is what it always was.

If you can’t articulate the specific engineering discipline that separates useful AI output from the output Apple is pulling from its store, your position just got more precarious. Not because you’re bad at your job. But because the engineers who can articulate it just got faster, and your relative position shifted without you doing anything wrong.

And if you’re skeptical of AI-generated code, that skepticism is completely rational. The vibe-coded output deserves every bit of it. The mistake is assuming the skepticism protects you from the competition. It doesn’t. The engineers using AI with discipline aren’t producing the code you’re skeptical of. They’re producing the code you’d write yourself, just more of it.

The Quiet Part

The earlier argument was that vibe coding was a deferred bill. The bill is now due, and the discipline this piece describes is what emerged to absorb it.

The loudest conversation in engineering right now is whether vibe coding is alive or dead. It’s the wrong question.

The question that matters is what replaced it. Not in the think pieces. In the commit logs. In the shipping velocity of engineers who used the same tools the writeoff crowd has dismissed and produced work that passed every code review, every quality gate, and every production incident without drama.

Nobody announced it. It just started showing up in the output of engineers who were already good at their jobs before any of these tools existed.

—Viz