Vibe Coding Is Dead: The Rise of Agentic Engineering (2026)

TL;DR — In February 2026, exactly one year after he coined it, Andrej Karpathy retired the term “vibe coding” and replaced it with “agentic engineering.” The shift is not cosmetic. Vibe coding meant describe what you want and accept what comes back. Agentic engineering means design the system, direct the agents, audit the work. The first raised the floor of who could build software. The second preserves the ceiling on quality once you actually ship. This article walks through what changed, why the harness around the model now matters more than the model itself, what Anthropic’s Claude Code reveals about where the discipline is heading (it now writes 90% of its own code), and what it means for engineers staying in the field through 2026.

What Happened to Vibe Coding? It Was Everywhere Six Months Ago.

Vibe coding peaked in late 2025 and was effectively retired by its creator, Andrej Karpathy, in February 2026. The term went viral in February 2025 when Karpathy described a new way of building software: you describe what you want in natural language, an LLM produces a working chunk of code, you keep prompting, you accept what comes back. You go with the vibe. Non-engineers were suddenly shipping working apps. Engineers were prototyping in hours what used to take weeks. The term captured something real.

The appeal was simple and powerful:

• It raised the floor. People who had never written a line of code could build functional software. Non-technical founders prototyped products. Designers shipped working components. The barrier to building dropped dramatically.
• It changed prototyping speed. Engineers who knew what they were doing could iterate through ideas at five to ten times the pace of typing the code themselves. Throwaway experiments became cheap.
• It produced a viral aesthetic. “I just vibe coded this” became a shorthand for moving fast, trusting the model, and getting something working without obsessing over implementation.

For about ten months, vibe coding looked like the future of software development. Then it ran into a problem that the framing itself made hard to see.

So What Went Wrong?

The problem with vibe coding was not that the code was bad — it was that “the vibe” had no quality ceiling. As long as you were prototyping, none of that mattered. As soon as the code went near production, the cracks appeared everywhere. An agent that confidently matches Stripe email addresses to Google account emails doesn’t throw an error — it just silently wrecks your data. Vibe-coded software was passing tests because no one had thought to write the tests that would have caught the actual problem.

Three failure modes kept showing up:

1. Silent assumptions become silent bugs. The agent makes a reasonable-looking decision — how to identify a user, how to handle a null value, how to parse a date — and there is no error message. The code ships. The bug compounds. By the time anyone notices, it has been in production for weeks.

2. The reviewer disappears. The whole point of vibe coding was not reading every line. But the assumptions that need to be checked are exactly the ones the model glossed over. When no one reads the code, no one catches the security issue, the privacy leak, or the data corruption pattern.

3. The system can’t be reasoned about. A vibe-coded app is a sequence of “this worked” decisions stacked on top of each other. When something breaks in production, you don’t have a mental model of the system to debug from. You have a transcript of prompts.

The engineers who had been most enthusiastic about vibe coding were the first to notice the limits. Vibe coding raised what anyone could build. But what people could trust in production was a different question — and the framing pretended that question didn’t exist.

The Person Who Invented Vibe Coding Just Moved On from It. What Does That Tell Us?

When the person who created a term abandons it within a year, that is a signal worth taking seriously. Karpathy didn’t drop “vibe coding” because the underlying capability got worse. He dropped it because the framing became actively misleading once the tools crossed a quality threshold. In February 2026 — almost exactly the one-year anniversary of coining the original term — he posted what has since become a widely cited framework on X: programming via LLM agents was becoming a default workflow for professionals, but with much more oversight, scrutiny, and discipline. He proposed a new name: agentic engineering.

His exact framing was precise: “‘Agentic’ because the new default is that you are not writing the code directly 99% of the time. You are orchestrating agents who do and acting as oversight.” The key three words he kept repeating: direction, judgment, taste. Those are the human contributions that don’t go away — they become the entire job.

What that tells us:

The discipline is real, but the previous name was wrong. The work of orchestrating AI agents to produce production-grade software is genuinely valuable — Karpathy explicitly called the leverage “very high right now.” The framing of “vibe coding” implied sloppiness and impermanence, which is exactly the wrong association for work that is supposed to ship to real users.

The category needs a professional name to attract professional adoption. Engineering leaders weren’t going to staff teams with “vibe coders.” They will staff teams with agentic engineers. The renaming is partly recognition that vibe coding had become a marketing problem for serious adoption.

The 10x engineer framing is obsolete. Karpathy was explicit about this: the speed-up available now is way more than 10x — but only for engineers who have the discipline to operate as agentic engineers. A 100x productivity multiplier on terrible code is not a win. A 10x multiplier on production-grade code is.

Why Does the Harness Matter More Than the Model?

