The Explosion Is Certain. The Hard Part Is Where It Lands, and When.
An optimization problem under changing AI production costs: compare producing now, waiting and improving production part by part, then assess other uses of transferable effort by their useful results over time.
The Explosion Is Certain. The Hard Part Is Where It Lands, and When.
For years I held a simple belief: the exponential explosion of technology is the only thing we need to care about. If AI keeps making work dramatically cheaper, much of what civilization produces today could soon cost a fraction as much. Perhaps we should move that effort into whatever makes progress happen sooner. I still regard continued exponential progress as close to certain.
The goal behind that belief is to improve the useful results civilization can produce: homes, industrial goods, services, art and ideas. With limited people and resources, we want better quality, more useful output and lower costs across these fields. This is an optimization problem under changing production costs: how much effort should go into useful results today, and how much into making future results cheaper or better? Results delivered along the way count, as does the ability to keep producing them later. Choices that help one field at another's expense require judgments about their relative value.
Continuing to spend at today's rates may pay for work that will soon become much cheaper. Waiting may sacrifice useful results, learning and preparation that we could obtain in the meantime. Investing in faster or more usable AI also consumes resources that could produce something valuable today. These choices compete for the same effort, which is why confidence in future progress still leaves a difficult allocation question.
My starting strategy is to look for work where some current spending can be saved, then compare what those resources could accomplish elsewhere. This is a way into the allocation problem: the low-hanging fruit of visible cost savings and useful alternatives.
The practical takeaway: adjust effort part by part as production costs change. Keep work whose benefits justify doing it now. Consider waiting where the expected saving outweighs the value of acting sooner. Invest in improvements to production when the useful gains justify their cost. Then compare other uses for any effort that can actually be transferred, and revise those choices as results become visible.
To make those comparisons, we need to understand how AI's improvements reach actual production. That tells us when cheaper work may become usable and how much it could change. The framework below is my reasoning model, calibrated with public research.
A cheaper task must become a cheaper result
Imagine a software team whose AI can write a proposed change in minutes. The team still needs to check that the change solves the right problem, test it against the rest of the system, integrate it and accept the result. If those steps take most of the effort, faster coding yields a smaller improvement in the complete job. This is a hypothetical example, but it gives us the unit that matters: a useful change successfully delivered.
A bottleneck is the step or resource currently limiting that complete result. Making one step faster can expose another constraint. In this team, checking and integration may become the bottleneck once code is easy to generate. A further improvement in code generation then has less effect on delivery than an improvement in the team's ability to evaluate the changes.
This also separates two kinds of waiting. First, AI has to become capable of the relevant task. Capabilities need not arrive for every kind of work at the same time. Second, once the capability exists, people must adopt it, fit it into the workflow and accept its results. I use diffusion delay for that second interval: the time between an available capability and an improvement realized in production.
The size of the realized gain matters alongside its arrival time. For the same useful result at the same quality, how much time and effort does the complete process save? A tool may already save coding time while release dates barely move. It may reduce the effort required for a release, increase the number of releases, or leave people spending the saved time on additional review. These are different outcomes. We need to establish which one has occurred before treating local speed as cheaper complete production.
Existing studies help calibrate this distinction. In a randomized experiment, developers with GitHub Copilot completed a fixed coding task in 55.8% less time than those without it (Peng et al. 2023). In their June 2026 summary, Demirer, Musolff and Yang reported a matched event study of more than 100,000 developers, estimating that adoption of successive AI coding tools raised commit activity to about 2.8 times its baseline but releases to about 1.3 times. This observational study and the fixed-task experiment do not measure the same task or establish a common conversion rate from coding speed to delivery.
For today's allocation, frontier progress therefore works through a production process. The relevant capability must arrive, people must be able to use it, and the improvement must reach the complete result. Those links determine when and how much effort could actually be saved.
Pressure changes the process, and the available routes
The software team's current workflow can change. As generated code becomes plentiful, a slow review process may leave increasingly valuable work waiting. That creates an incentive to try better tests, redesign review or change how the software is built. In this example, automated checks could handle changes that previously needed a person to inspect them one by one. Another approach might use a simpler implementation that avoids the difficult integration step.
This is the role of evolutionary pressure in my model. When old ways of working become harder to sustain or less able to meet demand, the incentive to experiment grows. People search for workable tools and processes. Across the ecosystem, some approaches expand and spread through imitation; others shrink or disappear. Nelson and Winter's evolutionary theory of economic change provides a search-and-selection framework for understanding that process.
Adaptation can improve the original route or produce a way around it. The difference matters later when we judge a bottleneck investment. If the software team can use a simpler design, the value of making its old integration process faster depends on what that improvement adds beyond the simpler route. The original constraint may have been real, yet relieving it need not remain the best use of effort.
Applied to AI, this mechanism makes diffusion delay and the size of usable gains changeable. When feasible tools and alternative processes exist, and people have the authority to change how they work, pressure can bring improvements into use sooner or spread them more widely. An unresolved constraint today need not remain unchanged. After one is relieved or bypassed, another may become the main limitation.
The pandemic illustrates process adaptation under pressure. In a McKinsey survey of 899 executives in July 2020, companies reported digital customer interactions rising from 36% to 58% in about seven months. This self-reported episode illustrates rapid change where capabilities and opportunities were available; it does not measure a general AI diffusion interval.

