Part of the problem is the word "replacement" kills nuanced thought and starts to create a strawman. No one will be replaced for a long time, but what happens will depend on the shape of the supply and demand curves of labor markets.
If 8 or 9 developers can do the work of 10, do companies choose to build 10% more stuff? Do they make their existing stuff 10% better? Or are they content to continue building the same amount with 10% fewer people?
In years past, I think they would have chosen to build more, but today I think that question has a more complex answer.
1. The default outcome: fewer people, same output (at first)
When productivity jumps (e.g., 5–6 devs can now do what 10 used to), most companies do not immediately ship 10% more or make things 10% better.
Instead, they usually:
Freeze or slow hiring
Backfill less when people leave
Quietly reduce team size over time
This happens because:
Output targets were already “good enough”
Budgets are set annually, not dynamically
Management rewards predictability more than ambition
So the first-order effect is cost savings, not reinvestment.
Productivity gains are initially absorbed as efficiency, not expansion.
2. The second-order effect: same headcount, more scope (but hidden)
In teams that don’t shrink, the extra capacity usually goes into things that were previously underfunded:
So yes, the product often becomes “better,” but in invisible ways.
3. Rare but real: more stuff, faster iteration
Some companies do choose to build more—but only when growth pressure is high.
This is common when:
The company is early-stage or mid-scale
Market share matters more than margin
Leadership is product- or founder-led
There’s a clear backlog of revenue-linked features
In these cases, productivity gains translate into:
Faster shipping cadence
More experiments
Shorter time-to-market
But this requires strong alignment. Without it, extra capacity just diffuses.
4. Why “10% more” almost never happens cleanly
The premise sounds linear, but software work isn’t.
Reasons:
Coordination, reviews, and decision-making still bottleneck
Roadmaps are constrained by product strategy, not dev hours
Sales, design, legal, and operations don’t scale at the same rate
So instead of:
“We build 10% more”
You get:
“We missed fewer deadlines”
“That migration finally happened”
“The system breaks less often”
These matter—but they’re not headline-grabbing.
5. The long-run macro pattern
Over time, across the industry:
Individual teams → shrink or hold steady
Companies → maintain output with fewer engineers
Industry as a whole → builds far more software than before
This is the classic productivity paradox:
Local gains → cost control
Global gains → explosion of software everywhere
Think:
More apps, not bigger teams
More features, not more people
More companies, not fatter ones
6. The uncomfortable truth
If productivity improves and:
Demand is flat
Competition isn’t forcing differentiation
Leadership incentives favor cost control
Then yes—companies are content to build the same amount with fewer people.
Not because they’re lazy, but because:
Efficiency is easier to measure than ambition
Savings are safer than bets
Headcount reductions show up cleanly on financials
ha ha, this is the response from Microsoft Copolit when I asked:
If 5 or 6 software developers can do the work of 10, do companies choose to build 10% more stuff? Do they make their existing stuff 10% better? Or are they content to continue building the same amount with 10% fewer people?
You don't need to draw the line between tech experts and the tech-naive. Plenty of people have the capability but not the time or discipline to execute such a thing by hand.
Generally most distribution costs are socialized starting with the REA and such. My block needed a new transformer a few weeks ago and it will be paid for by every customer of that utility.
reply