Because the model is the engine, but the harness is the car around it — and most of the actual engineering happens in the harness. The model produces tokens. Everything else that makes those tokens useful — context management, tool use, error recovery, permission gates, multi-agent orchestration, the spec layer — sits in the surrounding software. Anthropic’s Boris Cherny and others have made this case explicitly: the difference between an agent that works in production and one that fails is rarely the model. It is the harness.

The eight layers that define a serious harness:

• Context management — what does the agent see, when, and how is it pruned when context windows fill up
• Tool use and MCP — which external systems can the agent reach, with what permissions
• Multi-agent orchestration — when do you spawn sub-agents, how do they communicate
• Permission and approval — what requires human review before execution
• Error recovery and retry — what happens when the agent’s first attempt fails
• Spec and plan layer — what does the agent actually try to build, before it starts building
• Background execution — does the task continue when the user closes their laptop
• Audit and test integration — what verifies that the work is correct before it ships

This is why two teams using the same model — Claude Opus 4.7, GPT-5.5, Gemini 3.5 — can produce wildly different outcomes. The team with the better harness ships faster, with fewer bugs, at higher quality. The model is necessary but no longer sufficient.

So the Gap Isn’t the Model. It’s the Harness.

Right — and that has big strategic implications for how engineering teams should invest their time. Through most of 2024 and 2025, the dominant question was which model is best at coding? That question still matters, but the gap between top models has narrowed faster than the gap between teams that have built sophisticated harnesses and teams that haven’t.

Three places where this shows up:

1. The compounding effect of MCP. The Model Context Protocol — originally introduced by Anthropic, now adopted by Google’s Gemini Spark and OpenAI’s ChatGPT Agent — has become the universal interface for agents to reach external tools. Once a team builds MCP connectors for its internal systems, every agent benefits. The connectors are harness, not model. Teams that have invested in their connector infrastructure are now multiples ahead of teams that haven’t.

2. The spec layer is becoming the bottleneck. The hardest problem in agentic engineering isn’t getting the agent to write code — it’s getting the spec right before the agent starts. Engineering teams that have developed disciplined patterns for writing specs — what the agent is supposed to build, what success looks like, what the constraints are — see dramatically different outcomes from teams that hand the agent vague instructions.

3. Audit and test infrastructure is the safety net. When 80–100% of code is written by an agent, the test suite isn’t a nice-to-have. It is the thing that prevents catastrophic failures from shipping. Teams that have invested in comprehensive test coverage are the ones that can let agents work autonomously. Teams without that safety net have to slow agents down to a crawl with manual review.

The strategic implication: if you are a CTO or engineering leader trying to capture the productivity gains of agentic engineering, the right investment is not “buy more Claude licenses.” It is “build the harness.” That includes the connectors, the spec discipline, the test infrastructure, and the agent orchestration patterns that let your engineers work as architects rather than implementers.

So the Spec Becomes the Input to the System That Will Implement the Feature?

Yes — and this is the single biggest shift in how engineering work is structured. In traditional software development, the spec was a document that humans read before writing code. In agentic engineering, the spec is the executable input that an agent uses to produce code. The quality of the spec is now the upstream constraint on the quality of the output.

What this means in practice:

Specs become first-class engineering artifacts. They are versioned, reviewed, tested, and treated with the same rigor as the code they produce. A bad spec is now a production incident waiting to happen.

The skills shift. Writing a great spec — clear enough that an agent can execute it, precise enough that the output can be verified, complete enough that the edge cases are covered — is genuinely hard. It is closer to designing an interface than to writing prose. The engineers who get good at it are the ones who become 10x more productive. The ones who don’t, can’t capture the leverage.

The review process inverts. Instead of reviewing code, senior engineers increasingly review specs and audit the agent’s output. The review at the spec stage is cheaper — you catch problems before the agent has executed against a bad input. The review at the output stage is essential — you catch the silent assumptions the agent made along the way.

This is also why the framing of “agentic engineering” feels more accurate than “vibe coding.” Writing a great spec is engineering work. Letting the agent vibe its way to a solution is not.

The Tool Writes Its Own Code?

Yes, and the numbers are real. Boris Cherny, the creator and head of Claude Code at Anthropic, has been the most public voice on this. On the Latent Space podcast in 2025, he said Claude Code writes 80–90% of its own code. By early 2026, on Lenny’s Podcast, he said 100% of his personal code has been written by Claude Code since November 2025 — he has not edited a single line by hand. He ships 10–30 pull requests per day, often with five agents running concurrently.

The wider data points reinforce this:

