The Finite Work Fallacy
Why your workload never decreases, despite AI and automation advances.
There is not a fixed amount of work. Automating the most important thing only promotes the second-most-important thing.
AI is automating more and more of our work, and yet the people closest to it report working more than ever. Dan Shipper said it clearly on Lenny’s Podcast recently, describing the strange feeling of having “so much automation, so much AI” while also working harder than before. He called it a paradox.
I don’t think it’s a paradox. I think it’s perfectly logical. The only reason it looks paradoxical is that it rests on an unspoken assumption: that there is a fixed amount of work to be done, so automating part of it should leave a smaller remainder and hand the rest of the day back to you. Drop that assumption and the “paradox” evaporates.
The Finite Work Fallacy
The premise is that work is a fixed quantity. You have a pile of tasks, the pile has a bottom, and any efficiency gain shrinks the pile and converts directly into free time. If that were true, then automating half your work really would give you half your time back, and the people most aggressively automating would be the most idle. I call this the “finite work fallacy,” because the premise is wrong.
Work is not finite. At any given moment there is a practically unbounded list of things that would be valuable to do, and the binding constraint is never the supply of valuable work. The constraint is your time and attention. Because the list is effectively infinite and your capacity is finite, you don’t work through the list. You only do the things that seem most important.
When the most important thing on the list becomes cheap, or fast, or fully automatable, you don’t stop working. If you compress the single most important thing you do, there is always a second-most-important thing that will now consume your time, and a third after that. The marginal value of each successive item may decline, but it does not hit zero, so you keep going. The queue never empties, because the queue was never finite.
The reason it feels like more work is that people still equate “work” with the technical output (the artifact they used to produce by hand), and they keep pouring mental and emotional energy into that layer even after the agent took over most of it. So the planning and prioritization that now fills their day registers as something extra, piled on top of a job they believe they are still doing in full. In reality, the focus just shifted. The execution stopped costing what it used to, the freed attention moved to the next constraint, and the brain quietly double-counts the part it no longer has to do.
Improving a Weakness Makes You Use It Less
There is another, less obvious explanation for this “fallacy” that comes from game theory. (Discussed nicely in The Art of Strategy, the same book I referenced in Burn the Ships.), It produces a result that sounds wrong the first time you hear it: getting better at a skill can cause you to use it less, not more.
Take tennis for example. Suppose your backhand is much weaker than your forehand. Your opponents are not stupid, so they play to your backhand relentlessly. You spend match after match hitting backhands under pressure, and over time, from all that forced practice, your backhand improves. Now the two strokes are roughly equal. Your opponents can no longer exploit the backhand, so they stop targeting it and start distributing their shots evenly. The result is that you get to use your better forehand more often than you did before. Improving the weakness was really a way of unlocking the strength.
“If your backhand is much weaker than your forehand, your opponents will learn to play to your backhand. Eventually, as a result of all this backhand practice, your backhand will improve. As your two strokes become more equal, opponents can no longer exploit your weak backhand... You get to use your better forehand more often; this could be the real advantage of improving your backhand.”
—Avinash Dixit and Barry Nalebuff, The Art of Strategy
The same logic shows up in basketball. LeBron James is right-handed, and defenses know it, so they might concentrate on stopping his right hand. The reason they can’t do so exclusively is that his left hand, while weaker, is still good enough to punish them if they overcommit. If he spends an off-season improving his left hand, the defense responds by honoring both, which frees his dominant right hand more often than before. The stronger his weak hand gets, the less he has to rely on it, because the threat of it does the work.
The tennis backhand and the basketball left hand are effectively constraints on production. They are the bottlenecks that limit how much you can do with your forehand or right hand, and they are the things that the opposing defense can reliably exploit. When you improve those weaknesses, you dissolve the bottleneck. The result is that you get to use your strength more often, not less.
Now map this onto software. For a long time, for a lot of founders and operators and even many engineers, the production of software was the weak hand. It was the bottleneck, the thing that had to be delegated to a small and expensive group of technical people, the stroke the opposing defense could reliably exploit. The naive expectation, now that AI has made that weak hand strong, is that we will all spend our days happily coding because coding finally got easy.
Game theory predicts the opposite. When the bottleneck dissolves, you don’t pour more of your time into the thing that is no longer scarce. Your attention reallocates to whatever is now the binding constraint. In practice that constraint is planning, prioritization, and judgment, which is to say the strategic layer that decides what the cheap execution should be aimed at. This reallocation is the engine underneath the “more work, not less” observation.
Execution Is Becoming Cheap
I’ve written before, in On Imperfect Information, about how I think LLMs are a near-perfect replacement for action under near-perfect information. Software is commoditized to the precise extent that you can hand an agent perfect operating instructions: clear goals, crisp constraints, complete context, and an unambiguous definition of success. The hard part is turning a messy, partially observable problem into something close to perfect information.
A junior-to-mid engineer used to spend the majority of the workday writing code, with planning and prioritization as a thin layer on top, often supplied by someone more senior. I expect that ratio to invert. A growing share of that engineer’s time (potentially an outright majority) goes to planning, sequencing, and defining constraints. This is not management overhead bolted onto an engineering job. It becomes the core of the technical job, and not only for engineers. Product managers and designers are converging on the same shape, because the same shift is happening underneath all of them at once.
This is yet another possible explanation for the “paradox.” Why would automating work produce more work rather than less? Because the work that survives automation is the judgment-dense work, which is harder per unit of time and exists in effectively infinite supply.
The “Burstiness” of Technical Work
I’ve argued elsewhere that the best work in a startup is “bursty” and phasic. The target is usually unclear at first, so you spend time talking to customers, brainstorming, and probing assumptions. But once the target comes into focus, you sprint at it with everything you have.
AI sharpens the “burstiness” of this cycle. If execution is cheap and getting cheaper, then “building something” largely reduces to a series of planning exercises, followed by intense periods of technical execution. The question becomes how clearly, precisely, and consistently you can define the order of tasks and the components that have to go into the system. Work that we used to file under management, technical leadership, or executive function is now a core part of what every individual contributor does.
The Second-Most-Important Thing
So there is no paradox. There is a fallacy, and once you name it the rest follows. Work is not finite — your time and attention is. Automating the top of the queue does not shrink the queue, it promotes the next item into that slot.
The people who feel busier with all of this automation are not victims of some cruel irony. They are the ones who correctly reached for the second-most-important thing the moment the first one got cheap.