Vibe Coding Is Over. Orchestrating Agents Is the Job Now.

Listen to this article

Vibe Coding Is Over. Orchestrating Agents Is the Job Now.

0:00

The renaming, the data, and what to actually do about it, ten slides

Save it, share it, or send it to whoever on your team is still measuring AI coding by lines typed instead of specs written.

Swipe to preview · 10 slidesDownload the PDF

The person who named it already renamed it

On February 2, 2025, Andrej Karpathy posted a short, self-deprecating description of a new way of working: forget the code exists, barely touch the keyboard, accept every suggestion without reading the diff, copy-paste error messages back with no comment, and let the code grow while you just watch. He called it vibe coding, and the term did exactly what a good name does. It spread. It became Collins Dictionary’s Word of the Year for 2025. It described, accurately, how a huge number of people were actually building software with AI: fast, loose, and a little reckless.

Karpathy didn’t stop using AI to code. He stopped calling it vibe coding. By early 2026 his preferred term was “agentic engineering,” and his own explanation of the switch is the whole argument of this piece in one sentence: 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. Engineering, because there is craft and expertise to doing that well, not just taste.

That’s not a rebrand for its own sake. It’s an admission that the first version of the practice, accept-everything, read-nothing, was never the destination. It was what happened in the gap before the tooling and the discipline caught up to what the models could already do. Eighteen months later, both have caught up, and the data shows exactly how much that gap mattered.

What happened in eighteen months

Start with the plainest evidence available: what Google itself is doing with its own codebase. At Google Cloud Next 2026, CEO Sundar Pichai reported that 75% of new code at Google is now AI-generated, up from 50% just six months earlier. He was careful to add the part that matters most for this argument: every line of that code is still reviewed and approved by engineers. AI is producing the draft at a scale no individual engineer could match. Humans are still the ones deciding whether it’s right.

Pichai gave two concrete examples of what that looks like in practice, and both are worth sitting with because they’re the kind of work vibe coding was never built to do. A complex code migration, run by agents and engineers working together, was completed six times faster than the same class of work took a year earlier with engineers alone. And when Google’s team needed a native macOS build of the Gemini app, they built the initial release with Antigravity, Google’s own agentic development platform, going from idea to a working Swift prototype in a few days. Neither of those is a story about someone typing a good prompt. They’re stories about someone directing a system.

The same shift shows up inside Anthropic, described in almost the same language the industry is now using for it. In a widely circulated 2026 talk on what practitioners call graph engineering, an Anthropic engineer put the internal trajectory bluntly: roughly 80 to 90% of the company’s own engineers had been running what the field calls self-improving loops, a single agent iterating on its own output in a cycle. The next step, already underway at the time of the talk, was building agentic graphs instead: multiple agents with distinct roles, wired together with explicit handoffs, instead of one agent looping alone. The engineer’s own framing was that within four to six months, that would simply be how the work got built. No more prompting, in the sense of one person typing one instruction and hoping.

Why the productivity data is split, and what it’s actually measuring

Here’s the part that should make anyone pause before treating “use AI to code” as a single, well-defined intervention with a single, knowable effect size. It isn’t. The evidence from the last eighteen months is split almost exactly along the line this piece is drawing, between unstructured assistance and directed orchestration, and the split is large enough to change the sign of the result.

METR ran the cleanest test of the unstructured case. In a mid-2025 randomized controlled trial, sixteen experienced open-source developers worked on real issues in repositories they knew well, with an average of five years of prior experience on those specific codebases, using Cursor with Claude 3.5 or 3.7 Sonnet in chat and agent mode. The result surprised almost everyone involved: developers took 19% longer to complete tasks with AI assistance than without it. Afterward, the same developers estimated they’d been sped up by 20%. They were wrong in both directions at once, slower in fact, faster in their own perception, which is its own warning about trusting a gut sense of whether a tool is working.

METR didn’t stop there. In February 2026 the organization published a follow-up with a larger, more diverse cohort, 800-plus tasks across 57 developers and 143 repositories, and found the effect had moved to roughly -4%, close enough to breakeven that METR’s own conclusion was that AI likely provides productivity benefits in early 2026. Part of the shift, by METR’s own account, came from a selection-effect problem in the original sample: 30 to 50% of invited developers had declined to take part without AI access at all, which had skewed the first study toward exactly the developers least likely to benefit. Correct for that, and the picture improves. It still isn’t a clean win. Even in the best reading of the most recent data, prompting an agent solo, on your own familiar codebase, without a structured process around it, gets you somewhere between a wash and a modest gain. Not the transformative leap the marketing promises.

Compare that to GitHub’s own controlled study of Copilot, a narrower tool doing a narrower job, autocomplete and inline suggestion rather than open-ended agentic coding. Developers with Copilot completed a defined task 55% faster, 1 hour 11 minutes against 2 hours 41 minutes for the control group, with a higher completion rate. Accenture’s real-world enterprise data pushes further: pull request cycle time dropped from 9.6 days to 2.4 days, a 75% reduction, alongside an 84% increase in successful builds. That’s a genuine, measured win, not an illusion like the one METR’s developers experienced. But notice what’s different about the unit of work. Copilot’s gains show up on bounded, well-specified tasks with a tight feedback loop, not on the kind of open-ended “go build this feature” prompting that defines vibe coding at its loosest.

