"AI is bad for the environment." I ran the numbers on website builds.

At a networking event this morning I got talking to a developer from a B-Corp agency. Decent bloke, serious about sustainability, builds properly. I asked if he was using AI. Not yet, he said, mostly on environmental grounds, though they were starting to look at it. Data centres draining rivers, electricity demand tripling; you know the case, and he made it well.

I suggested the picture might be bigger than the data centres. If AI cuts the hours a developer spends at a powered-on machine, the gap might be smaller than it looks, maybe even reversed. But I was arguing gut feel against his gut feel, and neither of us had a number between us. That bothered me all the way home. So I sat down and ran them: the build, the hours at the machine, and every page view after. They land harder on my side of the conversation than I dared suggest at the time.

On this page

• First, what he’s right about
• What one prompt costs in 2026
• Nobody counts the hours at the desk
• The best objection so far
• Every visit, for years
• “But the data centres are still growing”
• What the saved hours buy
• Measure the whole system

First, what he’s right about

Let’s not pretend the macro picture is fine. The IEA puts data-centre electricity at around 485 TWh in 2025, heading for roughly 950 TWh by 2030, which would be about 3% of global demand, with AI the fastest-growing slice. That concentration lands hard in specific places: data centres take around a fifth of Ireland’s electricity, and about 26% of Virginia’s. Training GPT-3 evaporated roughly 700,000 litres of freshwater in on-site cooling, and over 5 million litres once you count the water embedded in its electricity.

The vendor numbers deserve scepticism too. When Google says a prompt uses five drops of water, that figure excludes off-site water tied to electricity generation. And there’s the rebound problem: make a thing cheap enough and people do vastly more of it, which can swallow the efficiency gains. Economists have worried about this since Jevons watched Victorian coal use rise as engines improved.

If that’s your concern, you’re right to have it. I have it. But none of it decides the question the two of us were standing there discussing, which was never “should hyperscale AI exist?” It was “should an agency use it to build websites?” Those are different questions, and the second one has maths.

What one prompt costs in 2026

The viral figure everyone quotes, half a litre of water per ChatGPT conversation, comes from GPT-3-era estimates published in 2023. It’s obsolete. In August 2025 Google published a proper methodology, counting active chips, idle chips, cooling and data-centre overhead, and measured the median Gemini text prompt at 0.24 watt-hours, 0.03 grams of CO₂e and 0.26 millilitres of water. Sam Altman has put an average ChatGPT query at about 0.34 Wh and a fifteenth of a teaspoon of water. Self-reported, yes. But directionally consistent, and Google’s own per-prompt energy fell 33-fold in twelve months.

Now the honest caveat, because a website build isn’t a median chat prompt. Agentic coding leans on big reasoning models, and a heavy response from one of those can cost 18 to 40 Wh. Across the sessions it takes to build a full site, I estimate 100 to 200 Wh of inference. Call it 150. That’s real energy. It’s also less than a fifth of a kilowatt-hour, which matters once you see what it replaces.

Nobody counts the hours at the desk

Every website ever built has had the same biggest energy input: a person sitting at a powered-on computer. The clock runs for as long as they do, and no one in this debate ever mentions it.

A from-scratch WordPress build, done properly (design, theme work, plugins, content entry, responsive fixes, the debugging that always eats a day), is realistically 20 to 30 hours at the machine. An AI-native static build in Astro and Tailwind, deployed to Cloudflare’s edge (how we build every Foundations site), takes me 3 to 5 hours of supervision. A typical developer setup draws around 75 watts. So:

The AI build uses about a quarter of the energy, and the inference everyone fears is dwarfed by the 1,500 Wh of human machine-time it removes. The water story flips the same way: grid electricity carries embedded water, a couple of litres per kWh for thermoelectric generation, so the 1.4 kWh gap is several litres of indirect water on the WordPress side of the ledger.

On the UK grid (call it 125 to 200 gCO₂ per kWh these days), the build-phase gap works out at roughly 175 to 280 grams of CO₂. As a number it’s a cheeseburger’s rounding error. But notice the sign. The AI approach wins the build phase outright, before a single visitor arrives. And the build phase is the small half of the story.

The best objection so far

I put this argument to a friend last night and she found the soft spot straight away: I’d be at the machine those twenty-five hours regardless. AI doesn’t switch my computer off, it just means more comes out of it. So where does the saving go?

It’s a genuinely interesting counter, and it deserves a straight answer. She’s right about my electricity bill: my machine draws what it draws, whichever way I build. And she’s pointing at the honest limit of this whole exercise, because attributing shared energy to individual outputs is where quantification gets properly difficult, and anyone waving precise per-project figures around should admit that. The convention carbon accounting settles on is allocation: the four hours spent on a site belong to that site, and the other twenty-one belong to whatever else they produce. On that convention, the quarter-of-the-energy comparison stands.

Take her frame instead, the machine runs anyway, and it has to cover the data centres too: that’s exactly the argument I make about them two sections down. Applied consistently, it collapses the whole build-phase comparison to the ~150 Wh of inference, a rounding error in either direction. So the two conventions disagree about the size of the build-phase win, and I’m comfortable saying I don’t know which is truer. What neither of them touches is the next section, and that’s where this argument is decided anyway.

Every visit, for years

Websites don’t spend their lives being built. They spend their lives being served, and that’s where the real carbon lives.

A WordPress page is assembled fresh on request: PHP executes, a database answers queries (30 to 100 of them per page load on typical setups), plugins pile on weight, and the visitor waits. I’ve audited local business sites taking ten seconds to load. A pre-rendered static page served from an edge node is just a file: no origin compute per request, lighter transfer, loads in a second or so (the full case against CMS bloat is here). The Sustainable Web Design Model, the industry’s standard method, ties a page’s CO₂ directly to data transferred and compute used. Lighter and faster also means lower carbon on every single view.

Run the comparison properly and you get the number I find genuinely persuasive: the one-off carbon cost of the AI build pays for itself against the per-view operational savings somewhere between 40 and 135 page views. Not forty thousand. Forty. A modest local business site clears that in its first week, and then keeps saving on every visit for the three, five, seven years it lives. Multiply across a lifetime of traffic and the operational delta buries everything that happened at build time, AI included.

Stretch it to a decade, which is not a long life for a business website, and the numbers get heavy enough to feel. At a modest 1,000 views a month, the heavy build emits something like 150 kg of CO₂ over ten years and the light one around 30 kg. The 60 to 180 kg between them is roughly 350 to 1,000 km of driving a petrol car, from one website, at small-business traffic. A site doing ten times the visits saves ten times that. Meanwhile every number at build time, the inference included, stayed under a bag of sugar.

”But the data centres are still growing”

The strongest counterargument is the macro one: doesn’t every prompt legitimise the buildout? The unit of analysis settles it. Training runs and grid expansion are fixed, systemic costs shared across billions of uses. GPT-3’s 700,000 litres divided by the hundreds of billions of queries served in its lifetime is a fraction of a millilitre each. Nobody charges one train passenger for laying the track.

One agency holding off doesn’t reduce data-centre construction by a single watt. The models run either way; that battle is fought through policy, procurement and disclosure, and it should be fought. What holding off does change is the site in front of you: it gets built heavier, over more machine-hours, and then burns more energy on every visit for half a decade. That harm is small, but it’s real, attributable, and yours. The position uses a civilisation-scale anxiety to justify a project-scale choice that the same anxiety, measured honestly, argues against.

What the saved hours buy

One more thing, and I’ll keep it short because it’s about values rather than maths. The twenty hours the AI approach saves per build don’t vanish into margin. At Originate some of that freed capacity funds websites we build for charities at no cost (the first was for a 1,000 km charity scooter ride raising money for clean water in Nepal). When a tool collapses the cost of good work, the question stops being “what does the tool cost?” and becomes “what do you spend the surplus on?” That question is ours to answer, not the tool’s.

Measure the whole system

The sustainable web movement, Wholegrain Digital and the Sustainable Web Manifesto crowd especially, built the measurement tools this whole argument runs on, and they deserve real credit for making website carbon a thing anyone can check. Next time I run into that developer, I owe him these numbers, and I suspect he’ll engage with them properly, because his instinct to take the question seriously is the right one. The challenge to any agency sharing it: use those tools on the whole system: the human hours, the build, and the operational lifetime. The scary headline is one line of the ledger.

We build to the same test: every Foundations site ships static, light and fast, because that’s what the whole-system maths rewards. Page weight and speed are the two biggest levers on a site’s per-visit footprint, and they happen to be the same things that make visitors stay and Google rank you. Our free Diagnostic scores both in about ninety seconds. The maths is the argument. Run it.