> "You can outsource your thinking, but you cannot outsource your understanding." — Andrej Karpathy
---
A True Story
In the spring of 2025, I watched a team argue about vibe coding for two weeks. On one side: senior engineers insisting every piece of code be reviewed, every API tested, architecture docs kept up to date. On the other: developers two years into their careers who built a working demo with Cursor in three days — complete features, polished UI.
What was the argument about? Whether vibe coding counts as "real engineering."
Two weeks later, the demo crashed on real data — no error handling, no boundary checks, one edge case deadlocked the database. Meanwhile, the senior engineers' "perfect solution" hadn't finished its first version, and a competitor had already shipped a month earlier.
Where did things go wrong? Both sides made the same mistake: they assumed vibe coding and Real Engineering are alternatives on the same dimension. They're not. They are tools for different stages — you can't tighten a nut with a screwdriver, and you can't chop vegetables with a wrench.
---
What Karpathy's Own Pivot Tells Us
In February 2025, Karpathy defined vibe coding: "Fully give in to the vibes... forget that the code even exists."
In May 2026, on stage at Sequoia AI Ascent, he said: "vibe coding is outdated."
Not because he rejected the idea — quite the opposite, he was one of its earliest beneficiaries. His shift reveals one thing: the tool didn't change, the context did.
In 2025, vibe coding was for side projects, demos, and idea validation. LLMs weren't capable enough for large-scale production code, so the vibe's natural boundaries limited the risk — they were toy projects anyway.
By 2026, LLMs could refactor 100,000-line codebases, find zero-day vulnerabilities, and write complete feature modules. Karpathy himself said that in November 2025 he wrote 80% of his code with AI assisting 20%; by December the ratio had inverted. Agents crossed a capability threshold.
Once the threshold is crossed, the tool no longer belongs only to the playground. When AI can write production-grade code, the casualness of vibe coding becomes a liability — security vulnerabilities lurk silently, technical debt compounds exponentially.
Hence Karpathy's replacement term: Agentic Engineering. Not "stop using AI to write code," but "when AI writes code, apply engineering discipline."
---
Jagged Intelligence: Why Some Tasks Can Be Vibed and Some Can't
Karpathy proposed a concept many people overlook: Jagged Intelligence.
LLM capabilities aren't a smooth curve but a jagged profile — absurdly strong in some domains, shockingly weak in others. It can refactor a hundred thousand lines of code but may fail to plan a route from a parking lot to a car wash.
Where does the jaggedness come from? LLM post-training uses RLHF, and RL reward signals concentrate in domains with verifiable outputs: math, code, logic puzzles. These have definite correct answers, so models get reinforced extremely well there. But many real-world tasks have no definitive verification standard — they require common sense, physical intuition, understanding of human behavior.
What does this mean?
Tasks on the jagged peaks: vibe coding works. Model accuracy is high enough to produce "useful errors" — even when wrong, you can spot and fix it quickly.
Tasks in the jagged valleys: vibe coding fails. The model is confidently wrong here, and you may not realize it until disaster strikes.
Concrete examples:
| On the peaks | In the valleys | |---------|---------| | Generating standard CRUD endpoints | Designing distributed consensus protocols | | Writing unit tests | Judging exploit paths for security vulnerabilities | | Front-end styling tweaks | Long-term database schema evolution planning | | Code refactoring (with test coverage) | Mapping cross-system dependencies | | Writing documentation comments | Defining API backward-compatibility strategy |
The test is simple: if a task's correctness can be verified by automated tests, it's probably on a peak. If it requires human judgment, experience, and taste, it's in a valley.
---
The Stage Spectrum: Not a Binary, But Four Quadrants
The original framing was "exploration vs. delivery," which is good but can be finer-grained. What really determines whether you vibe or engineer isn't "is it done" — it's the cost of failure, the cost of rollback, and how much taste the task demands.
I've expanded this into a four-stage spectrum:
Stage 1: Personal Sandbox
Characteristics: Only you use it; if it breaks, throw it away and start over. Tools: Full vibe coding. Cursor Composer, Claude Code, whatever agent — optimize for speed. Bottom line: No bottom line, because you are the bottom line. You can always say "this doesn't work, re-vibe it."Example: A weekend tool that turns voice into notes. Vibe coding gets it up in two hours — use it if it works, drop it if not.
Stage 2: Team Tooling
Characteristics: At least two people use it; code goes into git; others must be able to read and build on it. Tools: Vibe coding + minimal engineering constraints. The four CLAUDE.md principles are exactly for this stage. Bottom line: Basic readability, tests on critical paths, no obvious security holes.Example: An internal data analysis script. Agent generates the first version, but a human reviews the data-processing logic to ensure nothing gets deleted by mistake.
Stage 3: User-Facing Feature
Characteristics: Real users, support tickets, direct impact on user experience. Tools: Agentic Engineering. AI-assisted code, but humans own architecture decisions, edge-case review, and performance assessment. Bottom line: Complete error handling, observable logs, clear rollback strategy, basic load testing.Example: An e-commerce payment flow. Agents can generate payment API boilerplate, but idempotency design, timeout/retry strategy, and reconciliation logic require human review.
Stage 4: Core Infrastructure
Characteristics: If the system goes down, the business stops; data loss is unrecoverable; security vulnerabilities cause real damage. Tools: Real Engineering first, AI assistance second. AI can accelerate writing but can't replace design review, security audits, or chaos testing. Bottom line: Formal verification, multi-round review, compliance audits, disaster recovery drills.Example: A financial ledger service, a medical data storage layer, an authentication system. These aren't vibe questions — they're "if this fails, it makes the news" questions.
---
CLAUDE.md: Drawing a Boundary Line Around Vibe
In April 2026, a 65-line markdown file hit 100k stars on GitHub. It's called CLAUDE.md, and its core is just four principles:
1. Prefer simple, minimal implementations — don't over-engineer, but simple ≠ careless 2. Avoid unnecessary abstractions — don't add complexity in the name of "elegance" 3. Write clear, explicit code — code is for humans to read, not for agents to show off 4. Add tests for critical paths — critical logic must have verification
These principles are so ordinary that no serious engineer would object. Yet it was precisely this most basic engineering common sense that got ignored during the vibe coding party.
CLAUDE.md's popularity proves one thing: developers aren't against AI writing code — they're against unconstrained AI writing code. Just as you wouldn't let an intern push directly to main, you shouldn't let an agent produce code without constraints.
It's not vibe coding's enemy; it's vibe coding's guardrail. A highway without guardrails isn't freedom — it's suicide.
---
Actionable Switching Signals: When to Move from Vibe to Engineering
Knowing the spectrum model is one thing; knowing "where am I right now" is another. Some concrete signals:
Signals to move from personal exploration to team tooling:
- Someone asks "how do I run this code?"
- You need to deploy on another machine
- You want to share the code with colleagues
- Real users exist (even just beta testers)
- The code starts handling sensitive data (user info, payment info)
- Bugs require hotfixes rather than "re-vibing"
- Outages affect company revenue
- Compliance requirements apply (SOC2, GDPR, HIPAA)
- Multiple business lines depend on the code; changes have cascading effects
- "Immediately — I'm watching the output" → vibe stage
- "Users will tell me" → time for engineering
- "When it hits the news" → time for Real Engineering
- Over-engineering when you need to vibe — spending two weeks writing docs for an idea that could be validated in three days
- Hardcore vibing when you need engineering — core systems with no tests, no review, no rollback strategy
- The three-day demo belonged to Stage 1 — vibing was correct; the mistake was treating it as Stage 3
- The "perfect solution" stuck at version one had jumped to Stage 4 without even passing Stage 1
Signals to move from team tooling to user-facing features:
Signals to move from user-facing features to core infrastructure:
An even simpler test: ask yourself "if this code breaks right now, when would I find out at the latest?"
---
The Real Enemy Is Neither Vibe Nor Engineering
Most online debates about vibe coding focus on "is vibe even real coding" or "are traditional engineers dinosaurs." Both debates miss the point.
The real enemy is stage mismatch:
As Karpathy put it: "Agentic engineering is about preserving the quality bar of what existed before in professional software."
The goal isn't writing less code — it's shifting human effort from typing to judgment. Agents handle execution; humans own taste, boundary judgment, and failure-mode recognition. The best agentic engineers aren't the fastest typists — they're the ones who understand the most: they know what they want, how the agent will fail, and when to call a stop.
---
Closing: Where Does Your Task Sit?
Back to that arguing team from the beginning. If they had read this, they might realize:
Figure out which stage your task belongs to, then pick the matching tools. That's how adults write code.
---
*Translated from the original Chinese forum post.*