Chip supply was never your constraint. Electricity was, and most of us building bots just hadn’t noticed yet because the bill arrived pre-abstracted as an API token price.
That’s the uncomfortable read I take from Morgan Stanley’s latest note on the US data-center power crunch. The brokerage estimates a 34% net power shortfall through 2028 — roughly 32 GW — even after accounting for workarounds like behind-the-meter generation and fuel cells. The headline everyone picked up was that Nvidia and Broadcom come out fine. True, and also the least interesting part of the story if you write code for a living.
Why the big two stay insulated
Morgan Stanley doesn’t see these bottlenecks threatening Nvidia or Broadcom’s 2027 forecasts. The reasoning is about information, not luck: both companies have visibility into where chips are physically placed, they’re expanding geographically, and they coordinate directly across data centers, semiconductor suppliers, and the power supply chain. When you can see which sites will actually have megawatts available, you route silicon accordingly. Demand doesn’t vanish, it relocates.
The exposure sits further down the stack. Any delay in AI deployments hits makers of memory, optical, and other secondary chip components — the parts that get ordered on the assumption a rack goes live on schedule. Morgan Stanley flags greater inventory risk for memory, optical, power-management, and analog suppliers if data-center timelines slip. Nvidia reroutes. A memory vendor sitting on product built for a site that won’t energize until 2029 has fewer options.
What this means if you ship bots
I build and deploy agents for a living, and the practical translation is simple: capacity in specific regions is going to be lumpy for years. Not absent. Lumpy. That changes how you design.
Most agent architectures I review are written as if compute is infinite, instant, and located everywhere. Unbounded tool-call loops. One hardcoded model endpoint. Retry logic that just hammers the same region harder when it gets a 429. That design survived the era when you could paper over inefficiency with more GPU. It handles a 32 GW shortfall poorly.
Things I’d actually change in your codebase this quarter:
- Make your model a config value, not a constant. If swapping providers or model sizes requires touching more than one file, you can’t react when a region gets tight. Build the abstraction layer now while it’s cheap.
- Treat capacity errors as a first-class state. Rate limits and capacity failures are not generic exceptions. Queue the work, degrade to a smaller model, or defer the task — but do it deliberately, with the fallback path tested.
- Cache aggressively at the semantic layer. A large share of agent traffic is near-duplicate requests. Embedding-based response caching is unglamorous engineering that cuts your inference footprint measurably.
- Batch anything that isn’t user-facing. Summarization jobs, enrichment pipelines, and evals don’t need to run at interactive latency. Off-peak batch endpoints are cheaper for a reason, and that reason is power.
- Measure tokens per task, not just latency. If you don’t instrument consumption per workflow, you can’t tell which agent is quietly burning your budget on a reasoning loop that re-reads the same document nine times.
- Plan for multi-region, even if you don’t need it today. Geographic expansion is explicitly part of how the chip vendors are managing this. Your deployment story should rhyme with theirs.
Scarcity is a design input
There’s a version of this news that reads as pure finance — who’s safe, who’s exposed, which ticker to watch. Fine. But the engineering signal underneath is that the physical world has re-entered the conversation. Substations, interconnect queues, turbine lead times. These are now upstream dependencies of your chatbot, and they move on timelines measured in years rather than sprints.
Morgan Stanley and Goldman Sachs have both flagged mounting constraints on the US data-center buildout, with Morgan Stanley pointing at labor, power, and permitting. Those aren’t problems a software team solves. They are problems a software team adapts to, and the teams that adapt early get to keep shipping while others wait on an allocation email.
The optimistic framing is that constraint is a decent engineering teacher. Efficient inference, smart caching, honest cost accounting, graceful degradation — these were always good practice. A power shortfall just turns them from nice-to-have into the difference between an agent that stays up and one that doesn’t. Write your bots like compute costs something, because it always did. Someone else was just absorbing the invoice.
🕒 Published: