Vibe Coding Isn't Lazy, Real Engineering Isn't Obsolete — The Real Problem Is Stage Mismatch
> "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 for two weeks over vibe coding. On one side: senior engineers insisting that every piece of code be reviewed, every interface tested, and architecture docs updated. On the other: a developer with two years of experience who used Cursor to build a working demo in three days — complete features, polished UI.
The question at stake: is vibe coding "real engineering"?
Two weeks later, the demo collapsed on real data — no error handling, no boundary checks, one edge case locked up the database. Meanwhile, the seniors' "perfect solution" hadn't finished its first version, and a competitor had shipped a month earlier.
Where did it go wrong? Both sides made the same mistake: they assumed vibe coding and Real Engineering are binary choices on the same dimension. They're not. They're tools for different stages — like using a screwdriver on a nut, or a wrench to chop vegetables.
---
What Karpathy's Own Shift Tells Us
In February 2025, Karpathy tweeted his definition of 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 over."
Not because he opposed 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.
Vibe coding in 2025 was for side projects, demos, and validating ideas. Back then, LLMs couldn't handle large-scale production code, so the vibe's natural boundaries limited its risk — it was just toy projects anyway.
By 2026, LLMs could refactor 100k-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 flipped. Agents had crossed a threshold.
Once a threshold is crossed, the tool no longer belongs to the playground. When AI can write production-grade code, vibe coding's looseness becomes liabilities — security flaws silently lurk, technical debt compounds exponentially.
So Karpathy proposed a replacement term: Agentic Engineering. Not "stop using AI to write code," but "when you use AI to write code, apply engineering discipline."
---
Jagged Intelligence: Why Some Tasks Can Be Vibed and Others Can't
Karpathy introduced a concept many people missed: Jagged Intelligence.
An LLM's capability distribution isn't a smooth curve — it's jagged. Superhumanly strong in some domains, absurdly dumb in others. It can refactor a hundred thousand lines of code but might fail to plan a walk from a parking lot to a car wash.
Where does this jaggedness come from? LLM post-training uses RLHF, and RL reward signals concentrate in domains with verifiable outputs: math, code, logic puzzles. Correct answers are deterministic there, so the models get reinforced extremely well. But many real-world tasks lack deterministic verification — they require common sense, physical intuition, and understanding of human behavior.
What does this mean?
Tasks on the jagged peaks: vibe coding works. The model's accuracy is high enough to produce "useful errors" — even when it's occasionally wrong, you spot and fix it quickly.
Tasks in the jagged valleys: vibe coding fails. The model will be confidently wrong, 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 | | Frontend styling tweaks | Long-term database schema evolution planning | | Code refactoring (with test coverage) | Mapping cross-system dependencies | | Writing doc comments | Defining API backward-compatibility strategies |
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 initial framing of "exploration vs. delivery" is good, but it can go finer. What really determines whether you vibe or engineer isn't "is it finished" — it's the cost of failure, the cost of rollback, and how much taste is required.
I expand it into a four-stage spectrum:
Stage 1: Personal Sandbox
Traits: Only you use it. If it breaks, it breaks. Throw it away and start over anytime. Tools: Full vibe coding. Cursor Composer, Claude Code, any agent — whatever's fastest. Floor: No floor, because you are the floor. You can always say "this won't do, re-vibe it."Example: A weekend tool that turns voice into notes. Two hours of vibe coding — use it if it works, drop it if it doesn't.
Stage 2: Team Tooling
Traits: At least two people use it. Code goes into git. Others must be able to read it and pick it up. Tools: Vibe coding + minimal engineering constraints. The four principles of CLAUDE.md are for this stage. Floor: Basic readability, tests on critical paths, no obvious security holes.Example: An internal data-analysis script. An agent generates v1, but a human reviews the data-processing logic to ensure it won't delete data by mistake.
Stage 3: User-Facing Feature
Traits: Real users. Bugs generate support tickets. UX is directly affected. Tools: Agentic Engineering. AI writes code, but humans own architecture decisions, edge-case review, and performance assessment. Floor: Complete error handling, observable logging, clear rollback strategy, basic load testing.Example: An e-commerce payment flow. An agent can generate payment API boilerplate, but idempotency design, timeout-retry strategy, and reconciliation logic must have human sign-off.
Stage 4: Core Infrastructure
Traits: If the system goes down, the business stops. Data loss is unrecoverable. Security flaws cause real damage. Tools: Real Engineering first, AI as an accelerator. AI can speed up writing but cannot replace design review, security audits, or chaos testing. Floor: 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 "when it 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 doesn't mean sloppy 2. Avoid unnecessary abstractions — don't add complexity for "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 be verified
These four principles are so ordinary that no serious engineer would object. But it's precisely this most basic engineering common sense that got ignored in the vibe coding party.
CLAUDE.md's popularity reveals something: developers aren't against AI writing code — they're against unconstrained AI-written code. Just as you wouldn't let an intern push straight to main, you shouldn't let agents 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 Switch Signals: When to Move from Vibe to Engineering
Knowing the spectrum model is one thing; knowing "where am I right now" is another. Here are 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, payments)
- Bugs require hotfixes, not "re-vibing"
- Outages affect company revenue
- Compliance requirements apply (SOC2, GDPR, HIPAA)
- Multiple business lines depend on the code; changes cascade
- "Immediately, because I'm watching the output" — vibe stage
- "Users will tell me" — time for engineering
- "When the news reports it" — time for Real Engineering
- Over-engineering when you need to vibe — a three-day idea forced through two weeks of documentation
- Vibing when you need to engineer — 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 on v1 meant they jumped to Stage 4 before even clearing Stage 1
Signals to move from team tooling to user-facing feature:
Signals to move from user-facing feature to core infrastructure:
An even simpler test: ask yourself "if this code breaks right now, when is the latest I'd find out?"
---
The Real Enemy Isn't Vibe, and It Isn't Engineering Either
Online debates about vibe coding mostly center on "is vibe real coding" or "are traditional engineers dinosaurs." Both debates are wrong.
The real enemy is stage mismatch:
Karpathy put it clearly: "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 energy from typing to judgment. Agents execute; 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 hit stop.
---
Closing: Where Does Your Task Sit?
Back to that arguing team from the start. If they'd read this, they might realize:
Figure out which stage your work belongs to, then pick the matching tools. That's how adults write code.
---
*Originally published in Chinese on zhichai.net.*