In February 2025, Andrej Karpathy gave a name to something a lot of people had quietly started doing: vibe coding. You describe what you want, the model writes it, you run it, and — in the purest form — you don’t really read the code. You “give in to the vibes,” accept the diffs, and steer by results. It was half a joke. It stopped being a joke almost immediately.
So here is the uncomfortable question for anyone whose job is typing code for a living: if a machine can produce the code, what is the programmer for?
What actually shrinks
Be honest about the parts of the job that are already evaporating. The boilerplate. The fortieth CRUD endpoint. Remembering the exact argparse incantation, the CSS flexbox trick, the regex you look up every single time. The glue between two libraries. For a huge fraction of everyday code, the model is faster than you, doesn’t get bored, and doesn’t typo the variable name. Pretending otherwise is nostalgia.
The 70% problem
But watch what happens on real work. The model gets you 70% of the way in about 10% of the time — and then the last 30% is where the entire game lives. The edge case nobody described. The integration that “should just work” and doesn’t. The subtle correctness bug that passes every test you thought to write. The security hole in the auth flow. The performance cliff at 10x scale.
That last 30% has a prerequisite the vibe can’t supply: someone who actually understands the system. You cannot debug what you never comprehended. You cannot review a diff you don’t have the taste to judge. The failure mode of pure vibe coding isn’t that the code doesn’t run — it’s that it runs just well enough to ship, and then breaks in production in a way no one on the team can explain, because no one on the team ever read it.
From author to director
The role doesn’t disappear. It moves up the stack. The programmer’s centre of gravity shifts from writing to:
- Specification. Turning a fuzzy human want into an unambiguous description a machine can execute. This is genuinely hard and genuinely valuable — most of software’s failures were always failures of specification, not syntax.
- Decomposition. Breaking a system into pieces small and clear enough that the model succeeds on each, and knowing where the seams go.
- Verification. Reading, testing, and adversarially probing what the machine produced — and having the taste to know when “looks fine” isn’t fine.
- Architecture and judgment. What to build, what to not build, which trade-off, which dependency, what happens under load, what happens under attack.
- Accountability. Someone has to own the output. The machine doesn’t get fired.
The closest old analogy is the shift from bricklayer to architect who also inspects the build. You still need to know how bricks work — deeply — or you can’t tell a load-bearing wall from a decorative one. But you spend your hours on the drawing and the walk-through, not the trowel.
The real risk
The danger isn’t that AI replaces programmers. It’s skill atrophy — a generation that can prompt but can’t reason about what comes back, accepting code they couldn’t have written and can’t debug. The engineers who thrive will treat the model like a phenomenally fast, tireless, occasionally-confidently-wrong junior: they’ll delegate aggressively and verify relentlessly. The ones who struggle will delegate and trust.
Why this is good news
For most of history, “I have an idea for software” and “I can build software” were separated by years of training. That wall is coming down. More people will build more things, and the floor of what a single motivated person can ship is rising fast.
And at the top, the best engineers aren’t being replaced — they’re being amplified. Judgment, taste, and the ability to hold a whole system in your head were always the scarce, high-leverage skills. Vibe coding just stripped away the typing and left the thinking exposed. That was always the actual job.