[pvab3]

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.

[1PlayerOne]

AI says:

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:

Tech debt cleanup Reliability and on-call quality Better internal tooling Security, compliance, testing

From the outside, it looks like:

“They’re building the same amount.”

From the inside, it feels like:

“We’re finally doing things the right way.”

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

[Andrex]

One of the most insightful HN comments I've read in years. Thank you! I'm curious about what you've read and are reading.