AI Capacity Is Arriving Before Its Returns Are Clear

AI’s physical requirements are already concrete; the commercial returns from many applications are not. Chips, data centers, electricity, cooling, fiber and critical minerals all require investment before it is clear which products will justify the expense. That gap is the central tension in Blackstone chief executive Stephen Schwarzman’s account of the buildout: infrastructure may have to come first, but building it does not guarantee that the investment will pay.

Blackstone bought a large data-center company for $10 billion in 2021. Schwarzman says the firm acted on a view that AI would require growing amounts of computing power, and that demand would put pressure on electricity supply. He says the business is now 15 times larger. The investment reflects Blackstone’s stated method: use information from its businesses to detect shifts before they show up clearly in public data, then invest in what those shifts may require.

Schwarzman compares AI infrastructure with the development of electric power. Thomas Edison invented the electric light bulb in 1882, he said, but building an electricity grid broad enough to support widespread use took about 40 years. Grid builders could not foresee every later application, including radio and television. The analogy explains how infrastructure can precede products; it does not show that today’s projects, companies or valuations will deliver comparable returns. Schwarzman himself noted that some investors who commit capital early may not last long enough to see the payoff.

The practical question is therefore not simply whether AI infrastructure will be used, but whether the returns will arrive on the timelines and at the scale that justify the capital committed. In Schwarzman’s account, uncertainty about applications is part of investing ahead of a shift—not evidence that each investment is sound.

AI Infrastructure May Pay Off Before Its Applications Are ClearBloomberg Originals

Inside engineering teams, Laurie Voss describes a related gap between capacity and realized output. Coding agents can generate code much faster than people, but that does not make the rest of software development equally fast. In figures he presented from a study of more than 100,000 GitHub developers, agent users produced 741% more code and shipped 30% more releases. The difference is a useful test of what “faster” means: code production accelerated sharply, while releases rose much less.

Voss argues that the extra output is creating queues elsewhere, especially in review. Large agent-generated changes still need to be checked against a codebase’s conventions, dependencies and operational risks. Reviewers cannot necessarily read more code just because agents can write it. If review tools improve, he expects the constraint to move again, toward deployment, operations, scaling or security.

The figures do not settle the long-run productivity question. They show a mismatch in the results Voss discusses, not that agents cannot eventually make delivery faster. Nor does passing tests alone establish that a change is ready to merge. Voss distinguishes test performance from a maintainer’s judgment about whether a change fits a particular system, including its style, side effects and history. That gap helps explain why code generation can be cheap while trustworthy delivery remains difficult.

Coding Agents Shift Engineering’s Bottleneck From Code to Product JudgmentAI Engineer

The two transitions meet at a question of judgment, though they concern different decisions. Schwarzman describes committing capital before the applications and returns are fully visible. Voss describes engineering work in which producing code is increasingly automated, while deciding what to build and what counts as a good result remains consequential. Investor foresight is not the same as product judgment; the parallel is that both require organizations to act before outcomes are completely legible.

For a software team, Voss says, a request such as “keep track of my orders” leaves the important questions unanswered. A bakery, an auto-parts store and a manufacturer may need different workflows, even if all want to track orders. The person running the business may know what would make a solution useful, but that knowledge has to be drawn out and translated into a specification. As Voss puts it, “Only the baker knows what the bakery needs.”

That knowledge is not necessarily beyond automation forever. Voss points to specifications, rubrics, evaluations and rules as ways to make human judgment more explicit. Once a standard can be written down and checked, an agent may be able to apply it. The constraint can move again: from tacit knowledge, to defining the standard, to deciding whether the standard captures what customers actually need.

The same discipline matters when assessing infrastructure. A forecast of future demand is a reason to investigate and invest, not a substitute for evidence that the resulting products will be useful or profitable. In both cases, the work is to connect a plausible signal to outcomes that can eventually be observed.

Voss’s account also raises a workforce question: the traditional junior path may be narrowing before employers have built a replacement. Well-specified tickets gave new developers a bounded task and a way to learn from feedback. If agents take on more of that work, organizations still need engineers with product judgment—but the old route to developing that judgment may no longer provide enough opportunities.

Voss presented a chart based on ADP payroll data showing that employment for software developers aged 22 to 25 had fallen 19% from its peak, while employment among older developers had risen. That figure is not a complete account of hiring or a prediction for every company. It does sharpen the concern he raises: experience remains valuable, but the entry-level work that helped people gain it is changing.

His proposed response is to train juniors in customer discovery and specification-writing, not only in implementing tickets. That requires time, experienced mentors and opportunities to work with users. It is a different training system, not an automatic consequence of faster code generation. Voss warns that people who entered programming for the craft of writing code may also find the shift away from that work unwelcome.

Infrastructure carries a parallel timing risk. Capital can be committed years before the applications and returns that would make the investment look successful are clear. Engineering teams, meanwhile, may gain production capacity before review practices, operational safeguards and training systems adapt. Neither story establishes that the transition will fail or succeed. They leave a practical test: whether organizations can turn new technical capacity into useful, trusted products—and adjust investment and workforce decisions while the evidence is still emerging.