The shift from T&M to outcome-based engineering: Why AI makes it inevitable

AI spending is accelerating across the enterprise, but accountability for the value it creates is struggling to keep pace.

Gartner reports that 85% of functional leaders plan to increase AI spending in 2026, while 23% say they don’t know the return on their AI investment. In software engineering, the disconnect becomes harder to ignore as generative AI, automation, and agentic workflows change how quickly teams can produce and deliver software.

Engineering leaders can see productivity gains. Vendors can report hours saved, AI adoption, and increased output. Yet enterprises still need to understand what those gains mean for delivery cost, quality, throughput, and business results, especially when engineering engagements remain structured around people, capacity, and hours.

For CIOs, CTOs, and engineering leaders, the question is no longer simply how much engineering capacity to buy. It is whether the commercial model used to buy that capacity still reflects the economics of AI-enabled delivery.

In this article, we explore:

• Why AI is exposing the limits of traditional Time & Materials models
• What changes when engineering outcomes become the basis for value
• How enterprises can move from buying engineering capacity to buying measurable Engineering Outcomes

T&M Was Built for an Effort-Based Economy

Time & Materials (T&M) became a natural fit for software delivery when human engineering effort was closely tied to the work required to build and maintain software.

An enterprise needed a team to build, maintain, modernize, or extend its software. The engineering partner supplied the required expertise and capacity, while the client paid for the time consumed. As requirements expanded or technical complexity increased, additional effort could be accommodated within the engagement.

What the enterprise was buying

The model also offered flexibility in an environment where software requirements could evolve during delivery. Teams could scale as demand changed, address technical challenges as they emerged, and absorb additional work without renegotiating the entire commercial arrangement.

The logic behind T&M was straightforward:

More work generally required more human effort, so human effort provided a reasonable basis for determining delivery cost.

As long as the relationship between effort and output remained relatively predictable, hours served as a workable commercial unit.

The weakness wasn’t the flexibility of T&M. It was the assumption underneath it: engineering effort could serve as a reasonable proxy for the cost of producing software.

AI is now putting pressure on the relationship between effort, output, and value.

AI Is Breaking the Link Between Engineering Effort and Software Value

AI is changing the economics of software delivery because more software can now be produced with less human effort.

Generative AI and agentic workflows can support work across the software lifecycle: requirements analysis, repository understanding, architecture, code generation, testing, documentation, deployment, and operational support. Engineering teams can move through parts of the lifecycle faster without adding people at the same rate.

The important shift is not faster coding. It is greater output from the same engineering capacity.

A team using AI effectively can deliver more features, move releases forward, address technical debt, or support a larger modernization backlog without a proportional increase in engineering headcount.

Productivity creates a choice

AI-driven efficiency does not automatically become cost savings. An enterprise has several ways to use the additional capacity created by AI:

• Reinvest — Deliver more software with the existing engineering organization.
• Accelerate — Bring strategic capabilities to production sooner.
• Redirect — Move engineering capacity toward modernization, innovation, architecture, or technical debt.
• Reduce — Lower the effort and cost required to deliver a defined body of work.

All four can create value. None can be captured adequately through an hours-saved metric.

For example, saying “engineering productivity increased by 30%” describes an efficiency gain. It does not explain whether the enterprise shipped more capabilities, shortened release cycles, reduced delivery cost, improved quality, or freed capacity for higher-value work.

The distinction becomes commercially important when the engineering engagement still prices delivery through hours.

If AI allows a provider to complete the same work with fewer hours, the client benefits from greater efficiency while the traditional T&M model still measures the engagement through effort consumed. The more productive the delivery process becomes, the less useful hours become as a proxy for what the enterprise is actually receiving.

AI therefore creates a new commercial question:

If the amount of effort required to produce software keeps changing, should effort remain the primary unit used to buy software engineering?

The answer requires looking beyond productivity and toward the outcome produced by the engineering investment.

Outcome-Based Engineering Changes the Commercial Equation

Once hours stop reflecting the amount of software an engineering team can produce, the commercial model needs a new anchor.

Outcome-based engineering puts the focus on what gets delivered, how delivery performs, and what the enterprise pays for.

Engineering capacity still matters. Skills, teams, AI tools, and delivery infrastructure remain essential inputs. But none of those inputs represents the end value on its own.

From resources to measurable delivery

In a traditional engagement, procurement often revolves around team composition:

• 10 engineers
• 2 architects
• 1 QA lead
• agreed hourly rates
• expected monthly capacity

The commercial conversation can remain focused on whether the right people are available and how much time gets consumed.

An outcome-based engagement puts more weight on the delivery target.

For example, a modernization program might define commitments around:

• applications migrated within an agreed period
• release frequency
• completed product capabilities
• defect thresholds
• sprint throughput
• cost per delivered feature

Delivery Units provide a way to translate agreed engineering work into measurable units for commercial and operational management.

The important point is not the name of the unit. The unit needs to represent work the enterprise can identify, measure, and evaluate against an agreed standard.

