Software Efficiency Gives Infrastructure Teams Another Lever Beyond Adding Capacity

Inefficient code is easy to dismiss when an application feels fast. Modern infrastructure can absorb a slow function or bloated dataset without creating an obvious problem for the end user, but the cost spreads through the stack. Unnecessary computation generates data that must be moved, stored, and processed again, turning the application waste into infrastructure demand that organizations keep paying for long after the original inefficiency is forgotten.

Janne Kalliola, Founder of Coonti, has been making this argument since 2019, well before AI energy consumption brought the issue into boardrooms. His experience across software architecture, product development, and commercial leadership has shaped his view of IT sustainability as an engineering problem measured in energy and efficiency. He sees today's AI boom as an existing problem amplified by far greater amounts of compute and data.

"Waste is energy consumption that doesn't add value," Kalliola says. Applied to computing, it turns a question usually framed in moral terms into a testable one: does a given unit of infrastructure produce a proportional return?

Abundant infrastructure made software waste easy to hide

For most of the last two decades, computers have been fast enough to make bad code invisible. "Computers are so powerful nowadays that you can't really distinguish whether something's poorly made," Kalliola says. "It has to be extremely badly made before it stutters or has visible lag." That wasn't always true. When Kalliola started programming in the 1980s, poorly written software simply wouldn't run. It wouldn't fit into memory, or it'd be too slow to be useful. Those constraints forced discipline. "Today, almost anything runs, or at least limps along well enough that users don't notice," he notes.

Kalliola attributes this shift to the cornucopian paradigm, in which IT design and development practices assume there will always be more power available in the future because of Moore's Law and that the cloud offers unlimited computing power. Scaling becomes somebody else's problem, so nobody has to see the cost of ignoring it. "Computers are so much faster than human senses that we simply can't see what's happening behind the scenes," he says. "We can't see that fast or think that fast, so it stays hidden." When infrastructure feels unlimited, inefficiency doesn't register as a decision at all.

Software waste cascades across the stack

Efficient software reduces demand across the technology stack. "They're usually faster, so you get a better user experience," Kalliola says. "In the web context, search engines value speed, so you get better SEO. They typically transfer less data, so you need less network capacity. They have lower storage requirements, so you need less disk space. Less is less. It cascades."

The same applies in reverse. Inefficient software consumes more compute, and that waste spills into the rest of the infrastructure, increasing the amount of data that has to be moved and stored. What starts as a compute problem can quickly become a networking and storage problem too.

Storage tends to be treated as the passive part of the stack, where data sits until someone needs it. The energy cost comes down to how much data exists and how efficiently the system handles it. "Either you have too much data that needs to be processed, or you have inefficient ways of processing that data, or you have a combination of both," Kalliola says.

He illustrates the point with an analogy. "Imagine you're diving for pearls. If the ocean becomes ten times bigger but contains the same number of pearls, you simply have to dive much more. That takes energy." As bandwidth and storage became less scarce, the incentive to optimize weakened. Storing more data is only half the cost. What the system does with that data afterward, again and again, is the more expensive half.

AI raises the cost of inefficient software

AI accelerates the tendency to throw more compute at more data instead of asking whether the same outcome could be reached more efficiently. More data and heavier processing methods compound each other, and the risk grows when AI starts writing the software itself. A model trained on decades of code written during an era of assumed abundance is unlikely to produce lean output by default because it has little lean output to learn from.

"If we lose the craft and people no longer know how to optimize software themselves, there's a chance the AIs won't be able to do it either," Kalliola warns. That's a harder problem than any single inefficient model, because it suggests the industry's baseline for "acceptable" code is quietly moving in the wrong direction, at the exact moment AI is scaling how much code gets produced.

Why measure inefficiency before scaling

If AI makes inefficient software easier to produce at scale, teams need to measure that waste before infrastructure expands around it. "I think the only really good metric at the end of the day is energy consumption," Kalliola says. The method is straightforward. Establish a baseline, then check it with every release. A sudden increase in consumption after a change is a reason to revisit that change rather than quietly absorb the cost and scale around it.

Most organizations don't have energy-consumption data readily available, so Kalliola points to execution time as a useful proxy. Tracking whether software gets faster or slower gives teams a practical way to spot inefficiency without specialized measurement infrastructure. "This requires discipline, and it requires somebody from the technical side to say, 'This is important,'" Kalliola says. "Otherwise, it's like Don Quixote fighting windmills. You won't win because nobody is supporting you."

Optimization as part of infrastructure design

Every unnecessary computation creates work elsewhere, from additional data movement and storage to more capacity that has to be provisioned. Even genuine efficiency gains don't necessarily stay banked. "When we save something, we run into Jevons paradox. We use those savings to invest in something new, and then we end up consuming more energy," Kalliola notes.

The goal is to keep infrastructure use proportional to the value it creates. Two approaches that deliver comparable outcomes aren't equivalent if one costs an order of magnitude more to run. That puts efficiency alongside latency, availability, and security as a constraint worth designing for from the start. "If we're doing something that doesn't add value, or if we could get the same value with ten times less energy consumption, then we should choose the option that consumes less energy," Kalliola concludes.