Vibe coding — writing software by telling an AI what you want and mostly saying 'yeah that's right' until something works — has the internet in a tizzy. Critics say it's unmaintainable garbage. Advocates say it's the future. Here's the actual analysis.
Vibe Coding Is Not a Bug — It's the Whole Point
In February 2025, Andrej Karpathy coined the term "vibe coding" and the internet had a minor meltdown. Developers were celebrating. Researchers were panicking. Tech Twitter did what Tech Twitter does best: turned a two-word phrase into a three-week culture war.
Here's the vibe-coded definition, since we're being precise: vibe coding is writing software by telling an AI what you want, then mostly just saying "yeah that's right" or "no, different" until something works.
No PR reviews. No architecture diagrams. No pair programming. Just you, a prompt, and a lot of tab-completion faith.
The critique army mobilized immediately. "This isn't real engineering." "The code will be unmaintainable garbage." "You're just rubber-stamping AI slop." And look — they're not entirely wrong. The code that comes out of vibe coding sessions is often chaotic. Variable names might be weird. The architecture might be "what happens when you let a talented but slightly manic architect loose for 20 minutes." There might be entire files that serve no documented purpose.
But here's what the critics are missing: that chaos is not a side effect. It's the product.
The Job Title Changed. Nobody Told the Job Description.
We keep pretending that "software engineer" means what it meant in 2010. Write code. Review code. Merge code. Push to prod on Friday at 4:55 PM and hope nothing breaks over the weekend.
That job still exists. But it's not the job that's winning anymore.
The job that's winning looks like this: understand a domain, define what good looks like, write just enough prompt to get an AI to build toward that definition, evaluate the output, give feedback, iterate. Repeat until the thing does what it's supposed to do.
#Vibe Coding#AI编程
Notice what's missing from that list: actually typing the code.
The highest-leverage activity in software development is no longer writing code. It's defining the problem.
This is deeply uncomfortable for people who got into software engineering because they liked typing. Code was the craft. The act of typing — the feeling of the keyboard, the flow state of a refactor, the satisfaction of a clever algorithm — that was the thing. If you're vibe coding, you're not doing that part.
But let's be honest about who we're describing. Not every developer is a craftsman trapped in a code factory. Most developers are building internal tools, MVPs, automation scripts, prototypes, integrations. For them, the code was never the point. The code was the means to an end. And if AI can handle the means more efficiently, that's not a tragedy — that's progress.
The Maintainability Apocalypse Is Real. So Is the Alternative.
Okay. The serious critique. Vibe-coded codebases become unreadable nightmare mazes within about six months. Nobody understands the code. Nobody can safely change anything. The original author has moved on. The AI that wrote it has a different personality now. You're left with a system that technically works but is too dangerous to touch.
This is a real problem. I've seen it. You've probably seen it too.
But the alternative the critics imagine — "proper" engineering, architecture astronauts, 47-layer abstraction systems — is often just as unmaintainable, for different reasons. Enterprise Java codebases from 2015 have abstraction layers that exist because of a meeting, not because of a technical need. They have "enterprise patterns" that nobody can explain without a 45-minute context load. They are absolutely not easier to maintain than vibe-coded code.
The question isn't "vibe code vs. clean architecture." The question is "what's the actual cost of each approach at the scale of the problem I'm solving."
A three-person startup building an MVP does not need the same code quality as a 500-engineer team maintaining a payments system. Vibe coding is wrong for the latter and possibly right for the former. The industry has been pretending these are the same question.
Who Gets Hurt When We Don't Look
There's a version of this essay where I just celebrate vibe coding and tell the haters to cope. That's not the full picture, though.
The people most excited about vibe coding are experienced developers who have enough judgment to know when the output is garbage and enough leverage to push back. They can prompt, evaluate, and course-correct in real time. They're not rubber-stamping — they're conducting.
The people most at risk are everyone else. Junior developers who don't know what good looks like, so they can't tell when the AI is producing confident nonsense. Developers in high-pressure environments where "ship it now" overrides "understand it first." Entire categories of work — debugging, security hardening, performance optimization — that vibe coding does not help with and may actively worsen.
When you don't write the code yourself, you don't develop the intuition for when the code is lying to you.
This isn't an argument against vibe coding. It's a map of where the bodies are buried. Use the tools. But know which end is the sharp end.
The Actual Competitive Moat Has Shifted
Here's what nobody wants to admit: for a certain class of work, the barrier to entry just collapsed completely. A solo developer with good product sense and access to vibe coding tools can now build things that would have required a 10-person team three years ago.
This should terrify the bottom 80% of the developer market and liberate everyone else.
The developers who should be terrified: anyone whose main skill is translating well-understood requirements into code. That's mechanical. That's what LLMs do. If that's the entirety of your value, you have a problem.
The developers who should feel liberated: anyone who can figure out what to build, why to build it, and whether it works. AI handles the how. You handle the what and the why. That was always the harder question anyway.
The moat was never typing. The moat was knowing what to type.
Vibe Coding Is a Mirror, Not a Trend
Every few years the software industry goes through a crisis of identity. Are we engineers or artists? Craftsmen or productivity workers? Builders or collaborators?
Vibe coding is forcing this conversation again, but with a twist: this time, the machine is in the room.
The people who find vibe coding empowering tend to be the ones who were always more interested in outcomes than process. They never cared about the craft of typing — they cared about the craft of solving problems. They just had to type to get there.
The people who find vibe coding offensive tend to be the ones for whom the code was the point. The craft itself was the reward. Not the shipped product, not the user impact — the act of writing elegant code. For them, vibe coding is not just a workflow change. It's an existential reframe.
Both reactions are valid. Neither is universal.
The industry will not settle this debate. The market will.
As vibe-coded products succeed or fail; as vibe-coded startups scale or crumble; as maintenance nightmares crystallize or get refactored into oblivion — we'll learn, as an industry, where the boundaries are. Not through think-pieces. Through consequences.
In the meantime: use the tools, know your stakes, ship the thing.
