The AI Gold Rush Has Quietly Moved Somewhere Else

A few weeks ago, I fell into Vercel's State of Vibe Coding report by accident. I was looking for a stat on something else entirely. Forty minutes later I was deep in a pile of unrelated tabs:

• A Hacker News thread arguing AI prompt engineering is dead
• Another one insisting vibe coding killed Cursor
• A LogRocket post making the opposite case — that we should bring prompt engineering back from the dead

None of it was what I set out to read. All of it was more interesting than what I set out to read.

Everyone is circling the same shift

What got me wasn't any single claim. It was a pattern. Everyone was circling the same shift. Nobody agreed on what to call it.

• One person called it vibe coding.
• Another called it agent orchestration.
• A third insisted the real story was MCP quietly becoming more load-bearing than the prompt itself — there's already a small ecosystem of repos built around exactly that idea.

Then the replies drifted further, into observability, eval pipelines, and permission boundaries. On paper, none of that has anything in common. Writing code, designing architecture, and securing a system usually sit under different job titles. But the more threads I followed, the more they looked like rooms in the same house.

For the better part of two years, the interesting AI story was about talking to models. When ChatGPT first showed up, the words you chose actually mattered. Rearrange a sentence and the answer could swing from useless to brilliant. People treated this like a newly discovered craft. They collected prompts. They compared notes. They built personal libraries of phrasing that worked. That wasn't hype. For a while, the conversation with the model genuinely was the product. Getting good at that conversation was a real skill.

The bottleneck didn't vanish — it moved

That assumption is aging fast. Open Cursor or Claude Code today and notice what you don't do anymore. You don't agonize over a prompt. You describe what you want, answer a clarifying question or two, and a working feature shows up. Rough sometimes. Unnervingly polished other times. Either way, it arrives fast enough that the conversation has already moved on. The model got good enough at producing a first draft of software that the interesting bottleneck packed up and moved. Not vanished. Moved. That distinction matters, because a vanished bottleneck and a relocated one look identical from a distance and behave completely differently up close.

One line from that Vercel report stuck with me: English is becoming one of the fastest-growing programming languages, because more people are describing software than implementing it line by line. It reads like a headline built for retweets. Spend enough time with current tooling, though, and it gets hard to argue with. The part that's easy to miss is this: the interesting change isn't English replacing Python. It's what happens to everything sitting around implementation once implementation gets cheap. Cost redistributes attention more than it eliminates it. You don't stop caring about the thing that got cheap — you just stop having to think about it. That freed-up attention has to land somewhere.

We've watched this play before

We've watched this exact redistribution happen before, with a different resource. Cloud computing didn't get rid of infrastructure. It made spinning up infrastructure so frictionless that companies suddenly provisioned far more of it than any data center budget would have allowed. Nobody planned for FinOps — the foundation behind it wasn't even formed until 2019, years after the constraint it addresses had already taken hold. It showed up once the old constraint, how hard it was to get a server, had dissolved. A new constraint took its place: figuring out where all that spend was actually going. Abundance doesn't remove the hard problem. It relocates it to wherever the abundance is happening.

AI coding tools are running the same play, which is maybe why conversations about them keep drifting somewhere nobody planned to go. Someone shows off a feature Cursor built in twenty minutes. Three replies later, people are debating context windows, in threads that look a lot like this one. Or why an agent called the same API thirty times because nobody defined a stopping condition. Or how you'd even evaluate whether the output was good in the first place. I used to read those tangents as the thread losing focus. I don't think that anymore. The tangent was the actual topic. The demo was just the doorway into it.

Systems that don't hold still

What makes this feel less like acceleration and more like a genuinely different kind of problem comes down to how these systems behave. Traditional software is deterministic — same input, same output, barring some outside change. Language models don't hold still that way:

• Their outputs shift.
• The models themselves get updated out from under you.
• They're increasingly wired into tools, APIs, and other agents making independent calls in real time.

None of that makes them unreliable, exactly. It means the system wrapped around them now carries weight that used to live inside the code itself. A prompt can produce working code in an afternoon. A production system has to explain itself six months later, when someone asks why an autonomous workflow approved a refund it shouldn't have, or surfaced a piece of information it had no business surfacing. Those aren't the same problem. They don't get solved by the same skill.

From overhead to the actual design work

The longer I sit with this, the less it feels like a revolution in how programming works. It feels more like a redistribution of where engineering effort goes.

• Boilerplate gets thinner.
• Syntax stops separating good engineers from great ones.
• Implementation speeds up until it feels almost incidental.

Meanwhile the stuff that used to feel like overhead moves earlier into the process — architecture diagrams, eval frameworks, questions about who or what has permission to do what. Eventually it stops being overhead. It becomes the actual design work. Observability quits being something you bolt on after an incident. It becomes part of what you're building from the start. None of this shows up well in a demo video, which is probably why it gets less attention online than a model writing an app in ninety seconds. It's also, as far as I can tell, the thing most likely to determine whether that app is still healthy two years later.

If code stops being scarce, what is?

Something quieter has been shifting underneath all of this too. For decades, software was expensive enough to write that companies organized entire teams around producing more of it. Bigger backlogs. Bigger planning cycles. More people whose whole job was turning ideas into code. If code stops being scarce, what becomes scarce instead? My instinct says it isn't engineering talent in the abstract. It's judgment.

• Judgment about what deserves to get built at all.
• Judgment about where autonomy actually makes sense, versus where deterministic, hand-written logic is still the safer bet.
• Judgment about which decisions stay with a system, and which should always route back to a person, no matter how capable the model looks in a demo.

None of that is a new skill, exactly. It's been sitting in the background for years, overshadowed by how much attention implementation used to demand. It's only becoming visible now that implementation has gone quiet.

We're still asking the wrong question

I don't think we've fully updated the mental model we use to compare these tools. We still ask which coding assistant "writes better code." That's a bit like asking which cloud provider spins up a virtual machine the fastest.

Right now, on paper, that's Claude Fable 5 — the model everyone's been talking about since it landed in June, and the current leader on most coding leaderboards. Here's what that comparison actually looks like, for anyone keeping score:

†SWE-bench Pro uses actively maintained repos with no public ground-truth leakage — it's a harder, newer test than SWE-bench Verified, so GLM-5.2's score isn't directly comparable to the rows above it. Prices and rankings shift monthly; this is a July 2026 snapshot, sourced from Anthropic's pricing docs, OpenAI, and LLM Stats, which aggregates official model cards and independent benchmark reproductions.

None of it is a bad question. All of it is a narrow one. It skips almost everything that happens after the VM boots, or after the feature ships. My guess is that the companies who end up ahead won't be the ones with the sharpest prompts, or even the highest score in that table. They'll be the ones who got exceptional at operating what the AI already built for them: the unglamorous work of keeping a probabilistic system honest once it's live, watched, and depended on.

That's a strange kind of advantage. It doesn't photograph well. But it's the pattern I keep running into, every time I look past the demo.

---

If any of this pulled you somewhere, here's where it started:

• Vercel — The State of Vibe Coding
• Hacker News — AI Prompt Engineering Is Dead
• Hacker News — Vibe Coding Killed Cursor
• cline/cline — a subagent stuck in an infinite loop, no stopping condition in sight
• LogRocket — the case for bringing prompt engineering back

I write these down mostly so I don't lose the thread myself.