Every technology supplier now claims to be AI-first, and buyers are rightly sceptical. If the tooling genuinely makes engineers more productive, the reasonable next question is: who gets that benefit, and how would I know?
Here is an honest account of how the economics actually work.
Where the saving comes from
Outsourcing saves money through two separate mechanisms, and they are often confused.
The first is labour arbitrage — the same seniority costs less in a different market. This is the larger and more reliable of the two, and it has nothing to do with AI.
The second is utilisation. An in-house team is a fixed cost whether the roadmap is busy or quiet. You carry the bench, the recruitment cost of filling a gap, and the cost of a specialist you need for six weeks a year. A supplier spreads that across clients.
AI adds a third, smaller effect: certain tasks take less time. Those tasks are real but specific — boilerplate, scaffolding, test generation, code comprehension, documentation. They are not the whole job, and they are rarely the critical path.
What AI does not change
- Requirements. Most project overruns come from building the wrong thing, and a model cannot tell you that your stakeholders disagree about the goal.
- Review and integration. Faster generation moves the bottleneck to review. That is work, and it is senior work.
- Coordination. Three teams and four dependencies cost what they always cost.
- Operations. Running a system in production is mostly judgement and availability.
So when a supplier claims AI has halved their delivery cost, the right follow-up is: on which activities, measured how, against what baseline?
The questions worth asking a supplier
- What is reviewed, and by whom? If AI-generated code reaches your repository without a named senior engineer accountable for it, the speed is borrowed against future defects.
- Where does our code go? Business-tier tools with training disabled, or somebody's personal account? Get it in writing.
- What happens to the saving? If productivity gains are real, they should show up as fewer billed hours for the same scope, or a faster date — not only as a slide in the pitch deck.
- How do you measure delivery? Time to deployed software, change failure rate and escaped defects are real. Lines of code and tool adoption are not.
- What have you stopped doing? A team that genuinely automated its documentation or regression testing can name what got cheaper. A team that has not will answer in generalities.
How to buy sensibly
Buy outcomes where you can describe them, and capacity where you cannot. A migration with a clear definition of done is a fixed-scope engagement. An evolving product is a dedicated team.
Start small and dated. A first engagement with a defined scope and a review point tells you more about a supplier than any reference call.
Insist on access, not reports. Your repository, your board, your environments, your sprint demos. Suppliers who are comfortable being watched tend to be comfortable for a reason.
Watch the seniority mix. The oldest trick in the industry is a senior-heavy proposal team and a junior-heavy delivery team. Ask who will actually be on the work, and ask again in month three.
What we think is defensible
Our clients see around a 40% saving against the in-house cost of equivalent seniority, and teams running in three to four weeks. Most of that comes from market rates and utilisation, not from AI. AI contributes speed on specific activities and better coverage on others, under senior review — which is a genuine benefit, and a smaller one than the marketing in this industry suggests.
We would rather tell you that up front than have you discover it in month four. If you want to pressure-test the numbers against your own situation, our IT outsourcing page sets out how the engagement models work, and a first conversation costs nothing.
