The Most Expensive Computation Is the One That Should Never Have Happened
The overlooked relationship between drift, recomputation, and AI energy demand
By Chris Ciappa
Founder & Chief Coherence Architect
Samirac Partners
I keep watching these stories pile up and something feels off.
Farmers who spent decades simply watching the sky for rain are now standing in packed town halls arguing about artificial intelligence. Homeowners who have never written a single line of code are suddenly deep in conversations about electrical substations, cooling towers, and billions of gallons of water. Local governments are looking at proposals for facilities so large their power demands rival those of small cities.
The fights are heated. One side says this is the future and we have to build the infrastructure. The other side looks at the noise, the water usage, the wildlife, the strain on the grid, and the long-term weight this will put on their communities, and they’re pushing back hard.
On the surface it looks like a simple fight over electricity. More computation means more power. More power means more infrastructure. The demand, everyone seems to agree, is inevitable.
But the more I sit with these arguments, the more it seems like we might be measuring the wrong thing.
We’ve accepted this idea that future AI demand is basically fixed. Bigger models, more agents, more everything — therefore we need dramatically more electricity. So the conversation becomes about how fast we can build the plants and data centers.
That’s when something started bothering me.
I kept thinking about those data center debates, and oddly enough I found myself remembering something I had read about hydraulic failures in aircraft. A plane is flying along normally. Then a hydraulic line ruptures. In one moment certain maneuvers are completely valid. In the next moment they’re not. The aircraft doesn’t keep trying anyway. The architecture itself recognizes that reality has changed and simply closes off the actions that no longer make sense.
Not because a committee met. Not because someone updated a policy. The system just responded to the new state of things.
I keep coming back to that.
Because right now the entire industry is almost entirely focused on increasing capability. Bigger models. Bigger clusters. Bigger power budgets. And we assume all of that future computation is necessary and productive.
But the more I watch what actually happens inside these systems, the more I see the same pattern showing up everywhere.
You start a workflow. One part gathers information. Another builds a plan. Another tries to act. Then come the validations, the corrections, the retries. As long as the original assumptions hold, it can feel almost magical. But the moment something shifts — a permission gets revoked, a goal quietly becomes invalid, a dependency disappears, a constraint appears that wasn’t there before — too often the whole chain just keeps moving forward anyway.
By the time the system realizes the original assumption was wrong, it may have already retrieved information it no longer needs, built plans that can’t succeed, executed actions that should have been stopped, and launched multiple layers of correction workflows trying to chase an outcome that stopped being possible several steps earlier.
All of that still burns real electricity.
And the more I think about it, the more I wonder if this is where the data center conversation becomes interesting.
When people talk about future AI power demand, the assumption is usually that the demand comes from useful work. More users. More intelligence. More capability. More value.
But what if a meaningful portion of that demand is actually re-computation?
What if the real cost isn’t the first answer?
What if it’s the second, third, fourth, and fifth attempts to recover from drift?
Every time a system loses its frame and has to rebuild context, that’s computation.
Every time an agent follows a path that should have been abandoned three steps earlier and has to be corrected, that’s computation.
Every time a workflow retries, re-evaluates, re-plans, re-validates, or re-executes because the system continued operating against assumptions that were no longer true, that’s computation.
Not new value.
Not new intelligence.
Just recovery.
The more I watch these systems, the more I find myself wondering how much of the industry’s projected power demand is actually useful work and how much is the accumulated cost of architectures that allow drift to compound before they intervene.
Because if that’s true, then we’re not just looking at a scaling problem.
We’re looking at an architectural problem.
That pattern feels familiar.
We’ve seen versions of it before. In aircraft systems. In industrial control systems. In early software that spent more time recovering from errors than doing useful work. The breakthrough in those fields didn’t always come from adding more capability. It came from learning when to stop. From building architectures that could recognize when reality had changed and close off paths that no longer made sense.
And now I wonder how much of our projected power demand is real intelligence… and how much is the hidden, compounding cost of systems quietly drifting out of alignment with reality and then spending enormous resources trying to recover from their own drift.
The communities asking whether we really need these massive facilities might be pointing at something deeper than they realize. And the industry insisting the demand is inevitable might be missing the architectural opportunity sitting right in front of us.
Because the more I sit with it, the more it seems like the biggest gains rarely come from building larger machines.
They come from building systems that understand their own state well enough to stop doing things that should never have been done in the first place.
Perhaps the debate over AI infrastructure is not really about power generation, water consumption, or data centers.
Perhaps those are simply the visible symptoms.
The deeper question may be whether future AI systems spend their time creating value or recovering from drift.
The answer to that question may determine how much infrastructure we ultimately need to build.
For readers interested in the broader architecture behind these ideas, including drift, admissibility, execution authority, external correction, and runtime governance:
— Chris Ciappa
Founder & Chief Coherence Architect
Samirac Partners
Share This Article
If you found this article valuable, share it.
Substack automatically gives every subscriber a personal referral link. When someone subscribes through your share link, it counts toward referral rewards.
Current rewards:
• 3 referrals → 1 month of paid access
• 5 referrals → 6 months of paid access
• 10 referrals → 12 months of paid access
You can share directly using the Share button on this article, or find your personal referral link here: