Lately, people keep saying Vibe coding will freeze the progress of programming—turn everyone into prompt jockeys, erode low-level skills, and leave the industry stuck.
I disagree.
Three kinds of problems
Problems in the world come in three kinds.
First, the trivially simple. What is 1+1? No one needs to solve that; it isn’t worth it.
Second, the impossibly hard. How do we trade with extraterrestrial civilizations? How do we achieve immortality? These are so hard that even the shape of the problem isn’t yet clear, let alone the solution.
Third, the in-between. Hard, but not hopeless; solvable, but the solutions aren’t good enough.
Forecasting the next three days of weather—we can do it, but not well enough. Earthquake prediction—we have a bunch of precursor indicators, but no reliable short-term warnings. Early screening for rare diseases—data is scarce, phenotypes vary, and every case looks like an edge case.
Everyday life for ordinary people: how to lay out bus routes in a small city to shorten commutes; a Taobao shop owner deciding how much stock to carry without getting stuck with dead inventory; an indie developer clustering three years of user feedback into a prioritized roadmap.
What these have in common: there’s intuition, and there’s data—often from the same person—but turning that intuition and data into a working system is still too costly.
And it’s precisely the third kind that is most valuable—commercially, scientifically, and for everyday life.
What Vibe coding is doing
For a long time, programmers played the role of modern priests. Only those who knew the incantations could command the machine.
Vibe coding separates the right to implement from the right to define.
Before: you had to be a bricklayer before you were allowed to design a building.
Now: if you can describe the structure and function, the bricks will place themselves.
This isn’t a loss of capability; it’s a restructuring of the production stack—a renaissance in software development. When the barrier to writing code drops to zero, the real barrier becomes your depth of understanding of the problem.
Vibe coding reduces the friction of turning ideas into runnable systems.
That friction used to be an invisible filter. It’s not that no one wanted to tackle in-between problems; it’s that those who wanted to lacked a cheap way to ship an engineering proof. A geologist has a hunch about earthquake precursors but can’t find a programmer to partner for six months. An ER doctor has observations about early sepsis markers but can’t write a model that runs.
And it’s not just experts. A restaurant owner wants an auto-scheduler that accounts for each employee’s commute and class schedule; in the past they would brute-force it in Excel—now they can state the requirements and let the schedule grow itself. A parent wants a vocabulary app that reviews along the forgetting curve—before, they needed three months of Swift; now they don’t.
Everyone is the expert of their own life. In their own domain, everyone has a pile of “I know how this should work but I can’t automate it” problems. Vibe coding lets code finally touch these problems for the first time.
If coding is like photography, Vibe coding is the spread of smartphone photography. It makes film aficionados rarer and more specialized, while letting countless people who might never have taken a photo capture decisive moments in their lives.
So Vibe coding is really a continuation of “software eating the world”—it answers more in-between problems and pushes humanity toward boundaries that used to be out of reach.
What changes is quantity—and topology
The problems software could reach used to be shaped like “things engineers can model.” After Vibe coding, the shape becomes “things anyone can describe.”
The difference between these sets is vast. It covers climate and ecosystem models scientists can’t formalize, clinicians’ tacit knowledge, and all the everyday problems that are “too small to hire a programmer, too complex for Excel.” A geologist, an ER doctor, a bubble-tea shop owner—they all enter the solution space. This isn’t just more area; the topology has changed.
Think one layer deeper. The rate of scientific progress is essentially “hypothesis generation rate × hypothesis validation rate.” If validating an idea goes from a 6‑month engineering cycle to 6 hours, we can run more iterations of being wrong in the same window—and the density of error is the only path to truth.
Vibe coding accelerates the scientific method; it does not replace it.
The real risks
As a software engineer, I’m not worried about my job. The systemic slide toward disorder will still keep us busy.
Vibe coding produces code far faster than humans can review it. If three teammates are all coding with AI, no one can read everything it generates. When it’s merged, everyone thinks “it runs,” and three months later a bug surfaces and no one knows where that logic came from.
The new problems stem from unobservability. They call for new tools. Our role shifts from creating order to fighting entropy. We need a new class of auditing tools, not just debugging tools.
Broader risks lie outside software. As the solution space expands, the density of low-quality solutions rises.
A geologist’s Vibe-coded earthquake model will likely be statistically wrong, but it runs, produces outputs, and makes charts. That can create the illusion that “the problem is solved,” which may block better solutions from view.
More precisely: Vibe coding speeds up the production of candidate solutions without simultaneously improving the mechanisms that filter for quality. That gap is likely the next real battleground.
It doesn’t lock programming
“The computer gets locked by Vibe coding” makes a classic mistake: equating the diffusion of tools with a cap on the ceiling.
With every rise in abstraction—assembly to C, C to high-level languages, languages to frameworks—people said low-level engineers would disappear. Instead, demand at the bottom grew because the top exploded. Vibe coding is the same: it will produce a flood of systems that run but run poorly, and those systems will intensify demand for people who truly understand the foundations.
What it really changes is the value distribution of “programming ability”:
- The ability to produce code is depreciating.
- The ability to verify code, understand system behavior, and judge whether a system actually solves the problem is appreciating.
Real engineers will shift from “people who write code” to “people who can tell whether a pile of code truly solves the problem.”
This isn’t a lock.
It’s acceleration—accelerating the digestion of the existing solution space and bringing more unknown terrain into range. The solution space should never have been monopolized by engineering skill in the first place.