The AI bottleneck moved from chips to electricity

For most of 2024 and 2025, the story about AI capacity was chips. Who could get H100s, how long the lead time was, which cloud had allocation.

That constraint has largely cleared, and a less tractable one has replaced it. Gartner's projection is that power shortages will restrict 40% of AI data centres by 2027. Not chip shortages. Power.

You can spin up a fab faster than you can get a transmission line approved, and it turns out that matters.

The shape of the constraint

The aggregate figures get quoted a lot and are worth treating carefully — most of the widely circulated numbers are projections, they vary substantially between forecasters, and they get repeated at second and third hand until the original caveats fall off. The direction is not in dispute; the precise magnitude is.

In any case, the binding constraint is not generation in aggregate. It is delivery to a specific location. Interconnection queues run for years. Heavy electrical equipment — transformers, switchgear — has lead times measured in the same units. A site can have capital, land, planning permission and a signed chip allocation, and still not have power until 2029.

This is why analysts describe grid capacity rather than capital or technology as the thing now shaping where data centres get built and which workloads they can support.

Why this lands on application teams

If you do not operate infrastructure, the temptation is to file this under someone else's problem. Three consequences arrive at the application layer anyway.

Regional availability gets lumpy. New model capacity will not appear evenly across regions any more. It will appear where power was available, which is increasingly not where your users are. If your architecture assumes the newest model in your nearest region, that assumption is weakening. Teams outside North America and Western Europe have been living with this for a while; it is about to get more pronounced, not less.

Latency becomes a routing decision again. When capacity concentrates in a handful of power-rich regions, inference for a user in Kathmandu or Nairobi may be served from considerably further away than the rest of the stack. The interesting design question stops being "which model" and becomes "what does this feature do when the round trip is 400ms instead of 80ms". Streaming, optimistic UI and genuine offline paths stop being polish.

Prices stop falling monotonically. The steady decline in per-token cost has trained everyone to assume next year is cheaper. That decline came from model efficiency and competition, both of which continue. It now runs against a cost floor that is rising, because electricity in constrained markets is not getting cheaper. It would be unwise to plan a business model on an extrapolated price curve.

The efficiency angle is not a footnote

There is a version of this that reads as doom. It should not. A physical constraint on a resource that was previously treated as unlimited is precisely the condition under which engineering gets better.

The last two years of AI application development have been extraordinarily wasteful, because compute was cheap enough that waste did not show up anywhere you looked. Sending an entire document to a frontier model to extract a date. Re-embedding a corpus that has not changed. Running the largest available model on a classification task a much smaller one handles perfectly.

Every one of those is now a line item with a physical constraint behind it. Caching, smaller task-specific models, batching work that does not need to be synchronous, actually measuring how much of a prompt is doing useful work — this is ordinary engineering discipline, and it has been optional for a while.

For teams that never had cheap abundant compute in the first place, this is not a new discipline. It is the one they already had.

What to do with this

Nothing dramatic, and nothing this quarter. But two habits are worth starting.

Measure tokens per user action, and treat a rise in it as a regression rather than a natural consequence of shipping features. Most teams cannot answer what a single user journey costs them, which makes the number impossible to defend when it matters.

And keep model choice a configuration value rather than an assumption baked through the codebase. The reason is no longer only that a better model might arrive. It is that the model you want may not be available in the region you need, and the team that can change that in a config file will handle it in an afternoon rather than a sprint.

The grid is not going to be fixed by anyone reading this. But the software built on top of it can stop assuming that compute is free, infinite, and evenly distributed — because on current evidence it is none of the three.