AI made the code cheaper. Make sure your contract noticed.

The renewal quote for next year looks a lot like last year's. Same team, same monthly rate, and one new paragraph explaining that the vendor's engineers now work with AI and deliver faster. Your finance lead reads it twice and writes one question in the margin: if they are faster, why is the price the same?

Plenty of buyers are asking it this autumn. Reuters reported in August that clients of India's big IT services firms are pushing hard on price, and the chief executive of Persistent Systems said customers want the same work for 25 to 30 percent less, delivered faster. The same report described fees moving away from hours worked and towards outcomes, and contracts getting shorter as both sides hedge against a technology nobody can forecast with confidence.

Look at what both sides of that negotiation are doing. The buyer wants a discount based on a speed-up nobody has measured on their system. The vendor either refuses, or concedes a figure it has not measured either. Haggling over the size of the discount is the wrong conversation. A better contract does not guess the saving. It finds it within a few weeks, and it decides in advance who keeps it.

Nobody knows the number, including the engineers

The natural move is to ask the team how much faster AI makes them. You will get a sincere answer that may be badly wrong. In a randomised trial published by the research group METR in July 2025, experienced open-source developers took 19 percent longer to finish real tasks when they were allowed to use AI tools, and afterwards they still estimated that AI had made them about 20 percent faster.

The tools have improved a great deal since early 2025, and we would not read that study as a verdict on today's speed. Its lasting lesson is about perception. The people doing the work are poor judges of their own speed-up, in either direction. A price built on their estimate, or on a slide in a sales deck, is a price built on a feeling.

Even where the gain is real, it is uneven. AI compresses some parts of a project far more than others, and the parts it barely touches are often the ones that set the schedule.

Follow a typical feature through a sprint. Writing the code shrinks dramatically. Writing tests gets quicker too, although someone still has to read them. Review grows, because more code arrives and every line needs a qualified person to accept it. And the slice that belongs to the buyer hardly moves at all: a decision from the product owner, access to a system, a security sign-off, an answer from the payment provider.

So the gain is largest on code-heavy, well-understood work, such as a new screen on top of a familiar API, or a migration protected by a good test suite. It is smallest where the project is waiting on people, and no contract clause changes that.

Who keeps the saving under each kind of contract

Every pricing model settles two questions, whether anyone discusses them or not. When the work turns out cheaper than expected, where does the difference go? When it turns out dearer, who pays? Before AI, estimates were wrong in fairly familiar ways. Now the error bars are wider, so the answers matter more.

• Paying by the hour or the month. Time and materials, in contract language. If the team really is faster, you keep the gain, but it arrives as more output for the same bill rather than a smaller bill. That suits a company with a deep backlog and the capacity to accept what gets delivered. If you cannot see output, you cannot tell a faster team from a padded one.
• A fixed price for the whole project. The vendor keeps any gain beyond what it assumed when it quoted. If it assumed too much, the shortfall comes back to you as change requests, thinner testing or a quietly cheaper team, usually in the second half of the project, when it is hardest to push back.
• Outcome-based pricing. Fees tied to a business result. It suits operations with a steady, countable output, such as tickets handled or invoices processed: one large provider told Reuters that about 80 percent of its finance, HR and business services contracts now work this way. For a new product the outcome is the market's verdict, which no vendor controls, so it gets redefined as features delivered, a fixed price with extra paperwork.
• Priced increments. A fixed price for a short slice of work, two to four weeks, re-estimated before every slice from what the previous one actually took. Any gain surfaces within a month and flows into the next price, so neither side carries a guess for long.

Pricing by the increment, worked through

Take a typical case. A company wants its customer portal rebuilt: accounts, billing history, support requests, and single sign-on through its existing identity provider. Last year's quotes said roughly six months for a team of five. This year one vendor offers a fixed price a third lower, citing AI. Another offers last year's monthly rate with a promise of faster delivery.

Neither offer tells the buyer what the work costs now. This is how we would set it up instead.

• Weeks one and two: a priced first slice. Pick something real and end to end: sign-in through the identity provider and the account page, against live APIs, with tests. Fixed price, acceptance criteria agreed up front, a demo at the end.
• After the demo: compare. The vendor puts the estimate next to what the slice actually took, including time spent waiting on the buyer's side. Both parties now hold a first measurement on this codebase, with these people, instead of an industry average.
• Slices two and three: re-price. Each new price uses the pace so far. If billing history went much faster than estimated because the old data model was clean, the next slices get cheaper. If single sign-on dragged because of a legacy configuration, that shows up too, early and with a reason attached.
• Around week eight: a forecast you can defend. Three or four slices in, the rest of the work can be priced from evidence, and a fixed price for the remainder becomes reasonable if the buyer still wants one. The vendor is quoting from data now, so the risk premium inside that quote should shrink.

The cost is some ceremony: a demo and a short pricing conversation every few weeks. In return the saving becomes visible, it is shared, and it arrives early. The structure also exposes a vendor whose speed exists mainly in the proposal, because a slow slice cannot hide inside a six-month total.

Do not let quality pay for the speed

There is a cheap way to look fast with AI, which is to skip whatever slows you down. Generated code that nobody reads. Tests written by the same model that wrote the code, confirming that the code does what the code does. Security checks deferred to a hardening phase at the end. Each of these looks like productivity on a burn-down chart and resurfaces later as a production incident or a penetration test finding that someone fixes on a Monday morning.

So a contract that rewards speed needs a floor under it, written into the definition of done (the checklist a piece of work must pass before it counts as finished) and checked at every demo.

• Human review you can see. Every change reviewed by a senior engineer before it reaches you, with the review recorded in your repository rather than described in a status report.
• Tests that run in your pipeline. Automated tests that run on your build system, not only on the vendor's machines, and that fail when behaviour breaks.
• Security inside each slice. Dependency and code scanning on every change, and anything touching sign-in, payments or personal data flagged for your review before it merges.
• AI usage costs stated. Whether model and tool costs are inside the rate, passed through at cost, or capped. Agentic coding tools can run up real usage bills, and that line should never arrive as a surprise on an invoice.

What to ask before you sign, whoever you hire

These questions work on any proposal, ours included. The answers matter less than whether the vendor has thought about them before you asked.

• What productivity gain is inside this price? And on what kind of work was it measured? A good answer names the assumption and says it will be checked against the first slices. A single percentage with no source should worry you.
• If it goes faster, who benefits? If slower, what happens? Listen for a mechanism, such as re-pricing or a shared saving, rather than reassurance.
• What is the shortest priced commitment? Long commitments made sense when delivery speed was predictable. Shorter cycles let both sides correct a wrong guess before it compounds.
• Who reads the AI-written code? You want a role, a process and evidence in your repository, not a statement that the team uses AI responsibly.
• What exactly is in done? If tests, review and security checks are not written into the definition, they are the first things to go when the price gets tight.
• Can the team change size without a new contract? If the same output needs four people instead of five by spring, you should be able to make that change in a conversation, not a renegotiation.

When you do not need any of this

If the job is small and well defined, say a two-week integration or a framework upgrade with a solid test suite, a plain fixed quote is fine. The uncertainty is low enough that nobody is guessing much. And if you are adding engineers to a team you already run, a monthly rate is still the right model: the gain lands in your own backlog, under your own management, and you will see it in your own sprint reviews.

The increment structure earns its ceremony on the work in between: a build of several months, with real unknowns, bought from a team you will not manage line by line. That is where the guesses are biggest and the contracts are longest. A discount agreed in October is a forecast. The pace you have measured by the end of January is a fact, and only one of them belongs in a price.