Figure 1. The hypothetical team's task gain must reach accepted delivery. Pressure can change the checking process or produce a simpler route. The time to usable delivery and the size of its improvement can therefore change.
We now have a model of the inputs needed for a decision: when an improvement becomes usable, how much complete work it changes, and how those quantities may move as methods adapt. It also identifies an action we could take: improve the process ourselves. Whether that action is worth its cost belongs in the same comparison as doing the work now or waiting.
Compare the saving from waiting with the value of acting now
The first comparison concerns how to use effort within a particular kind of work: produce something now, postpone it, or improve the process that produces it. A useful result retains its usefulness even if a future system could produce it more cheaply. We need to compare the extra resources spent to get it earlier with what that earlier result makes possible.
Call the extra resources today's premium: for the same useful result, how much more does producing it now cost than producing it later? Waiting may avoid that premium, but it forgoes benefits in the meantime. The result may be needed now. Using it may teach us what to do next or enable work that would otherwise start late. Some opportunities expire.
Usable timing changes both sides of this account. Suppose a society needs a result over the coming year and expects AI to make it much cheaper. If the same saving becomes usable next month, waiting may cost little. If it arrives five years from now, producing during the coming year may be worth the higher cost. Improving an existing process could offer a third option: pay to bring the saving forward.
This is why delay matters to the argument. It changes when the lower production cost becomes available and how much useful work is lost while waiting. The magnitude of the saving, the urgency of the result and the benefits of starting early complete the comparison. Laying foundations or acquiring land makes necessary preparation especially visible: starting a sequence late can mean finishing late, even if a later step becomes cheaper.
For investments that generate benefits over time, we also need payback: when do the accumulated benefits cover the investment's cost? Benefits already earned count, and benefits that continue after a new tool arrives count too. A cheaper way to produce new results can reduce an investment's remaining advantage without erasing everything it has produced or will continue to produce.
Consider a simplified illustration where an investment loses its remaining advantage once a much cheaper alternative becomes usable. Suppose that happens in four years, and three investments take one, three and six years to repay. Under those assumptions, the first two can repay if begun today; the third cannot. Two years later, only the first can repay before the alternative arrives. An investment with continuing value needs that value included.
The amount of work worth doing now is a matter of degree. Our hypothetical software team might continue maintaining a service that users need today, postpone an optional feature that is likely to become cheaper to build, and invest in tests that improve delivery for years. These decisions can coexist because the work has different deadlines, benefits and useful lives. Uncertainty about usable timing affects how much to commit to each part; as that timing becomes clearer, those commitments can change.
Build capacity where it improves the whole job
The comparison leaves room for producing results today and for improving the ability to produce them. I call these output and capacity. Output is the code, report or design delivered this time. Capacity is the ability to use AI effectively: tests, clear specifications, usable data, integration procedures and the authority to change a process.
Return to the hypothetical software team. Writing automated tests consumes effort now, but creates a reusable way to check later changes. The team could then accept more of AI's work without repeating the same manual inspection. The investment's value comes from the extra useful delivery it enables, or the effort it saves in producing the same delivery. Its construction and maintenance costs belong in the account.
This fits the economics of complementary investment. In The Productivity J-Curve, Brynjolfsson, Rock and Syverson explain how general-purpose technologies require new processes, skills and other intangible assets to realize their potential. Building those complements takes resources before their benefits fully appear. Their J-Curve analysis concerns the timing of measured productivity around intangible investment. For this article, the relevant mechanism is that acquiring a better tool and developing the ability to use it can happen at different times.
Capacity investment can therefore change the usable arrival time introduced earlier. The software team may already have a capable model; building a reliable checking process can make that capability useful sooner. The investment still needs to earn enough benefit to justify its cost. Some model-specific scaffolding wears out quickly, while other tests or processes remain valuable across model generations. Include both the cost of updating and any lasting value.
The investment also has to improve the complete job. In a randomized field experiment at Alibaba's customer service, access to an AI assistant cut the time agents took to identify a customer's issue by 8.2%, but cut the conversation's duration by only 1.1%. A faster step can help, while the effect on the whole service remains much smaller. This is the same bottleneck relationship we saw in software, now applied to choosing what to improve.
The following table groups the comparison into four rough regions. Near and far refer to when a substantial improvement becomes usable relative to when the work is needed and when an investment earns its return.
| State of the field | What to do now |
|---|---|
| A large usable improvement is near, and you can afford to wait | Reduce or postpone replaceable direct output; assess capacity that can repay within its useful life, counting value retained after new tools arrive |
| A large usable improvement is near, but you cannot afford to wait | Do the work with the AI available today, accepting the premium relative to waiting |
| The usable improvement is far beyond when the work is needed | Continue work whose interim benefits justify its cost; assess whether process or capability investment could bring the gain forward |
| Unclear whether a usable improvement arrives within the relevant period | Plan around present costs and benefits, retaining the ability to adjust |