• Anthropic company-wide: CEO Dario Amodei said at Davos in January 2026 that “the vast majority” — around 90% — of Anthropic’s new code is now AI-written.
• Productivity per engineer: Cherny reported productivity per Anthropic engineer increased roughly 70% in a year, even as the engineering team tripled in size.
• Other labs follow: OpenAI researchers, including the pseudonymous Roon, have made similar claims about no longer writing code by hand.

What this means is significant for two reasons. First, it validates that agentic engineering works at the highest end — a frontier AI lab building a developer tool that builds itself. Second, it reveals the recursive loop the AI industry is now in: tools that get better at building tools, building tools that get better. The pace of acceleration in 2026 owes a lot to this dynamic.

A reasonable caveat: these are vendor-supplied numbers. Independent audits of how much code is AI-written vs human-edited at Anthropic don’t exist. The headline percentage probably understates how much human direction, spec writing, and review goes into each AI-written PR. But the directional point — that agents now write the majority of code at frontier labs, with humans operating as architects and reviewers — is broadly verified across multiple sources.

Is This Painful for Existing Engineers?

Honestly, yes — for some of them, in a way the industry is not being open enough about. The transition to agentic engineering is not a free productivity boost for everyone. It is a sorting mechanism. Engineers who can adapt their skills toward direction, judgment, and review are seeing genuine career upside. Engineers whose value was concentrated in the implementation phase — the work that an agent now does in seconds — are facing a harder reality.

The honest read by skill profile:

Winners — the architects. Senior engineers who design systems, write disciplined specs, audit AI output, and mentor through code review are seeing their value increase, not decrease. Their judgment is what makes the rest of the system work. Staff and principal engineer compensation is up substantially.

Adapting — the mid-level. Mid-career engineers who are actively learning to direct agents — building harnesses, writing specs, structuring reviews — are seeing 2–5x productivity gains. The transition is genuinely demanding, and not everyone is making it gracefully. Compensation curves are being rewritten in ways that haven’t settled.

At risk — the pattern-matchers. Engineers whose primary value was implementing standard patterns from clear specs are in the most exposed position. This includes a large portion of junior engineering hiring, implementation-heavy roles, some offshoring contracts, and any work where the human’s contribution was “translate this spec into code.” That work is what agents do best.

The harder structural problem is what this means for the entry-level rung of the engineering career ladder. Traditionally, junior engineers learned by writing implementations of patterns that senior engineers had specified. That learning loop is exactly what agents have automated. Engineering leaders need to invent new ways to develop junior talent that don’t depend on the implementation-phase work that has been the historical training ground. Several companies have started rotating juniors through spec-writing, review, and agent-orchestration roles instead. It is too early to know if these alternatives produce engineers as well as the old apprenticeship model did.

This is the part of the agentic engineering story that doesn’t fit on a productivity slide. The technology works. The leverage is real. The disruption to the career structure is also real, and the industry is still figuring out what to do about it.

Is Vibe Coding Completely Dead, or Does It Still Have a Place?

Not completely dead — but it has a much narrower place than its peak hype suggested. Vibe coding remains useful for the work it was always best at: prototyping, side projects, throwaway experiments, and exploratory work where the cost of failure is essentially zero. The mistake of late 2025 was treating that workflow as a general approach to building software, including software meant for production. The mistake of 2026 would be assuming vibe coding has no remaining role.

Where vibe coding still works:

• Prototyping a new idea quickly before you have any sense of whether it is worth building
• Side projects where you are the only user and the worst case is just deleting it
• Internal tools that touch no sensitive data and can be replaced in an afternoon
• Learning new languages or frameworks by getting working examples fast
• Hackathons and timeboxed experiments where speed beats robustness

Where agentic engineering is the right discipline:

• Anything that touches customer data
• Anything that ships to a production environment
• Anything where the cost of silent failure is meaningful
• Anything that other engineers will need to read, debug, or extend
• Anything where security, privacy, or compliance is involved

A useful mental model: vibe coding is the prototype workflow, agentic engineering is the production workflow. Most professional software work is the second category. Most personal hobby work is the first. The error people make is using the prototype workflow for work that should be on the production track.

What This Means for Engineering Leaders in 2026

Three priorities deserve attention this quarter, based on where the discipline has actually moved.

1. Invest in your harness, not just your models. The team that builds disciplined harness infrastructure — connectors, spec patterns, review processes, test coverage, agent orchestration — captures more leverage from any model than the team that just buys more Claude Pro seats. This is the highest-ROI engineering investment available right now.

2. Rewrite your hiring and career paths. The job description for an engineer in 2026 is meaningfully different from the one in 2024. Spec writing, agent orchestration, and review discipline are now core skills, not nice-to-haves. The career ladder needs to reflect this. Some companies are explicitly hiring “agentic engineers” as a distinct role; others are folding the skill set into existing tracks. Either approach can work — operating as if nothing has changed cannot.

