3 ms·

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 w

by pvab3 8mo ago

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 8mo ago
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 8mo ago
  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.
  - 1PlayerOne 8mo ago
    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?

by pvab3 8mo ago

1PlayerOne 8mo ago

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 8mo ago
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.
- 1PlayerOne 8mo ago
  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?