Figure 2. Compare these choices for each part of the work. Benefits while waiting, costs, payback and lasting value can justify different commitments to production and capacity within the same field.
Before moving to other uses of resources, establish what can actually move. A saving may be absorbed by greater output or additional checking. Some effort may be needed to maintain the new process. Reallocation concerns the part genuinely saved and available for another use, including the costs of making that transfer possible. Only then does the next comparison have resources to allocate.
For a purely illustrative account, suppose the same accepted software work takes 70 engineer-hours a week rather than 100, including its checking and integration. Maintaining the new automation takes another 10 hours. At most 20 hours remain available before training or handover costs. If the team instead uses those hours to deliver more software, no hours have been released for another activity. These numbers describe an accounting example, not a measured saving.
Put transferable effort where it improves useful results
The first comparison helps us decide how much work to do now and which improvements are worth building. If it identifies people or resources that can actually move, a second comparison begins: where would that effort create the greatest additional value? We can invest in new frontier capabilities, in the resources AI needs, or in the processes that put existing capabilities to work. These routes can reinforce one another. The same effort could also produce useful results directly. Each destination has to be judged against the other available uses of that effort, by what it enables downstream and what choosing it gives up.
Start with how an improvement travels to useful work. Breadth is how many kinds of downstream task can benefit from the same improvement. For example, better tools for AI-assisted research might help formulate and test ideas in software, design and science. The possible benefit is broad because one improvement could be used in several kinds of work. It counts only where people can actually use it to improve their results.
Depth is how much the improvement changes a complete job in an affected task: its cost, speed or quality. If a workflow cannot use a capable model because it runs out of memory, reducing memory use might let it complete the job or obtain a larger gain from the model. Relieving a bottleneck can therefore increase depth. A shared power or memory constraint may also affect many tasks, giving its relief breadth. These are two dimensions of the downstream benefit, rather than separate categories of investment.
Then ask when those gains could become usable and what it costs to bring them about. What useful production would the same resources otherwise provide? That last comparison is the opportunity cost of acceleration.
The bypass model adds another input. An investment earns its value beyond the best alternative route. In the software example, the proposed review upgrade should be compared with the simpler design from section 2: which delivers the needed result at a better cost, quality and time? An upgrade can improve on the old process yet still be a worse use of effort than that feasible alternative. When power is short, people may improve efficiency or build where power is available. When visas are short, firms may hire elsewhere. In a natural experiment using the US H-1B lottery in ordinary firms, extra visa holders largely replaced other hires, with little measured innovation gain. That result concerns the firms studied; it illustrates why the effect of easing a constraint has to be distinguished from the resources it attracts.
My response is to keep several routes active and revise their weights as effects become clearer. Broad, substantial gains that reach work sooner deserve attention. Good alternatives reduce the claim of an investment in the original route; a physical limit with few alternatives may warrant concentration. Frontier models, chips and research may be the most valuable uses of effort. Their comparative value remains a bet on future downstream effects.

