How to turn your vendors’ AI productivity gains into savings and value

It is reasonable to assume that your technology vendors are improving their productivity with new AI tools and models. After all, hardly a day goes by without a new one being launched, usually accompanied by studies and forecasts about how much time it could save us in our day-to-day work.

And you might think that if these tools allow your vendors to develop software in less time, then software should cost less.

But is that really the case? Not necessarily. Improving a specific task does not automatically reduce the cost of a project, nor does it mean that software will reach production sooner or with fewer defects.

And even if it does, there is another question we need to ask: how can the improvements achieved through AI be translated into value for the client?

To answer that, we first need to understand what productivity gains have been generated, at what cost and what improvements in quality, cost or capacity they deliver.

Productivity is changing, but by how much?

That is the key question, but also one of the biggest challenges we face: there is no single answer to how much AI improves software development productivity. Studies show widely varying results depending on the tasks, teams and contexts analysed, as we explored in a previous article on the impact of AI on software development productivity.

Your vendor may have introduced AI and certain activities may now take less time. That freed-up capacity could translate, for example, into more functionality, a smaller backlog or shorter delivery times.

But those improvements may also fail to materialise. Time saved on one task may reappear later in the form of additional review, correction, integration or rework.

Software development does not end when the code is generated. For an improvement to be meaningful to an organisation, it must also be sustained throughout the subsequent stages of the development lifecycle.

This does not mean that using AI necessarily makes software development worse. But improving one individual activity does not automatically improve the whole system.

It would be like widening one section of a road without looking at the next one: the traffic jam simply moves somewhere else.

In fact, the DORA 2025 report explores this idea in depth, describing AI as an amplifier of an organisation’s strengths and weaknesses. The best outcomes depend less on simply adopting these tools and more on the organisational system in which they are used.

So what matters is not whether your vendor uses AI, but whether AI is actually helping them deliver more value. And whether you can quantify that value.

Measure efficiency through the product, not tool usage

Counting licences, tokens, prompts or lines of code only measures activity and the level of AI adoption. To measure productivity, we need to look at the outcome: the software product delivered in relation to the effort and cost required to produce it, as well as the quality achieved.

In practical terms, we should be able to answer the following questions:

• Are we getting more software? The comparison should be based on accepted functionality, not the volume of code produced or the number of tasks completed.
• Has the unit cost decreased? A reduction in effort only represents an economic improvement if it reduces cost or enables more scope to be delivered within the same budget.
• Is software reaching production sooner? Any acceleration must be measured across the entire development lifecycle, not just the coding phase.
• Is quality being maintained? Savings lose their value if they result in more defects, incidents, additional review or rework.

These dimensions need to be analysed together to ensure that an improvement in one area is not coming at the expense of the others.

And to identify whether a genuine change has taken place, we need a reference point: a baseline. Ideally, this baseline should capture productivity, unit cost, delivery time and quality before AI was introduced. Alternatively, historical project data combined with functional metrics can be used to normalise the software delivered and relate it to effort and cost, providing productivity and unit-cost indicators that allow us to compare performance before and after AI adoption.

Context also matters. Not every project, team, vendor or technology responds in the same way. That is why the analysis should be segmented and the results compared against relevant benchmarks.

Benchmarking allows us to compare a vendor’s performance not only against its own historical data but also against comparable services and projects in the market. This makes it easier to distinguish between a genuine improvement, a temporary variation and a difference caused by changes in context.

And we must not forget the total cost of AI. Licences, model usage, integration, training, review and governance can reduce the gains initially observed. The final efficiency gain is not the gross improvement achieved in a single task, but the improvement that remains after these costs have been considered and we have confirmed that quality has not deteriorated.

From measurable efficiency to the contract

Once the improvement has been quantified, the contractual conversation changes completely. And this should not be seen as a conflict between client and vendor.

Vendors need to be able to recover their investment, take on risk and retain incentives to continue improving their services. At the same time, clients need to ensure that technological efficiency ultimately creates value for their organisation.

This process should be structured around mutually agreed criteria: defining which activities will be assessed, since not all of them have the same potential for improvement and establishing a baseline, comparable indicators and monitoring mechanisms. Finally, both parties need to agree on how that value will be shared, whether the improvement is reflected in price, capacity, scope, quality or verifiable commitments.

It is not about dividing up a theoretical figure. It is about building a model in which both parties can demonstrate what has improved and periodically review how the resulting value is shared.

A model that allows us to understand what software product we are receiving, how much it costs and how it compares. The question is not whether your vendor uses Artificial Intelligence, but:

Are we getting more software, with the same or better quality, for every euro invested?

For an organisation that can answer this question with data, productivity is no longer a perception. It becomes a measurable outcome that can be compared, reflected in contractual agreements and governed.

And with Quanter, you can make that happen.