Skip to content
SwankyForge
SwankyForge
All insights
Article11 min read

When AI cuts the hours, a fixed milestone price on published rates splits the saving instead of hiding it

Hourly billing hands every saved hour to the client, an opaque fixed price hands it to the vendor; a worked example shows a middle that both sides can check.

AI coding assistants have made parts of engineering work cheaper to produce. Buyers know it and are asking for the saving. This note is about who keeps it, and why the answer depends less on the tool than on how the work is priced.

The short version, if you are buying

There are three common ways to price the same piece of work.

  • Hourly. You pay for every hour worked. If AI tools cut the hours, you pay less. You also carry the risk of an overrun, and the vendor earns less for having become faster, so the pricing gives it no reason to get faster.
  • Fixed price, no breakdown. You know the price up front. If the work got cheaper to produce, you do not see it. The vendor keeps the whole saving until someone renegotiates.
  • Published rates, fixed price per milestone. The vendor shows hours per role at published rates, fixes the price of each milestone, and invoices only after you accept it against a metric agreed before the work started. You pay less than before and know the figure in advance. The vendor keeps the margin on the efficiency it actually achieves, and carries the risk if it does not.

The third is the model we offer: rates on the pricing page, a calculator that multiplies role hours by those rates, a price fixed once the scope is agreed, and an invoice per milestone after acceptance. The worked example below shows the arithmetic with illustrative numbers.

What the market is doing

The pressure is explicit, and it is reaching contracts before they come up for renewal.

  • Clients want the saving now. In August 2026, Reuters reported that clients of large IT services firms were demanding "the same work for 25% to 30% less", in the words of the chief executive of Persistent Systems. TCS said about 80% of the contracts in its finance, HR and business services segment are now based on outcome measures, which a person familiar with the matter described as double the share in late 2023. The same report describes a Cognizant automation deal that splits AI-related cost savings between vendor and client, according to people familiar with its terms.
  • Renegotiation does not wait for renewal. A June 2026 report republished by HFS Research describes clients reopening contracts within 24 months to capture AI efficiencies, with deals above $50 million a year under the most pressure. HFS's chief executive described the conversation as moving away from FTEs and rate cards towards productivity commitments, outcome-based pricing and gain-sharing.
  • Margins have mostly held so far. UpperEdge reviewed the Q2 2026 results of eleven large providers. Several widened operating margins: Wipro by 80 basis points to 17.3%, Tech Mahindra by 60 to 11.1%, Accenture by 20 to 17.0%. TCS's margin compressed to 24.0%, which UpperEdge attributes to wage rises and AI infrastructure spending, and Kyndryl's adjusted EBITDA margin fell from 17.3% to 14.2%. UpperEdge's reading is that AI investment is so far "funding itself rather than generating new client spend". It also notes TCS now says a 10–15% AI-driven improvement can be committed from the first day of a contract, against the traditional 3–5% spread over a contract's life.
  • The direction is set. IDC expects 30% of all engagements with service providers to be outcome-based by 2029.

Large outsourcing contracts are not a two-engineer lab's market. The mechanics are the same at $15,000 as at $50 million, though. Someone decides who keeps the saving, and the contract either shows that decision or hides it.

How big is the saving? Smaller and less certain than the headlines

Coding is a fraction of the work. Bain's 2025 Technology Report found that teams using AI coding assistants see productivity gains of 10–15%. Gains of 25–30% appear only where AI comes with a redesign of the whole process. Writing and testing code is about 25–35% of the time from idea to launch, so even a large speed-up in writing code moves the total much less.

Measurement is hard. METR's 2025 randomised trial found experienced open-source developers took 19% longer with AI tools. In February 2026 it reported that its follow-up data showed "some evidence for speedup" and that developers were likely faster in early 2026 than in early 2025. It also called that data only very weak evidence for the size of the change, because more and more developers declined to work without AI and so dropped out of the comparison. Both of its new confidence intervals still include no effect.

Promising a saving in advance is a bet. In the same Reuters report, the chief executive of Tech Mahindra said some competitors were pricing in productivity gains of 70–80% over five to seven years and guaranteeing prices on that basis, and that his company had chosen not to take that risk.

We have not measured our own saving either. A contract that promises a fixed percentage discount for AI promises something nobody can verify yet. A contract that fixes the price of a milestone and leaves the estimate risk with the vendor does not need that number.

A worked example (illustrative)

Everything in this section is illustrative. The hours saved are an assumption, not a measurement. The cost figures are placeholders, not our cost base.

Baseline. Take the RAG copilot template in our calculator: 310 hours across five roles, €14,500 at published rates and standard complexity. Treat it as the estimate without AI assistance. Then assume AI assistance cuts the hours spent on boilerplate, tests and documentation, role by role:

