Your Outsourcing Vendor Uses AI Now. Should You Still Be Paying Per Developer-Hour?

Why Are Companies Reopening Outsourcing Contracts Two Years Early?

Because the thing they bought is no longer the thing being delivered. Contracts signed in 2023, 2024 and even early 2025 priced software delivery as a labour input — so many engineers, at so many hours, at such a rate. Then AI-assisted delivery compressed the hours needed to produce the same output, and the price stayed exactly where it was.

This is not a hypothetical concern raised by procurement theorists. HFS Research reports that corporates are increasingly renegotiating IT services contracts within 24 months of signing them, rather than waiting for the renewal cycle. The pressure is heaviest on large deals — those with annual values above $50 million — but the underlying logic applies at every contract size, including the $200,000-a-year dedicated team arrangement that a mid-sized company signed eighteen months ago.

Phil Fersht, CEO at HFS, describes the shift bluntly: "The discussions are moving away from FTEs, rate cards and offshore ratios towards productivity commitments, outcome-based pricing and gain-sharing." What makes this cycle different from previous automation waves is speed. As NelsonHall's Gaurav Parab puts it, "AI is showing productivity gains within quarters, while in the past automation gains due to new technology took years to show up." A contract designed to be re-benchmarked every three years cannot absorb a delivery-economics change that lands in two quarters.

The uncomfortable implication for buyers: if you signed a labour-priced contract before agentic coding tools became standard in your vendor's workflow, your deal is probably mispriced relative to what delivery now costs. Not fraudulently — just structurally, in the way any fixed-input contract becomes mispriced when the input changes.

Who Captures the AI Productivity Gain — You or Your Vendor?

Under a time-and-materials or per-FTE contract, the vendor captures it by default. This is worth sitting with, because it is not obvious until you draw it out.

Suppose a workstream took 1,000 developer-hours a quarter in 2024. Your vendor adopts AI coding tools and the same workstream now takes 700 hours of human time. If you are billed per hour, one of two things happens. Either the vendor bills 700 hours and you save 30% — which is the honest outcome and does happen — or the vendor bills the same 1,000 hours against the same committed team, and the 300 hours become bench capacity, additional scope absorbed elsewhere, or simply margin.

Tripp Lake, an attorney at Dickinson Wright quoted in InformationWeek's reporting on the renegotiation wave, frames the stakes precisely: "When AI efficiency gains go entirely to the provider's margin, buyers are subsidizing a competitive advantage they funded." That last clause is the sharp part. Your budget paid for the engagement during which the vendor built its AI-assisted delivery capability. That capability is now an asset the vendor sells to your competitors.

There is a legitimate counter-argument, and any honest treatment of this has to include it. Vendors carry real costs you do not see: AI tooling licences, the senior review capacity needed to catch AI-generated defects, retraining, and the risk they absorb when AI-assisted code fails in production. A vendor that invested ahead of the market has some claim on the return. The reasonable position is not "the buyer takes 100% of the gain" — it is that the split should be explicit and negotiated, rather than defaulting silently to whoever happens to hold the pen on the invoice.

Does a Per-Hour Contract Give Your Vendor a Reason Not to Use AI?

Yes, and this is the more serious problem — worse than overpaying, because it degrades the work itself.

Eduard de Vries Sands, a former CIO now advising at PatientPoint, poses the question that every buyer on a time-based contract should be asking: "We have to move to pay-per-outcome. If you pay by the FTE, why would your provider use AI?" A vendor billing hours has a direct financial disincentive to reduce hours. Not a conspiracy — just an incentive gradient, and incentive gradients shape behaviour over quarters whether or not anyone intends them to.

In practice this rarely looks like a vendor refusing to adopt AI. It looks subtler: tooling adopted enthusiastically for internal projects and slowly for yours; efficiency gains routed into absorbing scope creep rather than reducing the invoice; a team size that never quite comes down even as the same team ships the same roadmap faster. None of it is a breach. All of it is the contract working exactly as written.

The same executive describes the magnitude of what is being left on the table: "We're able to do with 10 to 15 people what in the past took 40 to 50 offshore developers, QAs, and business analysts." Treat that as directional rather than a benchmark to hold your vendor to — it reflects one organisation's transformation, in one domain, with a particular workload mix. But even discounting it heavily, a compression of that order does not show up in a contract that prices seats.

What Does "Productivity" Even Mean When an Agent Writes the Code?

This is where most renegotiations get stuck, and where buyers who charge in with a rate-cut demand tend to lose. If you cannot define the gain, you cannot claim a share of it.

