ESSAY · AUGUST 2026

In a recent talk, the physicist and AI-safety advocate Max Tegmark made a genuinely important case: that we should demand far stronger guarantees from advanced AI systems — moving from what he calls “vibe coding,” where we prompt a model until something works and hope for the best, toward formal verification, where we can mathematically prove that critical software does exactly what it is supposed to do. (His talk is available here.) It’s a powerful idea, and he is asking the right foundational questions. Can we trust systems we don’t fully understand? Should we hand black-box neural networks control over nuclear plants, financial markets, or critical infrastructure? What guarantees should we require before turning high-stakes decisions over to machines? These are vital questions, and Tegmark deserves credit for pressing them.

But there is another safety question almost entirely absent from that conversation — one his technical framing quietly takes for granted. It is the rush to build the physical infrastructure that powers these systems, and the long-term effect of those facilities on real communities and watersheds. Even a perfectly verified algorithm has to run somewhere. And the somewhere is made of concrete, steel, water, and electricity that no proof examines.

Safety as code, but not as concrete

Tegmark’s solution is elegant: rather than deploying opaque models directly, use AI to write conventional software and the formal proofs that it behaves correctly. Move from faith to mathematical guarantee. That is undoubtedly safer than “deploy the black box and see what happens.” But it leaves out an entire layer. Even if the code is proven correct, the physical systems hosting it are not being scrutinized with anything like the same rigor. There is no formal proof for how much water a data center will draw from a stressed aquifer, how much load it will add to a fragile grid, how much land and habitat it will consume, or how thoroughly a community will be sidelined when its county is reclassified as an economic-development opportunity. We are learning to verify the software and simply assuming the hardware.

The unspoken premise: infinite infrastructure

The entire AI-safety conversation rests on an assumption that is rarely stated aloud: that we will keep building whatever infrastructure the labs require. More data centers. More generation and transmission. More cooling, more substations, more warehouse-scale computing. It is taken as given that these will be built, and built fast, and that the only real question is whether the algorithms inside them are aligned. But from the perspective of a watershed or a town, the algorithm is almost secondary. The existence of the facility is the first impact. A single large campus can consume millions of gallons of water a day for cooling. It can lock in decades of energy demand, often pushing new gas or “bridge” generation when grid upgrades lag. It converts farmland and open land into hardened industrial zones. And once the capacity exists, it will be filled — because idle capacity is a cost, and costs get used.

If we ignore this layer, we are quietly redefining “safety” in a way that serves the labs and their investors, but not the communities and ecosystems that absorb the consequences.

Proofs don’t cover the water table

Formal verification can prove that a control system keeps a reactor within safe temperatures, or that a messaging app protects your texts. What it cannot do is answer whether a given region should trade its water and grid stability so that larger models can be trained elsewhere, or whether a rural county should become a national computing hub without a full public accounting of the long-term ecological and social costs. We can prove that an algorithm does X. We are not proving that X, multiplied across thousands of facilities, remains compatible with resilient watersheds, a livable local climate, and genuine community control. Safety, honestly defined, is not only “the model doesn’t misbehave.” It is “the whole system, infrastructure included, doesn’t erode the conditions people and ecosystems need to flourish.” By that measure, the current buildout deserves far more scrutiny than it gets.

Here in the Valley, this isn’t abstract

I write from Augusta County, in the Shenandoah Valley, and the pattern that played out in Northern Virginia is arriving here now. Across the Valley, counties are scrambling to write rules ahead of the wave. Shenandoah County adopted an ordinance this June requiring a special use permit for data centers; Rockingham County did the same in 2025; Strasburg is reviewing a proposed campus of more than eighty acres. My own county, Augusta, currently allows data centers by right in its General Industrial districts and is still drafting a dedicated ordinance — a draft promised for release in August 2026 that had not appeared as of this writing. The rules are being written after the interest has already arrived, not before.

The power to run these facilities has to cross the land to reach them. East of the Blue Ridge, Dominion Energy and its partners in Valley Link have proposed the Joshua Falls–Yeat line — at 765 kilovolts, the highest-voltage transmission line ever proposed in Dominion’s territory — running roughly 115 miles from Campbell County to Culpeper County across as many as nine counties of the central Piedmont, to serve the utility’s growing queue of data centers. It does not cross our valley, but it shows what is coming to rural Virginia, and the developers plan to seek State Corporation Commission approval this fall. Its right-of-way would extend a hundred feet on either side of the center line, negotiated through easements across private land. This is what the infrastructure actually looks like on the ground: not a cloud, but a corridor cut across working farms and scenic country to carry electricity to server halls.

The numbers, stated fairly

It would be easy to reach for the most alarming figure available, so let me be careful and give you the whole picture, including the part that complicates the case.

Virginia’s own legislative watchdog, JLARC, estimated in its December 2024 study that data centers in the state used about 2.1 billion gallons of water in 2023. You may see that figure paired with a growth rate — an 86 percent increase since 2019 is widely quoted. I have left it out, because JLARC publishes no 2019 statewide baseline; that comparison sets JLARC’s statewide 2023 total against a Northern-Virginia-only number from 2019, and the two do not measure the same thing. The absolute figure is solid. The trend line is not. That sounds enormous, and in absolute terms it is. But the same JLARC report found that this was still under half a percent of Virginia’s total water withdrawals, that many individual data centers use about as much water as a large office building, and it judged current statewide use to be sustainable.

I include that reassurance deliberately, because it is true, and because it is exactly where the real problem hides. The statewide average is comforting precisely because it dissolves the local peak into a big denominator. Zoom in, and the picture changes. Loudoun County’s data centers used roughly 900 million gallons of drinking water in 2023, not counting reclaimed water — a jump of about 250 percent over a few years — concentrated in the summer, when cooling demand and drought risk peak together. In the Washington metro region, data centers’ share of water use is projected to climb from about 8 percent in 2025 to 25 percent by 2035. A number that is trivial spread across a state can be decisive spread across a single county’s aquifer in August. The average is not a lie. It is just the wrong instrument for measuring a harm that is, by its nature, local.

A broader definition of safety

If we take safety seriously, we have to extend it past the behavior of algorithms to the material footprint of the systems that run them. That means asking harder questions than the labs tend to pose. Can we have AI safety without unlimited growth in data-center capacity? Who decides where these facilities go, and on what terms? What is the cumulative effect on water, energy, and land over decades, not just the first few years? Are communities given real power to say no, or to attach binding conditions that protect what they can’t get back? It also means admitting that some applications might be unsafe once their full footprint is counted, even if the code is flawless. A perfectly verified system that accelerates resource extraction is still, on balance, a harm.

A genuinely responsible safety agenda would hold several things at once: technical guarantees like formal verification for specific high-stakes systems; real limits on data-center density, energy draw, and water use in vulnerable places; lifecycle accounting for hardware, cooling, and power built into policy rather than bolted on after; and meaningful, enforceable community consent in siting and permitting. Without those, “AI safety” risks becoming a reassuring phrase that leaves the concrete, the steel, and the transmission corridors entirely unexamined.

None of this is a criticism of the work Tegmark and others are doing. Verified code is better than unverified code, and I hope they succeed. It is only to say that the conversation has drawn its circle too small. The question isn’t only whether the algorithm is safe. It’s whether the whole thing — the model, the campus, the water it drinks, the line cut across the countryside to feed it — is safe for the world we actually live in.