AI is making IT faster and better, but is this sustainable?

It feels like every IT conversation now has the same subtext: move faster, ship more, automate everything. I’m all-in on using AI and LLMs to remove toil, improve developer productivity and bring more value, but I’m increasingly concerned we’re sleepwalking into a new cost problem.

From AI productivity to AI burn rate

A few years ago, the industry had a clear cost control push: cloud cost optimisation, ‘be frugal’, clean architectures, right-sizing and not treating the cloud opex model like a credit card with an unlimited balance. Teams built practices around this because they had to.

Now, the centre of gravity has shifted again: the narrative is less about (cost) efficient execution and more about ‘better and faster’ at almost any cost. And we hear public takes like: ‘If a €500k salaried developer isn’t spending €250k in tokens, they’re not doing their job.’

These are dangerous statements, not only from individual and company cost perspectives but for the whole of humankind from a sustainability perspective. This mindset normalises waste, blurs accountability and subtly pushes organisations towards a spend pattern that mainly benefits the companies selling tokens, compute and platforms. If we don’t put guardrails in place, ‘AI productivity’ will quietly turn into ‘AI burn rate’. In fact, I’d argue we’re already starting to see this. With AI hype trumping sustainability, frugality and accountability, unsustainable operating models are emerging where consumption exceeds production.

Why this hits IT (and software engineering) particularly hard

The danger stems from potential lack of engineering discipline: no budgets, quotas, prompt/version control, evaluation gates, measurement, clear adoption strategy or real accountability/organisation around adoption.

LLMs are variable-cost by design

A ‘small’ prompt habit at scale easily becomes a recurring bill. Uneducated AI tool use can lead to incorrect and inefficient usage that fails to bring the desired outcome or value and, more importantly, leads to unexpected and uncontrolled costs. Extrapolate this over large organisations, countries and the entire world, and you have sustainability, environmental and energy availability risks as well as cost risks. Therefore, it’s worth considering if each small patch, fix or feature would be better addressed by old-fashioned automation created efficiently by a person, or whether it should be executed (and potentially re-executed) by an AI tool/agent. Combining the two worlds efficiently is the key here – creating a practice that balances human effort, automation, machine learning, generative AI and other engineering fields.

Tool sprawl

Copilots, agents, evaluation suites, vector databases, tracing, orchestration – each adds cost and operational overhead. These tools are evolving fast, and companies spend tremendous time and effort evaluating different options and methods, which can lead to recurring re-engineering of the whole practice.

Moreover, each tool needs support – and you need to (re)train teams to be efficient.

Agentic AI is seen as the solution to everything

There are clear risks that come from seeing AI as the hammer to use for all problems, rather than using the full engineering toolbelt. While agents are definitely great for efficient and immediate task execution in the IT space, you need to be careful about how you design, monitor and govern them.

For example, without proper design and control, you can end up with agents that loop aimlessly: retries, pings between different agents, repeated MCP and tool calls, multi-step plans, long contexts... Great demos can ultimately lead to surprisingly creative and complex execution steps, with low accuracy when it comes to solving your original problems.

You need to design your agent fleet for tasks that are small and easy to control/validate. For the AI to be as accurate as possible, you need to ensure the context is clear and unpolluted, which means it’s generally better to orchestrate multiple purpose-built agents instead of a few general-purpose ones.

Sustaining the human side of AI adoption

For some years, discussions about developer experience have focused on cognitive load, extra mental burden caused by tool sprawl, context that’s too wide to manage and continuous workflow interruptions. For the change management needed in AI adoption, this isn’t currently a focus area – and it definitely should be.

In this regard, talk about AI adoption misses a key element – ensuring sustainable change for the workforce. I don’t mean the ‘AI is going to take my job’ discussion, but rather how sustainable it is to expect information workers to focus only hard problems while letting AI take away the toil – but still measuring them on 40-hour-week effort rather than the outcomes they produce together with AI colleagues.

There should be KPIs to measure not only AI adoption and associated efficiency gains, but also the sustainability of ways of working and employee Net Promoter Score (eNPS). Otherwise, companies risk cutting short AI adoption benefits because employees rotate too quickly or burn out, meaning the organisation loses that all-important tribal knowledge.

How FinOps helps avoid failed AI implementations.

Discover how FinOps for AI helps organisations control AI costs, optimise model usage and scale AI initiatives sustainably without budget overruns.

Practical guardrails: Use AI to automate work, not automate spend

To be clear, I’m not anti-AI. AI and LLMs absolutely have a place in automation, operations and software development. But we shouldn’t treat them as blunt instruments. We need to be intentional about where they help, how we run them and what we expect in return.

Here are the best practices I recommend:

• Start with the process: Map the workflow you want to improve (e.g. tickets, incident triage, access requests, runbooks, root cause analysis, architecture analysis, cost optimisation) and automate the steps, not the entire organisation.
• Right-size the model: Use smaller/cheaper models for classification, routing and extraction; reserve larger and more capable models for genuinely hard reasoning.
• Set budgets and quotas: Per team, per service and per environment (dev/test/production). Treat tokens like any other metred resource.
• Build in cost observability: Cost per ticket, cost per change, cost per incident, cost per feature...if you can’t measure it, you can’t improve it.
• Prioritise retrieval and tooling over raw generation: Grounded answers, constrained actions and deterministic tools reduce rework and hallucination-driven loops.
• Use caching and context discipline: Reuse results, keep prompts small, avoid ‘send the whole repo’ patterns and summarise aggressively.
• Evaluate quality systematically: Cheap calls that produce wrong output are expensive. Add tests, golden sets and go/no-go gates.
• Design agents defensively: With time-outs, max-steps, retry ceilings and ‘fail closed’ behaviour.

One of the best uses I’ve seen is treating LLMs as a coach, sparring partner and real colleague. This involves helping engineers explore options, challenge assumptions, draft implementation approaches and accelerate learning. This is very different from delegating every step to an agent and hoping the invoice stays reasonable. Measuring architects and developers on the outcome they produce versus the bill they generate might not be a bad idea either!

We’ve been here with cloud adoption...let’s not repeat it

That pattern of speed first, bill arrives, everyone scrambles to retrofit discipline...we can do better with AI.

Yes, build faster. But also build frugally and sustainably, with engineering rigour and a clear link to IT outcomes.

And I do believe this is where we could help you 🙂