One year after Andrej Karpathy coined "vibe coding," the real shift isn't about code at all.
The Term That Launched a Thousand Debates
In February 2025, Andrej Karpathy posted a simple observation. He was building software by "fully giving in to the vibes" - describing what he wanted, letting AI write the code, accepting the results without fully understanding every line. He called it vibe coding.
Within weeks, the term was in Merriam-Webster. Within months, it had become one of the most polarizing ideas in software engineering.
The backlash was swift and loud. Buggy output. Security holes. Senior developers reduced to "AI babysitters" spending 30-40% of their time cleaning up AI-generated messes. A Fastly survey found that 95% of developers spent extra time fixing AI-generated code. The verdict from the engineering community was clear: vibe coding was a parlor trick, not a practice.
Here's what I think they got wrong - not about the problems, but about what they were actually criticizing.
Why 1.0 Deserved the Criticism (And Why It Doesn't Anymore)
The backlash was fair. At the time.
Two things made vibe coding underwhelm in early 2025:
The models weren't ready. Early 2025 models could generate impressive-looking code in demos, but they struggled with systems thinking. They'd generate the same feature multiple times in different ways rather than creating reusable components. They'd introduce subtle security vulnerabilities. They optimized for "looks right" over "works right."
The humans weren't ready either. Knowing how to work with an LLM - how to steer it, constrain it, review its output, structure your requests - is a genuine skill. It takes experience to develop. Most people trying vibe coding in early 2025 were learning the tool and the technique simultaneously. Of course the results were rough.
A year later, both problems have largely resolved. Models are dramatically more capable. Practitioners have developed real expertise in guiding them. Vibe coding 1.0 - one human, one LLM, generating code through conversation - actually works remarkably well now for a wide range of tasks.
But that's not the interesting part.
The Dual Layer: Human to AI to AI
The interesting part is what happens when you add a second layer.
In vibe coding 1.0, the pattern is linear:
Human -> LLM -> CodeYou talk to an AI. It writes code. You review, iterate, accept. One conversation, one output stream. Your throughput is bounded by that single interaction.
In vibe coding 2.0, the pattern is recursive:
Human -> Orchestrator LLM -> Sub-agent LLMs -> WorkYou're no longer vibing with an AI that writes code. You're vibing with an LLM that vibes with other LLMs. You set intent. Your orchestrator understands the goal, breaks it down, and delegates to sub-agents - each one tackling its own piece of the problem.
This is the dual layer, and it changes the math completely.
In 1.0, your output is bounded by one conversation. In 2.0, your orchestrator fans out. Five agents working in parallel. Ten. Each one operating within the context you've shaped, each one producing work independently.
The throughput increase isn't incremental. It's an order of magnitude.
The Bottleneck Flips
This is perhaps the most counterintuitive part. In vibe coding 1.0, the bottleneck was AI capability. The models weren't good enough, and everyone could feel it. The criticism was justified precisely because the AI was the weak link.
In vibe coding 2.0, the bottleneck flips entirely. The AI is no longer the limiting factor. You are.
Your bandwidth - how fast you can set intent, review output, make judgment calls - becomes the constraint. And the only other limit is economic: how much you're willing to spend on tokens.
Think about what that means. We went from "the AI can't do this well enough" to "the AI can do more than I can absorb." That's not an incremental improvement. That's a phase transition.
It Was Never Really About Coding
Here's the bigger reframe, and the reason I think "vibe coding" was always the wrong name for what's actually happening.
Coding is just one type of output. When your orchestrator LLM delegates to sub-agents, most of what they produce has nothing to do with code:
- Research and analysis. Market research, competitive analysis, legal document review, technical due diligence.
- Business operations. Board meeting preparation, financial summaries, compliance documentation.
- Communication. Email drafts, meeting preparation briefs, client-facing materials.
- Strategy. Product positioning, go-to-market planning, investment analysis.
- Content. Blog posts, presentations, social media, documentation.
- Personal operations. Calendar management, health data analysis, daily briefings.
The code? It's maybe a fraction of the total output. Important, sure. But it's one instrument in the orchestra, not the whole performance.
The pattern - human sets intent, orchestrator delegates, sub-agents execute - works for any knowledge work. The same architecture that spawns a coding agent to build a feature also spawns a research agent to analyze a market, a writing agent to draft a memo, and an operations agent to prepare a board meeting.
This isn't vibe coding. It's vibe working.
How Context Sculpting Makes It Possible
If you've read my previous post, Programming in English: The Agent Is the Runtime, you'll recognize the infrastructure that makes vibe working reliable.
The dual layer doesn't work if the orchestrator is flying blind. It needs structure - a way to understand what's available, what the constraints are, and how to route work effectively. That's what context sculpting provides.
In practice, this means:
An entry point that acts as a routing table. When you express intent to your orchestrator, it needs to know which workflows exist, what each one does, and when to use them. This is a structured markdown file - natural language that the LLM reads and acts on.
Workflows that define how specific tasks get done. Not rigid scripts, but step-by-step procedures with decision points, quality checks, and output expectations. Each sub-agent gets loaded with the workflow relevant to its task.
A knowledge base that grounds the work in domain-specific reality. Company information, style guides, technical specifications, historical decisions. The sub-agents reference this to produce work that's contextually appropriate, not generic.
Think of it this way: context sculpting is the sheet music. The orchestrator LLM is the conductor. The sub-agents are the musicians. And the human? The human is the one who decided what piece to play.
You sculpt the context. The LLM vibes within it. And it spawns more vibes as needed.
The Economics of Vibe Working
The shift from 1.0 to 2.0 also changes the economics.
In vibe coding 1.0, the cost equation is simple: your time plus token costs for one conversation. The human time dominates because you're doing everything - prompting, reviewing, iterating - in a single thread.
In vibe working, human time drops dramatically relative to output. You set intent once, review output at the end, and make judgment calls at key decision points. The token cost goes up (more agents, more parallel work), but the output-per-human-hour goes through the roof.
This creates an interesting dynamic. The constraint shifts from time to budget. If you have more to spend on tokens, you can produce more. If you need to economize, you can route less complex work to smaller, cheaper models while reserving the heavy lifting for more capable ones.
The human role becomes capital allocation as much as creative direction. Where do you invest your tokens? What work justifies the spend? What can be automated versus what needs human judgment?
What This Looks Like Day to Day
This isn't theoretical. Here's what a typical day looks like when you're vibe working instead of vibe coding:
Morning. Your orchestrator has already been working. It checked your calendar, scanned incoming emails, reviewed task queues, and prepared a briefing. You read it over coffee. Ten minutes to get oriented instead of an hour.
Mid-morning. A board meeting is coming up. You tell your orchestrator to prepare materials. It spawns agents: one to pull financial data, one to analyze the legal implications of a specific equity threshold, one to draft the board memo, one to prepare the agenda. You review the output, make judgment calls on tone and emphasis, and sign off.
Afternoon. A client needs a research brief on a logistics integration. You describe what they need. Your orchestrator delegates to a research agent that investigates technical options, a writing agent that drafts the brief, and a review agent that checks for accuracy. You add your industry knowledge and send it.
Throughout the day. Emails get drafted. Presentations get built. Blog posts get researched. Data gets analyzed. You're steering, not rowing.
The coding that happens - and coding does happen, the agents build tools and integrations - is a fraction of your orchestrator's total output on any given day. The rest is knowledge work.
The One-Year Anniversary Question
It's February 2026. One year since Karpathy coined "vibe coding."
The critics were right about 1.0's limitations. The enthusiasts were right about the direction. And both camps are still mostly talking about the wrong thing - whether AI can reliably write code.
The real question isn't whether AI writes good code. It does now, most of the time. The real question is what happens when AI orchestrates AI across every kind of knowledge work.
Vibe coding was the starting point. A useful first step, a catchy name, a necessary experiment.
But the actual shift? The one that changes how we work, not just how we code?
That's vibe working. And it's already here.
This is a follow-up to Programming in English: The Agent Is the Runtime, which describes the context sculpting methodology that makes LLM orchestration reliable and reproducible.