DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
12 GW announced. 5 GW under construction. What happens next?



Subscribe • Previous Issues
The Gap Between the Press Release and the Power Grid
Back in February, I wrote about what I called the “Data Center Rebellion,” the growing local resistance to the physical infrastructure behind AI. Since then, I have been asking tech people around the Bay Area how closely they are following the backlash. The answer is usually: they know it exists, but not much more than that. There is still a quiet assumption that most of these announced campuses will get built, plugged in, and brought online more or less on schedule. I am much less sure. What looked like a scattered set of zoning fights has hardened into something more organized, more politically potent, and more consequential for anyone trying to think clearly about AI infrastructure timelines. The opposition has gone from a speed bump to a genuine constraint.

Regularly reading? Consider becoming a paid supporter 🙏

The striking part is how broad the opposition has become. Polling suggests that resistance to local AI data centers is now a mainstream position, not a fringe one. And the “AI” label matters. Data centers have become a visible target for wider concerns about corporate power, electricity costs, water use, job displacement, surveillance, and who actually benefits from the buildout. The politics have also gone cross-ideological in ways that make this harder to dismiss. Environmental justice advocates, rural conservatives worried about local control, and labor groups anxious about automation are all finding common cause at the zoning board.
The Local Backlash Gets Smarter
The objections are practical and increasingly specific. Communities are worried about water in dry regions, electricity demand on strained grids, air pollution from backup power, the constant hum of cooling systems, farmland conversion, tax breaks, and the small number of permanent jobs these projects often create. The industry tends to lead with billion-dollar investment figures. Residents tend to ask a simpler question: what do we give up, and what do we actually get?

The tactics have matured too. This is no longer just online frustration or a few angry public meetings. Residents are using moratoriums, zoning challenges, lawsuits, ballot measures, protests, water-rights filings, and elections. What makes the backlash more durable is the trust problem. Shell companies, project code names, NDAs, fast-tracked approvals, and vague end-user disclosures make communities feel boxed out. Once that trust is gone, even reasonable technical claims start to sound like sales material.
Microsoft’s recent pledge to stop requesting NDAs is a useful illustration here.  It’s notable precisely because it signals how widespread the practice has become. When a company feels compelled to make that kind of pledge, it’s an admission that the old playbook has become a liability.

Announced Capacity Is Not Real Capacity
Local opposition gets much of the attention, but it is only one constraint. Even if a project clears the political process, it still has to get power, transformers, electrical equipment, GPUs, memory, networking gear, cooling systems, utility approvals, and enough skilled construction capacity. In many markets, the bottleneck has shifted from “can you get the chips?” to “can you get the megawatts?” A site can have land, permits, and a glossy announcement and still sit idle because the electrical infrastructure is not ready.
That’s why the gap between announced capacity and capacity under construction matters so much. Of the roughly 12 GW of U.S. data center capacity announced for 2026, only about 5 GW is under active construction. That ratio gets worse, not better, for later years. The industry’s pipeline looks enormous in press releases and investor decks, but only a fraction appears to be moving toward actual completion on the promised timeline. The word “capacity” can mean too many things: land under option, a permitted site, a building shell, reserved power, an energized hall, installed racks, or revenue-generating compute. Those are not minor distinctions. They are the difference between a story the market wants to hear and an asset that can actually serve AI workloads.
(enlarge)
The Trust Deficit Becomes an Execution Risk
The industry is responding, but mostly at the edges. Some developers are revising site plans, changing cooling designs, offering community benefits, making renewable-energy commitments, or becoming more selective about where they build. But they do not fully answer the harder questions: who pays for grid upgrades, who gets the water, who absorbs the noise and pollution, and who has the right to say no?
What concerns me is the financial exposure accumulating underneath all of this. More and more of this buildout is being funded through debt, long-term lease obligations, and capacity commitments made against a pipeline that is, in many cases, more announced than actually under construction. The hard question is whether the math works even if the projects do get built. Hyperscalers are spending as if AI infrastructure will unlock a very large new revenue pool. Maybe it will. But if capital spending keeps rising faster than revenue, the industry may discover that “demand” and “attractive return” are not the same thing. Either AI generates much more revenue than analysts currently expect, or some planned spending gets pushed out, scaled back, or canceled. That second outcome might not look like a crash. It could look like delayed campuses, slower GPU orders, tougher financing terms, and more “rephasing” language on earnings calls.
From “The impossible maths of the AI boom”
This is why I would not treat local opposition as a side story. The compute demand behind AI is not going away. That does not mean every project deserves a rubber stamp. It means the industry has to get much better at earning trust and building capacity that communities, utilities, and investors can actually live with. If AI infrastructure spending is helping support the broader economy, then a serious pause becomes a macro risk, not just an AI story. A slowdown isn’t even the worst version of this. It is an AI economy where compute becomes scarce, expensive, and concentrated in the hands of the few companies and customers that can afford it. That would be a bad outcome for everyone who wants AI to become broadly useful, not just broadly hyped.