Role Rate (USD/h) Hours before Hours after (assumed) Where the hours go
ML engineer 50 120 108 (−10%) evaluation harness and loaders; the evaluation design is unchanged
Data engineer 45 60 52 (−13%) ingestion scaffolding, data tests
Backend engineer 40 60 45 (−25%) API scaffolding, integration tests
MLOps engineer 55 40 32 (−20%) CI configuration, dashboards, runbooks
Product manager 40 30 30 (0%) metric, scope, client conversations
Total 310 h = €14,500 267 h = €12,500 −43 h, −13.9%

We chose 13.9% because it sits inside Bain's 10–15% range for assistants alone.

Two more placeholders. An hour of delivery costs the vendor 60% of its billed rate, and AI tools cost €300 over the milestone.

Four ways to price it:

Pricing Client pays Vendor cost Vendor margin Margin per hour worked
A. Hourly, before AI (310 h worked) €14,500 €8,700 €5,800 (40.0%) €18.71
B. Hourly, after AI (267 h) €12,500 €7,800 €4,700 (37.6%) €17.60
C. Fixed at the old price, after AI (267 h) €14,500 €7,800 €6,700 (46.2%) €25.09
D. Fixed milestone priced at 288 h, delivered in 267 h €13,480 €7,800 €5,680 (42.1%) €21.27

The arithmetic. Cost in A is 60% × €14,500. In B, C and D it is 60% × €12,500 + €300. Margin per hour worked is the margin divided by the hours actually worked: 310 in A, 267 in the others. In D the vendor commits to an estimate that counts half of the expected saving in each role: ML 114 h, data 56, backend 52, MLOps 36, PM 30. That is 288 hours, and €13,480 at published rates. (The calculator rounds each role to the nearest hundred dollars, so it would show €13,500.)

What the table says:

  • B is what hourly billing does to a vendor that gets faster. The client saves €2,000. The vendor's margin falls by €1,100, and its margin per hour worked drops 6% below where it was before AI. It wins that back only if it can sell the 43 freed hours to someone else. A large firm with a queue of work can. A two-engineer lab with one or two concurrent projects often cannot. Either way, the pricing rewards slower work.
  • C is what an opaque fixed price does. The vendor keeps the whole saving and earns 34% more per hour worked than in A. The client cannot see this. When it finds out, the result is the mid-contract renegotiation the reports above describe.
  • D splits the saving in the open. The client pays €1,020 (7.0%) less than before AI, knows the figure before work starts, and pays only after accepting the milestone. The vendor earns about 14% more per hour worked than in A. Both sides can see how the price was built: hours per role, times published rates.

D also has a downside, and it belongs to the vendor. If the saving does not appear and the work takes the full 310 hours, cost is €9,000 (60% × €14,500 + €300) and the margin falls to €4,480 (33.2%). The client still pays €13,480. Carrying that risk is what entitles the vendor to the upside.

Compared with B, the client in D pays €980 more on paper. In exchange it gets a fixed figure instead of an open meter, and payment only after acceptance. Whether that is worth €980 depends on how much you trust the estimate. That is why the hours are published.

Why the metric and the acceptance step matter

A fixed price without a definition of done only moves the argument to the end of the project. Two things make option D work.

The metric is agreed before training and written into the contract. For a RAG copilot, for example, that could be the share of answers judged correct on an agreed question set, plus a response-time limit.

Acceptance comes before the invoice. You check the milestone against the metric before you pay. If AI-written code cut a corner, it shows up at acceptance, not after the final payment.

This is narrower than outcome-based pricing in the sense IDC and TCS use, which ties fees to business results. For ML systems, a business result such as revenue also depends on prices, stock, marketing and season, none of which the vendor controls. A system metric both sides can measure at acceptance is what a vendor can honestly be held to. The business result is measured afterwards, in an A/B test.

Where this does not work

Research risk. If nobody knows whether the data can support the model, a fixed price is a bet for both sides. Run a paid discovery first; the free teardown tells you whether you need one. Ours takes 2–3 weeks and costs €6k–14k.

Scope that changes every week. A fixed milestone needs a frozen scope for that milestone. If that is impossible, hourly billing with a cap is more honest.

Savings that never reach the next quote. Under D, the vendor keeps the extra margin on this milestone. On the next quote, the hours per role should reflect what it learned. If they do not fall, ask why. That check is what stops D drifting into C.

What to ask a vendor about AI savings

  1. Which parts of this work will be AI-assisted, and what do you assume that does to the hours, role by role?
  2. Is that assumption in the price you quoted? Show the hours and the rates.
  3. Who pays if the estimate is wrong, in either direction?
  4. What do we accept before each invoice, and against which metric?
  5. Have you measured your own speed-up? How, and over what window? A self-report is not a measurement: METR's participants believed they were 20% faster while they were 19% slower.
  6. Who reviews AI-written code, and which checks run on every change?
  7. Which AI tools will see our code and data, and under what terms?
  8. Will the next quote reflect what you learned on this one?

A vendor that answers these quickly has already done the arithmetic. Ours starts with the calculator on the pricing page, which shows hours and rates per role for your project.

Sources

Have a process that costs too much?

Tell us about it. The first call is free, and if AI is not the answer we say so.

Discuss your task