Vendors are promising a lot. A Morgan Lewis and Boston Consulting Group roundtable cited in the InformationWeek reporting noted that outsourcing providers often promise 40%-70% productivity gains from AI services, while the reality is "often more challenging" and requires operating-model redesign that most contracts were never built to accommodate. A 40-70% range is not a measurement; it is a sales band. Any productivity-sharing clause anchored to a vendor's self-reported figure will be litigated the first time it pays out.

The measurement problem runs deeper than mistrust. Brad Peterson at Mayer Brown identifies why the old instruments stop working: "Now you turn it over to AI agents. It's inherently not the same. You can't use the same service level measurements." Service levels built around staffing levels, ticket throughput and response times were proxies for human effort. When an agent handles first-pass triage, throughput stops being a proxy for anything you care about.

The practical answer is to stop trying to measure productivity in the abstract and measure a specific workstream instead. Pick one with a stable, repeatable unit of work — a defined integration, a per-ticket support flow, a release cadence for a specific service. Establish what it cost in human hours twelve months ago and what it costs now. That single comparison is defensible, verifiable by both sides, and far more useful in a negotiation than an argument about whether AI makes developers 40% faster in general. It also protects you from the reverse error: on genuinely novel architecture work, judgement-heavy design, or anything requiring deep domain context, you may find effort has barely moved — and demanding a discount there will cost you credibility on the workstreams where you have a real case.

Should You Switch to Outcome-Based Pricing Instead?

Probably not wholesale — and this is where a lot of 2026 outsourcing commentary is giving buyers bad advice. Outcome-based pricing is the right answer for a narrow set of workloads and a governance burden most buyers underestimate for everything else.

Everest Group's analysis is notably unromantic about this: while gainsharing and outcome-based pricing will continue to appear in niche cases, they are unlikely to become dominant, being complex, difficult to govern, and prone to creating misaligned incentives over time. Outcome-based models require sophisticated governance and strong due diligence, are hard to benchmark, and in multi-vendor environments can actually increase costs as providers price in the additional risk they are being asked to carry.

That last point deserves emphasis because it is counter-intuitive. When you push delivery risk onto a vendor, they do not absorb it for free — they price it, usually with a margin for uncertainty that exceeds the risk's expected cost. A buyer who moves an ambiguous, discovery-heavy programme to fixed-outcome pricing frequently ends up paying more than they would have on time-and-materials, and gets a vendor who now has a financial reason to argue that every clarification is a change request.

Where outcome pricing genuinely works is where the unit of work is repeatable and countable. Everest notes that in deals under its advisement, outcomes are priced through gainsharing on measurable improvements — days sales outstanding, cost takeout — or as output pricing: per invoice, per conversation, per minute. The pattern is consistent. Countable, repeatable units price well by outcome. Bespoke product engineering does not.

The realistic destination for most buyers is a blended structure: time-based pricing for exploratory and architectural work where you want flexibility, output or outcome pricing for the repeatable operational workstreams, and an explicit productivity-sharing mechanism sitting across the time-based portion. That is more work to draft than a flat rate card. It is also the only structure that survives another two years of delivery-economics change without needing to be reopened again.

Which Clauses Is Your Contract Actually Missing?

Tripp Lake identifies five areas that contracts signed before agentic delivery routinely fail to address. Read them as a checklist against your current agreement — most buyers find they are missing at least three.

AI tool disclosure. You are entitled to know which AI tools touch your codebase and your data. Not to veto them, necessarily, but because you cannot assess licensing exposure, data residency, or code provenance without knowing. A vendor that treats this as a trade secret is telling you something.

Prohibitions on training with your data. If your proprietary data, codebase or customer records are flowing into a model that improves for everyone, you are contributing to a shared asset without compensation or consent. This clause should be explicit and should extend to the vendor's subcontractors.

IP ownership of AI-generated output. Your existing work-for-hire language was drafted assuming a human author. The assignment mechanics for AI-assisted output are murkier, and the gap between "the vendor assigns what it owns" and "you own the deliverable outright" is exactly where disputes live. Worth reading alongside the licensing exposure that AI-generated code can carry.

Liability for AI errors. When AI-assisted code causes an outage or a compliance failure, who carries it? Jason Epstein at Nelson Mullins expects the market to follow the cloud-adoption pattern, where providers initially resisted accepting responsibility and gradually came to accept it. Early in that curve — which is where we are — the allocation defaults to whoever drafted the contract more carefully.