The MANIAC. I know this is a 2023 book, but it feels even more worth reading now. As AI reshapes computing, research, and mathematics, this portrait of John von Neumann made me wonder what one of history’s great mathematical minds would make of the machines we’ve built. This is historical & biographical fiction at its best 💯
Steve Jobs in Exile: The Untold Story of NeXT. I had a couple of professor friends who were devoted NeXT users, and this helped me understand why that little black cube inspired such loyalty. This is a sharp, readable look at Jobs’ wilderness years, and how what looked like a detour ended up shaping the Mac, the iPhone, and the tools we use every day.
Inside the Box: How Constraints Make Us Better. I liked this book because its core idea feels especially relevant to AI right now. DeepSeek and other Chinese model builders are a good reminder that constraints do not always slow innovation down, sometimes they force teams to get sharper, scrappier, and more creative.



Source link

Your AI agent looks capable. But can it actually finish the job?



Subscribe • Previous Issues
Why Your AI Agents Fail in Production (And How to Actually Test Them)
In a previous post, I argued that deploying autonomous AI agents reliably is not primarily a model problem. It is an environment problem. The gap between a capable foundation model and a production-ready system is bridged by harness engineering: the discipline of building structured workflows, validation loops, and governance mechanisms around the model rather than inside it. The central argument was that organizations that treat the surrounding environment as the primary engineering target outperform those that chase better models, and that this principle applies across every domain where agents handle complex, consequential work.
That argument raises an immediate practical question: how do you actually know whether an agent is ready for that work? Most existing evaluations still measure narrow, low-friction tasks in controlled or synthetic environments. They can tell you whether a model produces a plausible answer or completes a neat subtask, but they reveal far less about whether an agent can stay coherent across a long workflow, adapt when something breaks, and finish a job that actually runs. Many benchmarks were simple enough that top models were already approaching perfect scores, leaving no meaningful signal about which systems could handle real work and which could not.

Value this newsletter? Consider becoming a paid supporter 🙏

What production usually demands is sustained execution under friction: long chains of interdependent actions, genuine error recovery, and deep domain knowledge applied to messy, open-ended objectives. That is a fundamentally different test than anything most benchmarks were designed to measure. The commercial stakes behind closing that gap are no longer abstract. Terminal-based coding agents alone are already generating billions in revenue, which means accurate measurement of what these systems can and cannot do in realistic conditions has moved from research interest to commercial necessity for anyone building, deploying, or investing in AI agent products.
Measuring the Agent, Not the Demo
Some of the most capable autonomous agents in production today are still concentrated in coding and software engineering. That makes sense. The terminal is one of the few environments where success criteria are clear and feedback arrives immediately. An agent cannot hide behind a fluent answer when a build fails, a dependency breaks, or a command returns the wrong output. It has to keep working until the job is done.
Terminal Bench was built around that reality. It places agents inside real terminal environments loaded with the files, packages, and system configurations needed for the task. Each problem includes an instruction, a verification script, and a reference solution. What gets measured is not whether the agent followed a preferred sequence of steps, but whether it reached a machine-checkable result. There is no partial credit for looking competent. The output either works or it does not.