3. Develop a new model for growing junior talent. The traditional apprenticeship model — juniors implementing specs from seniors — has been largely automated. Engineering organizations that don’t invent a replacement will face a senior-engineer pipeline problem in 2030–2035. The companies experimenting with rotating juniors through spec writing, agent supervision, and architecture review early in their careers are running the most important talent experiment in the industry. Watch what they learn.

Frequently Asked Questions

What is vibe coding?

Vibe coding is a term Andrej Karpathy coined in February 2025 to describe a style of programming where you describe what you want to an LLM in natural language, accept the code it produces without reading every line, and iterate by prompting. It made software development accessible to non-engineers and dramatically accelerated prototyping, but produced quality problems when used for production code.

Why did Karpathy stop using the term vibe coding?

In February 2026, on the one-year anniversary of coining the term, Karpathy announced that vibe coding’s framing had become misleading. He proposed replacing it with “agentic engineering” — a more accurate description of the discipline of orchestrating AI agents to produce production-grade software with direction, judgment, and oversight rather than just accepting whatever the model returns.

What is agentic engineering?

Agentic engineering is the discipline of designing systems, writing specs, directing AI agents through complex multi-step workflows, and auditing their output to produce production-grade software. Where vibe coding is “describe what you want and accept what comes back,” agentic engineering is “design the system, direct the agents, audit the work.” The key skills are direction, judgment, and taste.

Is vibe coding dead?

Effectively yes for production software work, where the discipline has shifted to agentic engineering. Vibe coding remains useful for prototyping, side projects, hackathons, learning new technologies, and other low-stakes exploratory work. The mistake is using vibe coding for software that needs to ship reliably.

What is the “harness” in agentic engineering?

The harness is all the software that surrounds the AI model and turns it into a working agent: context management, tool use through MCP, multi-agent orchestration, permission and approval gates, error recovery, the spec/plan layer, background execution, and audit/test integration. Two teams using the same model can produce wildly different outcomes depending on the quality of their harness.

How much code does AI actually write at frontier labs?

Boris Cherny, head of Claude Code at Anthropic, has said publicly that 80–90% of Claude Code’s own code is now written by Claude Code, and that 100% of his personal code has been AI-written since November 2025. Anthropic CEO Dario Amodei said at Davos 2026 that around 90% of Anthropic’s new code is now AI-written. These are vendor-supplied numbers but consistent across multiple sources.

Will agentic engineering replace software engineers?

Not as a wholesale replacement. Senior engineers who design systems, write specs, and audit AI output are seeing their value increase. Engineers whose primary skill was implementing standard patterns from clear specs are in a more exposed position. The biggest structural concern is the entry-level career ladder — the work that used to train juniors has been largely automated, and the industry has not yet figured out a robust replacement.

What skills should engineers develop for the agentic era?

Spec writing (precise, testable, complete instructions for an agent), system design (the architecture an agent will build within), code review and audit (catching the silent assumptions agents make), agent orchestration (when to spawn sub-agents, how they coordinate), and harness construction (building the infrastructure that surrounds the model). Karpathy’s three words — direction, judgment, taste — are the underlying capabilities that don’t go away.

Is agentic engineering just a rebrand of AI-assisted coding?

No. AI-assisted coding implied the human was still writing most of the code with AI suggesting completions. Agentic engineering inverts that: the agent writes most of the code, and the human directs, reviews, and audits. The change in who is doing what is significant enough to justify a different name.

Final Take

Vibe coding was a useful concept that captured a real shift in late 2025. Agentic engineering is what comes after — a more honest description of the discipline that actually produces production-grade software when AI does most of the typing. The fact that the person who created the original term retired it within a year tells you everything about how fast this field is moving.

For engineers, the practical advice is direct: stop treating AI-assisted coding as a productivity hack and start treating it as a discipline with its own skills, patterns, and failure modes. The leverage is real. It is also conditional on doing the work properly — building the harness, writing the specs, auditing the output, and developing the judgment that the framing of “vibe coding” implicitly devalued.

For engineering leaders, the advice is sharper: the team that builds disciplined agentic engineering practice in 2026 will compound a productivity advantage that the team waiting for the next model release will not catch up to. The model is the engine. The harness is the car. Buy the engine. Build the car.

---

Published May 24, 2026 · The AI & Tech Society · digitalstrategy-ai.com

Sources: Andrej Karpathy, Sequoia AI Ascent 2026 talk and February 2026 X posts; Boris Cherny on Lenny’s Podcast (Feb 2026) and the Latent Space podcast; Dario Amodei, Davos 2026; SD Times, Fortune, and engineering-leader analysis published April–May 2026.