Productivity-sharing clauses. The mechanism by which measured efficiency gains are split rather than defaulting to margin. This is the one buyers most often skip, because it is the hardest to draft and requires the measurement discipline described above.

How Do You Open This Conversation Without Wrecking the Relationship?

Carefully, specifically, and not as an ambush. The buyers who get good outcomes here treat it as a repricing of a changed service, not as an accusation.

Start with disclosure rather than demands. Ask your vendor, in writing, which AI tools are in their delivery workflow, on which workstreams, and since when. This is reasonable, easy to answer honestly, and tells you a great deal. A vendor already using these tools openly will answer in a day. A vendor that has been quietly capturing the gain will take three weeks and send something vague.

Then bring one measured workstream, not a blanket rate demand. "Our per-ticket support cost has not moved in eighteen months while your team has adopted agentic tooling on this queue — walk me through that" is a conversation. "We want 25% off the rate card" is a fight, and one you will likely lose because the vendor can point to the workstreams where nothing has changed.

Front-loaded productivity commitments are more achievable than most buyers assume. HFS notes that providers are increasingly willing to commit to productivity improvements up front, and more open to reopening the contract if there are material changes in how services are delivered. A standing re-opener clause — either party can call a repricing review if delivery methodology materially changes — is often easier to agree than a specific number, and it protects the vendor too, which is why they will sign it.

One structural point worth raising, because it changes what any of this is worth: a productivity-sharing clause is only as good as your ability to verify the input. If your vendor subcontracts, rotates staff through a shared bench, or cannot tell you which named engineers worked on your product last month, you will never audit a productivity claim. It is one reason we run dedicated teams at StepTo with directly employed engineers named to a single client rather than a floating bench — not primarily as a contracting feature, but because it is the only staffing model where the numbers in a productivity discussion are checkable by both sides. Whatever partner you use, ask whether their model makes verification possible before you negotiate a clause that depends on it.

When Is Renegotiating the Wrong Move?

There are several situations where reopening the contract will cost you more than it recovers, and it is worth being honest about them.

When your vendor genuinely has not changed how they deliver. Plenty of smaller partners have not meaningfully adopted agentic tooling, particularly on regulated, embedded, or legacy-heavy work where the tools help less. Demanding an AI discount from a team that is not getting an AI benefit is a good way to damage a working relationship over nothing.

When you are mid-delivery on something critical. Contract renegotiation consumes senior attention on both sides and injects uncertainty into a team's planning horizon. If you are eight weeks from a launch that matters, note the issue, schedule the conversation for after, and do not let procurement force the timing.

When the real problem is that you cannot specify what you want. A meaningful share of outsourcing dissatisfaction has nothing to do with pricing models — it is a buyer who has not defined the outcome clearly enough for anyone, human or agent, to deliver it. Repricing that engagement will not fix it. Better specifications will, and no contract structure substitutes for them.

When switching costs exceed the gain. If the renegotiation is really a prelude to changing vendors, price the transition honestly: knowledge transfer, ramp-up, the productivity trough of a new team learning your domain, and the risk that undocumented context leaves with the outgoing team. A 15% rate improvement is frequently smaller than the cost of the move required to get it.

And the honest inverse of everything above: if the numbers work, your vendor is delivering, and the relationship is good, a contract that is 10% mispriced against a rapidly moving market may simply be a fine thing to leave alone until renewal. Not every structural inefficiency is worth the political capital to fix.

What Should You Do This Quarter?

A short sequence, roughly in order, that most buyers can run without external advisors.

First, find out when your contract was priced and against what assumptions. If the rate card was set before mid-2024, assume it does not reflect current delivery economics. Second, send the AI tool disclosure request. It costs nothing, it is a reasonable ask, and the quality of the response is itself informative.

Third, pick one workstream with a countable unit and reconstruct its human-hour cost twelve months ago versus today. You need one defensible number, not a programme-wide productivity model. Fourth, review your agreement against the five clause gaps — disclosure, training data, IP of AI output, liability, productivity sharing — and note which are missing.

Fifth, ask for a standing re-opener clause rather than an immediate rate cut. It is a smaller ask, vendors sign it more readily because it cuts both ways, and it converts a one-off confrontation into a recurring review. That is a better long-term position than a single negotiated discount that will itself be stale in eighteen months.

Finally, and this is the part that determines whether any of it works: decide who inside your organisation owns the vendor relationship technically, not just commercially. Productivity claims are engineering claims. If the only person who reads the invoice is in procurement, you will not catch the things worth catching.