Three models, three economic relationships

Fixed price solves a different problem. It establishes a price for a defined body of work. Outcome-based engineering goes further by linking commercial accountability to measurable delivery performance.

For an AI-enabled engineering engagement, the difference becomes material.

Suppose AI-assisted development allows a team to deliver a capability using 30% fewer human hours. Under T&M, fewer hours can mean lower revenue for the provider. Under an outcome-based arrangement, the commercial focus remains on delivering the agreed capability and meeting the agreed performance criteria.

Efficiency becomes an advantage rather than something the commercial model needs to absorb.

Accountability needs clear boundaries

Outcome-based engineering also requires more precision around responsibility.

A provider can be accountable for engineering performance, delivery throughput, agreed quality levels, and cost efficiency. An enterprise still controls business priorities, approvals, product decisions, and dependencies outside the engineering partner’s control.

A credible engagement therefore establishes upfront:

Outcome — what must be delivered
Baseline — where performance begins
Quality — what constitutes acceptable delivery
Dependencies — what each party must provide
Measurement — how performance will be evaluated
Commercial consequence — what happens when agreed targets are missed

Without measurable criteria, “outcome-based” can become little more than a new label for a conventional services contract.

With measurable criteria, the relationship changes. The enterprise gains a basis for evaluating the engineering partner on delivery performance rather than activity alone.

And AI makes the need for such a model harder to ignore. As software production becomes less dependent on human hours, the commercial relationship needs to keep pace with what engineering can actually deliver.

Making Engineering Outcomes Measurable

An outcome is only useful commercially when both sides can see the evidence behind it.

Enterprise software delivery already generates enormous amounts of delivery data. Requirements live in product systems. Code lives in repositories. Testing produces quality signals. AI tools generate usage and token data. Project systems track sprints and releases. Finance captures engineering and infrastructure costs.

The problem is rarely a lack of data.

The problem is connecting the data into a reliable view of delivery.

A feature can be marked complete while requiring significant rework. AI usage can increase while release throughput remains unchanged. Sprint velocity can rise while defect rates move in the wrong direction. Lower engineering hours can look like efficiency even when delivery has slowed.

An outcome-based model needs enough context to tell the difference.

Follow the delivery evidence

A useful measurement framework connects the major stages of delivery:

1. Demand
What capability or business requirement was requested?

2. Engineering
What work was performed across product, architecture, development, testing, and operations?

3. AI contribution
Where did AI tools or agents contribute, and how much?

4. Delivery
What was actually released, and how quickly?

5. Cost
What did human engineering, AI usage, infrastructure, and delivery activity cost?

6. Quality
Did the delivered software meet agreed quality thresholds?

7. Outcome
Did delivery achieve the agreed Engineering Outcome?

Looking at each signal independently can produce misleading conclusions. Connecting the signals creates an evidence chain from engineering investment to delivered software.

From measurement to managed delivery

This is where an AI-native delivery operating model becomes important. TechBlocks AiDE, the AI-Native Delivery Engine, brings user stories, engineering effort, AI usage, code, quality signals, token spend, and delivered business features into a connected delivery system.

AiDE combines three layers:

• Insights — establishes visibility into engineering performance, AI impact, cost, quality, and delivery.
• Delivery Engine — coordinates AI-assisted and human engineering activity across the software lifecycle.
• Governance — provides the controls, evidence, and accountability required for enterprise delivery.

The result is more than another engineering dashboard. A dashboard can show what happened. An operating model can use the evidence to influence how delivery is planned, executed, measured, and governed.

For enterprises moving toward outcome-based engineering, the distinction matters.

A CIO needs confidence in the relationship between engineering investment and business results. A CTO needs visibility into throughput, quality, architecture, AI contribution, and cost. Procurement needs measurable commercial criteria. Engineering leaders need a delivery system capable of improving performance without losing control as AI adoption expands.

Outcome-based engineering brings the commercial commitment. Connected delivery evidence makes the commitment verifiable.

As AI continues to increase software production capacity, the enterprises best positioned to capture the value will not simply measure how much AI their teams use.

They will measure what the engineering system produces with it.

The Hour Is Becoming the Wrong Unit of Value

AI is changing how much human effort software requires.

For enterprises, value still comes from what reaches production: faster releases, better quality, lower delivery costs, modernized systems, and capabilities that move the business forward.

An hourly model can measure effort consumed. It cannot, on its own, show whether the investment produced the right result.

Outcome-based engineering brings commercial accountability closer to delivery performance, allowing AI-driven efficiency to contribute to enterprise value rather than remain trapped inside an hourly equation.

The shift is bigger than changing how engineering services are priced.

It is changing what enterprises should expect an engineering partner to be accountable for.

AiDE: AI-Native Delivery Engine

Ready to Build an Outcome-Based Engineering Model?

See how measurable engineering outcomes can improve delivery accountability, cost efficiency, and AI value.

See Outcome-Based Engineering