There Is No Fixed Amount of Work

“AI will take all the jobs” is zero-sum thinking. It assumes there’s a set amount of work in the world, and every task a model picks up is a task a person loses. That misses how work changes when capability goes up. AI removes bottlenecks, and removing a bottleneck uncovers work that wasn’t possible before. The obvious move is to treat AI as leverage that grows the pie.

The fixed-pie assumption

The fear runs on subtraction. Take all the work there is, subtract what AI can do, and whatever’s left is what people get paid for. As the models improve, the remainder shrinks toward zero.

Economists have a name for this: the lump of labour fallacy. It’s the belief that there’s a fixed quantity of work to go around, so anything new that can do work must take it from someone. It’s an old argument, and it has a long record of being wrong about whole economies, even in the years it was painfully right about specific jobs.

Software is a good place to see why. Most engineering backlogs are longer than the team will ever finish. Product has a list of features that never made the cut. Ops has an admin page they’ve asked for more than once. Somewhere there’s a migration that’s been “next quarter” for two years. All of that is demand, stuck behind a bottleneck.

Bottlenecks hide demand

In 1865, William Stanley Jevons argued that more efficient steam engines would increase Britain’s coal consumption: cheaper work per ton made coal worth using for more things. Economists still call it the Jevons paradox.

Software has run this experiment before. Compilers made each line of code cheaper to write, and we wrote far more code. Cloud infrastructure turned a server into something you rent by the hour instead of rack by hand, and the number of things worth deploying went up.

Code generation is the same move again. When an agent can build a feature in an afternoon, a lot of work that was never worth a sprint becomes worth doing. That admin page. Tests for the legacy billing module. The internal tool that saves support a few minutes on every ticket. I made a small version of this argument in AI Never Would Have Installed left-pad: once writing a utility costs almost nothing, owning it beats depending on someone else’s package.

Work that didn’t exist before

Removing a bottleneck also creates whole categories of work that had no reason to exist. A few years ago, nobody’s job included writing SKILL.md files that teach an agent how a codebase works. Most product teams weren’t building eval suites to grade a model’s answers, or reshaping their CLIs to expose structured output an agent can reason about.

Those are real jobs now, and they exist because the capability showed up first. The zero-sum view has no way to count them. It tallies the tasks AI takes over and has no column for the tasks AI makes possible.

The transition still costs something

None of this makes the change painless. Specific tasks do go away, and someone whose day was mostly those tasks feels it first. A growing pie says nothing about who gets the new slices, or how quickly.

I think the zero-sum framing makes that transition worse. If you believe the work is fixed, the rational move is defensive: hoard the tasks you’re good at, avoid the tools, and argue for keeping the bottleneck where it is. People who do that end up guarding a slice that’s shrinking while the new work goes to whoever showed up curious.

Spend the leverage

For anyone running a team, the fixed-pie view shows up as a specific decision. AI frees up a chunk of capacity, and the first instinct is to bank it as savings. The other option is to point that capacity at the backlog you’d given up on: the reliability work, the internal tools, the experiments that never fit in a quarter.

Which one is right depends on the business, and I won’t pretend it’s always the second. Either way, capacity aimed at the wrong work is waste, which is why speed is only useful if you’re going in the right direction.

AI gives us more capacity than we’ve ever had. I’d rather spend it on the work we never had time for than on dividing up the work we already have.