Many conversations about IT economics begin with a familiar question: What are we spending? Most CIOs can answer that for cloud infrastructure and, increasingly, for AI. The harder question is: what engineering output that spend delivers. As coding assistants and AI agents become part of software engineering, answering that question matters more. Gartner has warned of rapidly rising AI coding costs, with some organizations already spending hundreds or even thousands of dollars per developer each month. The emerging challenge is clear: enterprises can track AI spend, but often lack a consistent way to connect it to engineering outcomes.
Cloud gave enterprises computing capacity on demand. AI is extending that idea to engineering work, yet many CIOs still lack a clear view of what this capacity costs and what it delivers. Spend is typically tracked through licenses, tokens, credits and individual provider bills. This creates three problems:
- Many tools, many ways of charging. AI is now used across the software development lifecycle (SDLC), from requirements and design to coding, testing, security and deployment. A single engineering task may involve several AI tools, each charging by user, token, request, credit or agent usage. Comparing their economic value is therefore difficult.
- Tool selection can be driven by habit rather than the work. Different SDLC activities require different levels of AI capability. Routine code or documentation may need less reasoning and oversight than architecture design, security testing or a production-critical defect. Yet developers often default to the tools they know best.
- Consumption does not tell the full story. Tokens, credits, requests and seats show how much AI was used across the SDLC. They do not show what was delivered: a completed design, working code, tests passed, a vulnerability resolved or a release successfully deployed.
This is where token-based accounting reaches its limits. A more useful approach starts by normalising the engineering work being completed, so spend can be compared against consistent, quality-accepted outcomes.
Normalising the Engineering Work
One way to do this is through an AI Engineering Work Unit (AEWU): a provider-neutral, quality-accepted unit of standardised engineering work.
This does not require cataloguing hundreds of software-development activities. Start with a small set of outcome-based work families aligned to the SDLC, such as Analyse, Create, Validate, Resolve and Document, then add simple complexity levels such as Small, Medium and Large. Categories can vary by organisation; the aim is to keep them few, measurable and tied to completed engineering outcomes.
For example, a medium complexity Resolve AEWU could mean fixing a defect, passing the required tests and meeting review criteria. The work may involve a reasoning model, coding assistant, testing agent and human reviewer. Each tool retains its own pricing method, while the costs are linked to the same engineering outcome. If an illustrative task uses $1.28 of AI services and $1.60 of human review, the total cost is $2.88.
The measure becomes:
Cost per Accepted AEWU = (AI costs + technology and subscription costs + human review + rework costs) ÷ quality-accepted AEWUs
This gives CIOs a more meaningful question to ask: What does it cost to complete a standard unit of engineering work, and how does that cost vary across teams, task groups or SDLC stages?
The next question follows naturally: what is the most effective way to get that work done?
Route Work by Policy, Not Habit
This is the idea behind FIT: Fit-for-Task routing.
FIT considers the type of work, its complexity and its business risk, then applies enterprise policies to determine the best way to execute it. Those policies balance four considerations:
Quality | Cost | Speed | Reasoning Required
The policies need input from across IT and Security. Engineering defines acceptable outcomes. Security and Risk define what is permitted. Finance sets economic boundaries. AI and Architecture teams determine which models and agents are suitable, while the CIO organisation provides overall governance.
A routine documentation task might use a lower-cost approved model. A regulated defect could require stronger reasoning and human review. A production-critical issue might call for the most capable approved model and mandatory human approval. The principle is straightforward: use enough AI capability to do the work well and safely, in line with what the task requires. FIT optimises the execution path, rather than simply selecting a model. The best route may involve one model, several models, an agent, human review or a combination of these.
Measure, Learn and Improve
FIT becomes more useful when enterprises learn from what actually happened. A route that appears inexpensive can become costly after failed attempts, additional human review or rework. A measurement loop should connect AI usage to the work performed, calculate the full cost and evaluate quality, speed and human effort. That evidence can then inform the next FIT decision.
The operating model becomes:
Define the Work → Apply Policy → Execute → Measure → Evaluate → Improve
The central shift is to optimise for the completed engineering outcome, rather than the individual AI call.
Five Moves CIOs Can Make to Get Started
CIOs can begin without building a sophisticated control system. Five practical steps provide a starting point:
1. Define the work that matters. Start with a small number of work families and simple complexity levels.
2. Understand where the money goes. Build a consolidated view of AI engineering usage and costs across tools and teams.
3. Connect spending to outcomes. Link AI costs, human effort and rework to the engineering work delivered, and measure spend by task and outcome.
4. Set practical policies. Define quality, cost, security and human-approval boundaries, then route work according to those policies.
5. Compare, learn and improve. Compare different approaches to similar work and use the evidence to improve future decisions, execution paths and policies.
The objective is to answer a more useful question: are we spending more on AI, or getting better engineering outcomes for every dollar spent? The next step in AI engineering economics is to measure the work delivered, not just the tokens consumed.
This article is authored by Akash Jain, Senior Director & Partner, Consulting- Strategy & Innovation Services, AHEAD