Then look at what happens when the structure gets built deliberately, not incidentally. In August 2026, Anthropic disclosed that an unreleased research version of Claude had raised a long-standing lower bound related to the Riemann hypothesis, the proportion of Riemann zeta function zeros proven to satisfy it, from 41.6% to 67.2%. Human mathematicians had moved that number by roughly 0.8 percentage points across the prior 37 years. Claude moved it 25.6 points in two sessions. The way it got there is the entire argument of this piece made concrete: the system coordinated around 60 Claude subagents inside Claude Code across 31 million output tokens and 2,400 shell commands. It generated and discarded 650 dead-end ideas. Two agents found the winning approach, a synthesis of a 2000 Enrico Bombieri paper with more recent results that no human researcher had previously combined. Thirteen more contributed pieces to it. Thirteen others did nothing but try to validate or break it. Anthropic mathematicians and two external reviewers checked the result, and Claude itself produced a formal, machine-checked proof in the Lean theorem prover before anyone called it done.

That is not a bigger vibe. It’s a different shape of work entirely: a defined goal, parallel exploration with distinct roles, and a verification gate that nothing gets past on vibes alone. It is also, not coincidentally, the shape the productivity data actually rewards.

What “director” means in practice

Strip the jargon and the distinction between a loop and a graph is simple. A loop is one agent, iterating on its own output in a cycle, plan, act, check, repeat, until it converges or gives up. It’s what most of last year’s “AI agent” demos actually were. A graph is multiple agents with different roles, wired together with explicit handoffs and, critically, at least one role whose entire job is verification rather than production. The Riemann zeta run had that structure exactly: idea-generators, contributors, and a dedicated validator tier, running in parallel rather than as one long conversation.

This isn’t a research-lab curiosity anymore. It’s shipping as default infrastructure. AWS’s Kiro, launched internationally in May 2026 as a ground-up replacement for Amazon Q Developer, inverts the usual order entirely: the specification is the source of truth and the code is a generated build artifact, not the other way around. GitHub’s open-source answer, Spec Kit, crossed 111,000 stars by June 2026 and implements a similar pipeline, constitution to plan to tasks to implementation, wired into more than 30 coding agents including Claude Code, Copilot, and Gemini CLI. Google’s own Antigravity 2.0, launched at I/O 2026, gives developers a CLI, desktop app, and SDK built specifically to orchestrate multiple agents in parallel on the same task, exposing the same internal harness Google’s own engineers use. And LangGraph, the most widely adopted orchestration framework outside any single vendor’s walled garden, now sees 90 million monthly downloads and runs in production at Uber, JPMorgan, BlackRock, Cisco, LinkedIn, and Klarna, built around exactly the supervisor-and-subagent, fan-out-and-fan-in pattern the Riemann zeta run demonstrated at the extreme end.

Every AI coding tool referenced in this piece, Cursor, Copilot, Claude Code, Kiro, Antigravity, sits somewhere on this spectrum. The tool isn’t what determines which column you’re in. How you use it is.

How to actually prepare

None of this requires abandoning speed or spontaneity entirely. It requires building four specific habits before the codebase you’re responsible for gets big enough that skipping them becomes expensive.

First, practice writing specs, not just prompts. A spec states the constraint, the acceptance criteria, and what “done” verifiably means, before any code gets generated. Kiro and Spec Kit both encode this as a literal pipeline, but you don’t need either tool to start the habit. Write the spec for your next non-trivial task before you open an agent, even if you’re the only one who reads it.

Second, learn to review the trace, not the diff. When a system runs 2,400 shell commands across 60 subagents, reading every line of output isn’t the job anymore, and it never really was even at smaller scale. The skill is reading the plan an agent proposes before it executes, and the summary of what it did after, closely enough to catch a wrong turn early rather than a wrong answer late.

Third, build your own verification gate before you expand what any agent is allowed to touch. This is the same discipline as a test suite and a CI pipeline, applied one layer up, to agent output rather than human output. The Riemann zeta run didn’t succeed because Claude got smarter mid-session. It succeeded because a third of the subagent budget was spent on nothing but trying to disprove the winning idea before anyone trusted it.

Fourth, practice decomposition as its own skill. Breaking one large, vague request into a planner role, an implementer role, and a checker role is a genuinely different exercise from writing a good single prompt, closer to how a lead engineer breaks a project into workstreams for a team than to how anyone writes a search query. It’s learnable, and Karpathy’s own point stands: it’s a skill you get better at with deliberate practice, not something that happens automatically because the model improved underneath you.

What’s coming, and the actual choice in front of you

Karpathy renamed his own term within a year of coining it. Google moved from half to three-quarters of its code being AI-generated in six months. Anthropic’s own engineers moved from single-agent loops to multi-agent graphs inside roughly the same window, by their own account. None of these are five-year forecasts. They are descriptions of what already happened, recently, at organizations with every incentive to get this right because their production systems depend on it.

The debate about whether vibe coding “counts” as real engineering was never going to be settled by argument, and it wasn’t. It was settled by the people doing the most of it simply moving past it, the way a first draft gets replaced by a second one nobody argues about missing. What’s left isn’t a question of whether orchestration is coming. It’s already the default at the organizations shipping the most AI-generated code in production. The only open question is whether you’re building the specific, learnable habits, specs over prompts, traces over diffs, verification gates over blind trust, before that becomes the baseline expectation of the role you’re already in, or after.

The AI Governance & ROI Executive Programme works through this exact shift with engineering leadership in the room: how the review unit moves from the diff to the spec and the verification gate, and what has to be true before agent autonomy expands on a real system. Details are on the workshops page.