This is the sixth essay in Reckoning with Reality. The previous essay separated fast feedback from slow results. This one turns to a question that technological progress makes easy to neglect: when an old bottleneck disappears, where does the new one appear?
Whenever a new tool arrives, people first imagine what it will eliminate.
AI makes writing faster, code cheaper, translation nearly instantaneous, and video production possible without a full team. Work that once took days can now be completed in minutes.
All of that is true. But the conclusion that “the barriers to execution have disappeared” leaves out the other half of the system: when one part becomes abundant, the constraint that determines the outcome moves elsewhere.
I remember one very specific morning. Several agents that had run overnight all reported completion. One had added Chinese, English, and Japanese localization to a small utility. Another had built reading-progress analytics for my blog. A third had converted an old CLI into a plugin architecture. The code was clean and the tests passed. I spent ten minutes reviewing the work and reverted two of the three changes. The models had executed well. The mistake was mine: I had placed two things that should not exist into the queue.
That morning made the new constraint visible. Production capacity was no longer my main limitation. Deciding what deserved to be produced—and how much output I could review with care—was.
A System Moves at the Speed of Its Narrowest Point
Imagine a production line with ten stages. If nine become ten times faster and the final stage does not change, total output will usually not increase tenfold. The added capacity forms queues, rework, or inventory in front of the bottleneck.
This is only the simplest static picture from the theory of constraints. Real systems respond. Demand may rise as price falls. Quality may decline under pressure. Former buffers may disappear. The bottleneck itself can change with the load. To speak of a “moving bottleneck” is to keep watching where the complete outcome stops improving after a local acceleration—not to identify one pipe that will remain the narrowest forever.
When AI lowers the cost of producing content, the quantity of content rises quickly; human attention does not grow with it. Production stops being scarce. Being seen and believed becomes scarce.
When development accelerates, code accumulates faster, while requirements, review, testing, and maintenance become the constraint. One person can ask five agents to write code in parallel, but cannot understand five sets of changes at the same speed. My three overnight tasks produced precisely the waste that appears when execution bandwidth exceeds review bandwidth.
A tool expands local capacity and pushes the hidden constraint behind it into view.
Greater Efficiency Does Not Necessarily Mean Less Work
Economics describes a rebound effect: when the use of a resource becomes more efficient and its unit cost falls, total consumption may increase. More efficient lighting can lead people to use more light. Cheaper computing can lead society to build larger models and more applications.
AI may behave the same way.
If producing one piece of content takes one-tenth the time, creators do not necessarily gain nine-tenths of their time back. If demand is sufficiently responsive to price and supply, the market absorbs more content and competitors increase output too. If no one wants the additional content, the saving may simply become a larger pile of waste.
The rebound is not inevitable. It depends on demand elasticity, competition, and whether new uses emerge. This qualification matters; otherwise, “efficiency always creates more work” becomes another kind of technological fatalism.
So the percentage improvement in efficiency is not a complete account of personal gain. We must also ask how the industry’s equilibrium changes, and where the saved resources eventually flow.
If everyone accelerates at roughly the same pace, absolute output rises while relative position may not change, and the tool becomes a ticket of admission rather than an advantage. Adoption is never perfectly even, however. Those with proprietary data, distribution, brands, and better review systems may turn the same tool into a larger lead. A public tool can narrow some skill gaps while widening gaps in complementary assets.
Advantages Have Different Half-Lives
An advantage gained from a new tool usually decays quickly. Others can buy the same subscription. Model upgrades package difficult capabilities into defaults. Platforms absorb workflows that once required separate software.
Workflows have a longer half-life. They contain sequence, judgment points, exception handling, and interfaces between teams; installing a tool does not reproduce them. But workflows, too, are eventually productized. Today’s internal trick may become tomorrow’s default button.
Beyond them lie proprietary data, reliable relationships, delivery capability, and reputation. These require real transactions and time. No version update can supply them overnight.
These layers are often confused. A team adopts AI early and describes its speed advantage as a moat. Months later, when everyone can do the same thing, the team discovers it left nothing else behind.
When judging an investment in AI, I prefer to ask: besides raising output, which learning loop does it make faster?
If the answer is only “more generated material,” the lead will evaporate as the tool spreads. If it helps us accumulate user choices, reasons for failure, delivery processes, and trust more quickly, the technology begins to connect with long-lived assets. Models and features can be bought. A history of judgment, action, and feedback cannot be purchased all at once.
A Moving Bottleneck Is a Roadmap
The appearance of a bottleneck is not necessarily bad news. It often means the previous stage has made progress.
When no one sees the content, there is no need to build a warehouse for a million orders. Once sales become steady, supply and support turn into daily constraints. Only after one team runs smoothly do organizational problems fully appear.
That does not mean every downstream issue can be postponed. Product safety, data protection, legal compliance, and irreversible user migration are boundary conditions from day one. A bottleneck tells us where to apply the next unit of effort; a boundary tells us which errors must never be made even once.
The danger is continuing to optimize a stage that is no longer scarce.
Content is already oversupplied, yet we keep investing in generation speed. There is enough code, yet the team is measured by commits. Traffic exists, yet no one wants to address returns and repeat purchase. These actions are easy because our old capabilities, tools, and identities were built around the previous bottleneck.
Whenever a constraint is relieved, we should redraw the system: Which part is now slowest, most expensive, or most error-prone? Does further optimization of the old part still change the complete result?
This demands a deliberate capacity to let go. Yesterday’s most important problem may no longer deserve the same share of attention today.
Engineering Should Shorten Learning
I once understood engineering ability mainly as the ability to “complete the system.” I now value another use more: shortening the distance from action to judgment.
Tools can reduce the cost of a first delivery. They can preserve the context of an action—from its input and judgment to its result—and help us see which errors recur. Once an activity actually becomes the bottleneck, we can automate it.
This sequence makes engineering serve facts that have already occurred.
Build the content factory, dashboard, and multi-model orchestration first, then search for a problem worth solving, and the system will amplify its original assumptions. The faster the production, the faster a wrong direction consumes resources.
AI is an amplifier, but amplification is not the most troubling part. Once execution is cheap enough, a bad judgment no longer encounters resistance in the slow work of construction. It becomes a finished product immediately. Parallel capacity can copy the same mistake several times before we recognize it. The cost of building falls; the cost of choosing and deleting rises.
Technological Progress Illuminates the Human Part
When execution is expensive, making something can itself be a source of distinction. As execution gets cheaper, choosing what to make, whom to serve, how to deliver, and why one should be trusted all gain weight. Instead of searching for a single eternal human capability, we should train the system to find each new constraint after every increase in speed—and to stop producing what no longer matters.
This does not justify some grand claim that “human judgment can never be replaced.” It only means that in the system as it exists now, after machines remove one scarcity, what remains scarce determines how value is distributed.
The stronger the technology, the more accurately we must see the new constraint, rather than merely celebrating the disappearance of the old one.
After AI solves a problem, the problem does not leave. It moves. Sometimes it moves to distribution, sometimes to trust, sometimes to the organization. It may even move back to the operator: now that productive capacity is nearly unlimited, where should I spend my limited attention?
Responses