The significance is not just that Terminal Bench is harder. It is harder in ways that matter. Previous benchmarks often measured narrow command-line skills, relied on synthetic environments, or used tasks so short that they revealed little about sustained execution. Terminal Bench instead asks whether an agent can manage long sequences of dependent actions, recover from real error messages, and apply domain knowledge to open-ended work. Its rigor also comes from the curation. Every task in Terminal Bench is manually reviewed to reduce broken tests, underspecified instructions, and loopholes that let agents game the evaluation. The early results show why that level of manual verification matters. Frontier agents still fail more than a third of the tasks, and smaller models perform much worse. For anyone building, deploying, or investing in agents, that makes Terminal Bench less a leaderboard curiosity than a practical instrument for separating systems that look capable from systems that can actually finish difficult work.
Evaluation is no longer a report card at the end of a cycle. It belongs directly inside the development stack.
The Emerging Infrastructure for Real Agent Evaluation
Terminal Bench has not developed in isolation. A small but important set of related efforts is now building on the same premise that agent evaluation should look more like real technical work and less like a polished demo. LongCLI-Bench pushes this further by focusing on longer command line tasks and by adding step-level scoring, so an agent is penalized not only for failing to finish the job but also for breaking something that previously worked. That is a meaningful advance for anyone building production agents, because regression is often the real failure mode. DevOps-Gym pushes the boundary further into real-world software operations, evaluating agents on their ability to configure builds, monitor systems, and resolve live issues instead of just completing isolated terminal prompts.
(enlarge)
The ecosystem is also expanding into the infrastructure needed to train and compare terminal agents at scale. TermiGen addresses one of the clearest bottlenecks exposed by Terminal Bench, namely the cost of hand-building realistic environments and trajectories for training and evaluation. Terminus and Terminus 2 provide reference implementations for how a terminal agent can interact with a live shell over many steps, which makes them useful both as engineering baselines and as cleaner testbeds for comparing models. And the appearance of fine-tuned terminal-focused systems such as Reptile, LiteCoder-Terminal, and TerminalAgent suggests that terminal competence is now being treated as a distinct capability worth training for directly. Taken together, these developments make Terminal Bench look less like a standalone benchmark and more like the anchor for a broader effort to measure and improve agents that have to do real work under real constraints.
What Comes Next, and What It Means Outside the Terminal
The near-term roadmap for Terminal Bench is really about keeping the benchmark informative. As agents improve, benchmarks only stay useful if they keep stretching the best systems, which means adding harder tasks, expanding domain coverage, and refreshing the suite before leaderboard movement stops meaning anything. Just as important, the Terminal Bench team is making an explicit argument that manual verification is not optional. Their experience showed that confirming task correctness, closing loopholes, and fully specifying success conditions takes substantial human effort, and that cost rises with task complexity.
The infrastructure supporting Terminal-Bench has become more valuable than the benchmark itself. Harbor serves as the expanded framework that allows developers to go beyond basic testing, giving them the tools to optimize AI prompts, run trial-and-error learning, and perform automated quality checks on their agents. That is a meaningful shift. Evaluation is no longer a report card at the end of a development cycle. It is moving into the development stack, not sitting outside it. The ecosystem growing around Terminal Bench is what that shift looks like in practice.
The real leverage comes from the surrounding system, not just the model.
For companies building agents outside coding, this is probably the clearest near-term lesson. The winning approach is unlikely to be full autonomy across messy, high-stakes workflows. It is more likely to be structured human-agent collaboration inside tightly engineered environments. That fits the larger argument in my previous post. The real leverage comes from the surrounding system, not just the model. Terminal Bench sharpens that claim by showing that even in a domain where feedback is fast and success is machine-checkable, reliable autonomous performance remains limited. In domains where mistakes are subtler and more consequential, companies will need even more harness, more evaluation, and more deliberate handoffs between automated execution and human judgment.

Quantum Computing Supply Chains
(enlarge)

The Laws of Thought: The Quest for a Mathematical Theory of the Mind. AI is starting to shape the economy, the job market, and national security. That’s why I think more people should understand the concepts in this highly readable book.
Mutiny: The Rise and Revolt of the College-Educated Working Class. This book struck me as a preview of something bigger. The college grads making lattes and running Apple Store demos are already living the gap between what their degrees promised and what the economy delivers. With AI moving into knowledge work, that gap may widen for many more people.
London Falling. One of my favorite writers delivers again here. I came away feeling like London is not just the setting but almost a character in its own right, with all its glamour, fraud, and seedy underbelly baked into the story.



Source link