Figure 3. Breadth concerns how many kinds of work one improvement can reach; depth concerns the usable improvement in each affected job. A shared constraint can affect several tasks too. Compare destinations against direct production and the best feasible alternatives, then update from complete results. The links shown are hypothetical possibilities.
Calibrate the comparison with what relief changes
A bottleneck claim needs evidence that the constraint matters to the outcome and a reason to expect relief to help. Public evidence often measures scarcity without measuring what relief changes. For a constraint that has never been relieved, missing observations of relief are especially weak information about its importance. If our team has never expanded its review capacity, the absence of a measured delivery gain from doing so tells us little; we still need a reason to expect the change to help.
Even estimates of scarcity need scrutiny. When Exelon required signed contracts and collateral from data-center developers, its high-probability load forecast fell from 18 gigawatts to 11; signed transmission security agreements covered only 4 gigawatts (company slides, earnings call). Queue-based demand alone can overstate the demand likely to materialize. These numbers do not settle the productivity gain from adding power.
France's Services Publics+ provides a concrete example of integration. The platform helps public servants draft responses and analyze user feedback; officials can edit or reject the suggested responses before sending them. The OECD reports average response time falling from 19 days to three. The reported outcome concerns responses, rather than the speed of drafting alone. This is official case reporting of an AI-assisted workflow, without a disclosed comparison group or request count, so it does not isolate AI's contribution.
By contrast, the US patent office piloted AI-assisted search with a subset of examiners while its reported average total patent pendency was 23.3 months in both fiscal years 2020 and 2021. A deployment and a complete-process improvement are separate observations. These cases make the investment question concrete: which change could improve the delivered result, and what other parts of the process must change with it?
Allocation itself changes the comparison. Concentrating effort on one constraint may ease it, expose another or make a different route attractive. When options look about equal, I prefer one where we could tell whether easing its bottleneck helped. That makes correction easier, and is why evals matter for agent systems.
We can now assemble the five-step argument:
- Rapid frontier progress provides a reason to expect some future work to become cheaper.
- Relevant capabilities must reach complete production before we can judge the usable timing and size of that saving. Bottlenecks and adaptation shape this passage.
- Compare the saving from waiting with the benefits of acting now. Some current investments become less attractive; others still justify their cost.
- Where effort can actually be saved and transferred, compare feasible alternative uses, including the value of direct production forgone.
- Acceleration is a promising set of those uses when it improves useful downstream results. Compare breadth, depth, timing, cost and alternative routes, then revise the allocation as outcomes change.
To see the whole route, continue with the hypothetical team's accounting example. AI handles routine coding, and the saving reaches accepted delivery. The team keeps the service users need, reduces replaceable effort and establishes what can move after upkeep.
Engineers with suitable skills might use some remaining time to improve memory efficiency in a constrained AI workflow. Suppose another team's AI-assisted software checks cannot finish on its current equipment because they run out of memory. If the engineers reduce peak memory use enough for those checks to finish, and the other delivery requirements pass, a fix that users need could arrive sooner. The benefit is the earlier reliable fix, together with any effort saved in delivering it.
Alternatively, they might build tools that help AI-assisted research test candidate ideas, with possible uses across several fields. These are candidate destinations: training and handover have costs, a more efficient existing tool might already bypass the memory problem, and the same hours could deliver valuable software directly. The final judgment is whether either destination enables more useful results than those alternatives.

Figure 4. A hypothetical path through the five steps. The first four establish whether effort is available; the branches show candidate uses in step 5. Either destination must beat its feasible alternatives after costs and forgone direct work are included. The diagram supplies no destination ranking.
This gives a strategy for conditional reallocation: reduce inputs whose returns no longer justify them, retain worthwhile production and capacity, and move available effort toward better uses. The models supply the conditions for each move. They explain why cheapness, speed or a visible bottleneck alone cannot complete the allocation judgment.
Use the framework within its limits, and update it
Starting with visible cost reductions makes the allocation problem easier to approach. It also leaves important comparisons unfinished. The tie-breaker above favors effects we can see, and the wider method finds opportunities where savings or downstream gains are clear enough to estimate.
Consider housing work that has not become cheaper through AI. The cost-saving route identifies no effort to release there. Yet moving some of that labor into data centers or power infrastructure might enable gains across other fields worth more than the housing forgone. I have heard of foundation workers being hired away by AI infrastructure projects at much higher pay; this is my observation, rather than a checked general finding. Judging the reallocation requires comparing lost housing with the infrastructure's downstream effects through the economy. Our low-hanging-fruit analysis has not performed that comparison.
The framework therefore identifies visible opportunities within a broader optimization problem. It helps compare continuing work, waiting and building capacity; it also organizes the comparison among uses of transferable effort. Specific resource quantities, delay forecasts and a reliable funding order require further evidence and judgment. The economy can develop useful routes that our current map does not anticipate.
Evidence is used to calibrate that map. Fixed-task studies, project outcomes and aggregate productivity describe different things. Rigorous studies may miss teams using the newest methods, while frontier reports often lack a denominator. Estimates of AI's aggregate productivity effect built from similar task-level studies, such as Daron Acemoglu's and Philippe Aghion and Simon Bunel's, differ by roughly a factor of ten. Assumptions about how local gains reach complete production can matter enormously. Survey evidence and narrow measurements should correct a mechanism-based judgment at the scope they actually observe.
Updating has a concrete job. Watch which constraints become pressing, which new routes appear and what happens to complete results after an intervention. In the software example, a faster review process is useful evidence only alongside what it changes in delivered software or the effort required to deliver it. If another stage remains limiting, further review investment may have lower returns. If a bypass becomes available, compare it with continuing to improve the old route.
Keep the decision tied to those outcomes. Change the expected gain, usable timing or allocation when the evidence changes. Pressure can reveal a problem and motivate an experiment; the resulting complete-work improvement tells us whether that experiment helped.
Takeaway: adjust effort as usable gains change
Fast AI progress changes the cost of future work. Today's choices depend on how that progress reaches useful results, what acting earlier provides and what other uses of effort could accomplish.
The practical path is to compare production, waiting and capacity part by part within each kind of work, then compare destinations for effort that can really be transferred. Different returns, deadlines and useful lives can justify different commitments within the same field. Bottlenecks and adaptation explain the passage to usable gains. Timing and payback connect those gains to current investment. Alternatives and opportunity cost connect reallocation to useful results across fields.
I would extend the same reasoning to a team or a person: keep work whose benefits justify doing it now, build reusable abilities that improve actual delivery, and judge a proposed bottleneck investment by the difference it makes beyond other available routes. That is an extension of the civilization-level argument.
As gains become usable and new constraints appear, revise where effort goes. The strategy earns its value through the useful results it helps produce over time.