There's a sentiment going around that you can fire your engineering team, spin up a swarm of AI agents, and ship better software faster. I get the appeal, but anyone who believes it has fundamentally misunderstood what software development actually involves.
Keystrokes were never the point
For a long time, a software developer's day was mostly writing code, simply because translating thought into working software took time. You had to type it, debug it, look things up, type it again. The ratio was skewed toward typing by necessity, not by where the value actually lived.
LLMs have changed that ratio dramatically. A developer using Claude Code or a similar tool can produce in an hour what used to take a day. The typing is handled, which means the thinking, the part that was always the actual job, now gets the time it deserves.
If your job was mostly typing, you were always one productivity improvement away from being redundant, and AI just made that improvement real.
The agent swarm problem
Replace a team of thirty developers with a swarm of agents running on a stack of Mac Minis, and you haven't eliminated the coordination overhead, you've concentrated it. Every agent still needs direction, every output still needs judgment. You've gone from distributed decision-making across a team of experienced people to a single bottleneck with a lot of compute underneath it.
The person who does this hasn't automated software development, they've automated typing. And in doing so, they've made themselves the sole owner of everything that typing was never responsible for: figuring out what to build, understanding the customer, making architectural calls that won't hurt you in two years, and knowing when "done" is actually good enough versus when it isn't.
That's not a lighter workload, it's a harder one.
What AI doesn't know
AI generates code that works, and it also generates code that passes review, ships to production, and quietly accumulates debt. The difference between those two things lives in someone's head, not in a prompt. It's the developer who knows why a particular shortcut is fine here and catastrophic there, or who has talked to enough customers to know which edge case actually matters.
That context doesn't exist in a context file. Some of it can be written down, but most of it can't. The value a strong developer brings to a product isn't typing speed, it's proximity to the problem over time.
The junior-to-senior problem is real
Here's where I'm on less solid ground, and I want to be honest: this is gut feeling, not research.
We learned to code by writing code. Senior developers know what to build because they spent years writing things that didn't work, or worked but were wrong, and figuring out why. That path from junior to senior is fundamentally about developing judgment, not just accumulating technical knowledge. And judgment comes from being wrong enough times that you start to recognize the patterns.
If there are no more junior roles, because agents handle implementation and companies stop hiring people to type, then the pipeline that produces senior developers breaks. The ones we have now got here through a path that may not exist in five years. I don't know what replaces it, but I don't think the answer is a slightly adjusted version of what we have now. What a developer is, and what their job actually involves, may look fundamentally different, and the path to getting good at it will probably have to change just as much.
Smart companies will still want smart people
Some companies will let people go, and some already are. The ones who were better at typing than thinking will go first, and I think that's probably correct even if it's uncomfortable to say. A developer who can't tell you why a feature needed to exist, only that it matched the spec, was always more fragile than they appeared.
But a company that fires its best people because the agents can type faster has confused output with value. The developers who spend their time talking to customers, arguing about product direction, and caring about what gets built and why, those people don't become less valuable when the typing gets faster. They become more valuable, because now the thinking is the constraint.
A smart software company, one that actually wants to build a better product for the people it serves, is going to want more of that kind of thinking, not less. The ratio shifts, but the work doesn't disappear.
A note on scope
Most of this applies to teams building products. SaaS companies, developer tools, anything where the software is the product and the customer's needs are always slightly ahead of what you've built. The picture is different for teams maintaining stable internal tools, though I suspect even that distinction will blur faster than people expect. An LLM that can learn from a codebase's full history, including commit messages, PR discussions, and the reasoning behind past decisions, will play a meaningful role there too. What's in a developer's head is still worth something, but the window for that being a competitive moat is narrower than it used to be.
If you think software development is typing code, you'll lose your job to developers who always knew the thinking was the real work, and now have the time to prove it. The ones who get that have never had more room to do their best work.