The commercial risk in AI-assisted development is not simply a larger token bill. It is the speed at which teams can turn weak ideas, vague requirements and redundant features into maintained software. Leaders should judge coding AI by the quality of decisions it improves, not by the volume of code it produces.
The pattern we keep seeing is a reversal of the usual productivity story: faster implementation can increase waste when demand is not disciplined. A developer who spends a day building an unnecessary feature has made a mistake. A developer and an AI system that build it in an hour have made the same mistake easier to repeat, review and deploy.
That changes the business problem. The scarce resource is not only model capacity. It is attention from product managers, security teams, testers, operators and users. Every generated pull request creates downstream work, even when the code itself costs little to run. Review, integration, documentation and eventual removal are operating costs. The token count is visible; the organisational drag is usually not.
This is why software efficiency should be treated as an engineering control, not a sustainability slogan. Recent research from GitHub and the Yale Program on Climate Change Communication found strong interest among surveyed GitHub users in tools for energy-efficient code, practical guidance and measurement. The authors also caution that the sample was drawn from GitHub users who opted in to marketing communications, so it should not be treated as representative of all developers. The useful conclusion is narrower: there is demand for evidence that helps teams identify and remove waste, but interest alone does not create a measurement practice.
Consider a product manager asking a platform team to add an internal dashboard because several executives want more visibility into service performance. An AI coding assistant can produce the interface, queries and access controls quickly. But if the underlying decision is not defined, the team may ship another dashboard that nobody uses, add recurring data-processing costs and create a new surface for permissions and maintenance. The assistant has performed well as a demonstration. The organisation has performed poorly as an operator.
A better workflow would make the request earn its implementation. What decision will the dashboard change? Who owns that decision? What existing report or alert is insufficient? If those answers are weak, the cheapest and most sustainable output may be a rejected build, a small change to an existing report or a two-week manual test. AI can still help, but its first job is to expose ambiguity, not conceal it with polished code.
The strongest objection is that careful gates could erase the speed advantage teams bought the tools for. That objection is valid when governance becomes another approval queue. The answer is not to review every prompt. It is to place lightweight checks at points where waste becomes expensive: before a new capability is commissioned, before generated code enters a critical path and after release, when usage can be observed.
GitHub’s related research points toward a practical standard: identify unnecessary compute, propose a change, test the result and let maintainers decide what ships. That standard applies beyond energy use. It also tests whether a feature earns its complexity, whether a workflow removes work or merely relocates it, and whether greater development capacity is producing better choices.
The real shift is therefore organisational. AI makes software supply more elastic. That makes demand quality more consequential. Companies that connect generation to clear decisions will reduce waste and increase capacity; companies that measure success by code produced may simply manufacture a larger backlog of obligations.
