It's less dramatic than either the boosters or the doom-sayers want.
The software developer's job isn't going away. It's being hollowed out at the bottom and pushed up at the top. The hands-on work of typing code is moving to . What's left for the human is the work that was always the harder part: deciding what to build, designing how it fits together, and judging whether what came back is any good. For people who already do that well, the result is a big multiplier on their output. For the industry as a whole, there's a structural problem hiding underneath the productivity story: how anyone becomes good in the first place.
The role moves from writing code to directing systems and reviewing what comes back.
I'm not a working programmer, which is either a disqualification or a useful vantage point. I spent 20 years in data engineering and recently built and deployed a real web application without writing the code myself, by directing agents. So I've watched the bottom of this ladder dissolve from the outside, as someone who could never have climbed it the old way and now can.
You've probably written your last unassisted line
When Andrej Karpathy moved past "" (the term he himself coined in early 2025) to "" in February 2026, his framing was that the new default is not writing code directly 99% of the time; you orchestrate agents who do, and you act as oversight . Three years earlier he'd predicted that the hottest new programming language would be English . Both have largely come true for a lot of working developers. If you write software professionally, you've likely already written your last line of code without AI assistance. Increasingly you'll review agent-authored code rather than produce it by hand.
Authorship gives way to oversight
The unit of work shifts from "write the function" to "review the diff, catch the error, feed the correction back into the agent's rules." Diff review becomes the main event rather than a box ticked at the end of a pull request. It's where seniors catch bad practices before they compound across a whole fleet of agents.
For anyone who can already do the harder parts, this is a promotion dressed as a threat. What it changes is the definition of being good at the job.
The skills that matter now
The work that keeps its value is the work agents are worst at, and it sits a level above typing.
| What shrinks | What grows |
|---|---|
| Writing boilerplate and glue code; remembering syntax; producing first-draft implementations; debugging routine, well-understood bugs. These were never the scarce skills, and they're now close to free. | Systems design and architecture; reading diffs critically and fast; talking to business users to work out what they need, not just what they asked for; managing a fleet of agents and stepping in for judgment calls; knowing when an approach is wrong before it's built. |
The upside is real, and worth being concrete about. A good developer who hands the typing to agents and spends the freed time on the hard parts can multiply their output. The backlog that's haunted a team for years gets cleared in weeks. The tech debt nobody had time to pay down: the agents don't mind refactoring. And someone who couldn't build at all, like me, goes from impossible to possible.
For the machinery that makes "managing a fleet of agents" a real skill rather than a slogan, see:
The uncomfortable question
If good developers multiply their output, and non-developers can now build things they couldn't before, how many developers does an organization need? When the backlogs are cleared and the debt is paid, what's the steady-state demand? I don't have a confident answer, and I'm suspicious of anyone who does.
Headcount is the obvious worry. The pipeline worries me more.
The broken apprenticeship
Juniors have always learned the craft by doing the work that agents now do: the small bugs, the boilerplate, the first drafts. If that rung is gone, how does anyone become a senior? Seniors are the ones who can tell when an agent's output is wrong. If we stop producing them, the whole oversight model runs out of people who can do the overseeing. This is the part the industry has not solved.
There's a plausible answer, and it's the one I'd bet on: the apprenticeship moves to diff review. Reviewing agent-authored code is a good way to learn: you see real patterns, real mistakes, and real solutions in context, at a scale no human mentor could produce by hand. Code review as a teaching tool, at scale. That's a hope more than a plan, though. We need a deliberate career path for juniors, and right now one mostly doesn't exist. Without it, we get one more generation of seniors and then none after them.
The new risks nobody priced in
Speed creates its own problems, and they're rarely the ones people warn about.
Review debt replaces tech debt
When building is this fast, you don't reduce tech debt; you trade it for review debt: mountains of agent-authored code that nobody truly understands. After hundreds of agent commits, a codebase drifts in ways neither you nor the agent fully tracks. More code also means more attack surface. And feature creep stops being a metaphor when adding a feature costs an afternoon of someone's half-attention.
Agents also have no eyes, which is easy to forget. Browser-automation testing catches functional bugs, but it cannot judge whether a layout is good, whether spacing is right, whether an interaction feels sensible. Anything spatial and mouse-heavy (boards, diagrams, visual editors) is both hard for agents to build well and nearly impossible for them to test. Those features still need a human looking at them, and that human is a scarce resource you're now spending on review instead of creation.
Fixing it is dull and well understood: regular testing cycles, real code review, refactoring passes, and real users early. Vibe coding lets you skip exactly the discipline that keeps the result from rotting.
What happens to software itself
The role changes because the economics of software change underneath it. A few predictions, mine, clearly labeled as guesses.
The value of pre-written code is falling. Why pay for internal, non-critical software that locks you into a vendor and charges extra for every customization, when an agent can build the custom version? I expect a split. vendors will increasingly sell API, , and agent-to-agent access (the data and the business logic, the hard parts) while the layer becomes free, open source, or built to order by your own agents.
Pay for the backend, not the buttons
The interface becomes a commodity you generate. What you pay for is data, an agreed quality level, an SLA, and someone accountable. Commodity SaaS races to the bottom on per-seat pricing; the survivors charge for outcomes (leads converted, campaigns shipped), not seats.
The strategy-side companion to this prediction:
The defensive countermove is obvious: vendors locking your data inside their platforms, so that even when the interface is free, leaving is expensive. Data lock-in becomes the moat when code stops being one. Meanwhile, interfaces themselves get more volatile: assembled from multiple backends, tailored to one use case, built at near-zero cost and thrown away when the use case changes. As more single-purpose, single-org software gets spun up, hosting and platforms matter more, not less.
And then there's cost, which underwrites all of it. Agentic coding is cheap right now, almost certainly because the providers are subsidizing it to drive adoption. The open question is whether that lasts. If the cheap coding plans give way to metered API pricing, the economics change sharply. The counter-pressure is that capable models, many from Chinese labs, keep getting better, which makes it hard for any provider to raise prices much without losing customers. How long until "good enough" runs on your own hardware for free? Nobody knows, and the answer reshapes everything above it.
How that cost is actually distributed inside a session, and the tool-output drain most people miss:
The strongest objections
The case against all this deserves a hearing, and some of it lands.
The quality objection, that code you didn't write and may not have reviewed shouldn't go to production, is the right instinct. But it proves less than it claims.
The audit question
How much of the code in the apps you use every day have you personally audited? Realistically, none. You trust them because they work and someone is accountable for them. That's the same standard agent-authored code should meet: not "did a human type it" but "is it reviewed, tested, and owned."
Two more points cut against the pessimism. Most modern applications aren't dense original logic; they're glue: wiring together frameworks, libraries, and . The novel business logic is a small fraction, and agents are very good at the glue. And reviewing agent output, like reviewing a junior's pull request, is fast next to the cost of a bad merge. The tooling for it keeps improving. Trust but verify; the checking is cheap.
None of that dissolves the pipeline problem or the review-debt problem. The real risk was never bad code. It's that we build too much of it, too fast, for too few people to understand, with too few coming up behind who could. Those are management and institutional problems rather than model problems, which is its own kind of bad news, because we're worse at solving them.
A better job, with a hole in it
I don't think agents replace programmers; I think they enable everyone else, and they change what being a programmer means. The role moves from writing code to directing systems and reviewing what comes back. For people who can think in systems and explain themselves clearly, that's a better job than the one before.
There's a hole in that, though. The seniors doing the overseeing today learned by doing the work agents now do. If reviewing diffs really is the new apprenticeship, someone has to design that path on purpose, because it won't appear by itself. Until then the productivity is real, the multiplier is real, and the question of where the next round of judgment comes from stays wide open.
No model release fixes that one. The people running teams and hiring juniors have to.
Final thought
We've automated the rung of the ladder people used to climb to learn the craft, and nothing has replaced it.
References
- 1The New Stack, "Vibe coding is passé. Karpathy has a new name for the future of software." (Andrej Karpathy reframes "vibe coding", a term he coined in early 2025, as "agentic engineering" in February 2026: orchestrating agents and acting as oversight rather than writing code directly; and his earlier prediction that "the hottest new programming language is English"). thenewstack.io ↗