In this article 11 sections
AI can change the effort required for particular development tasks, but a faster coding task does not establish a cheaper finished product. Total cost includes deciding what to build, reviewing and integrating the work, operating it and fixing failures. Compare equivalent outcomes and include that full lifecycle before claiming savings.
A prototype that once felt expensive can now appear surprisingly quickly. That changes what a founder can explore before hiring a team. It does not, by itself, answer what a dependable product will cost to deliver, support and improve.
The market conversation often moves between three different quantities: how fast a developer finishes a task, how much useful output a team produces and what a buyer pays an agency. Those quantities can move differently. This article examines published evidence and offers an editorial framework for reading a proposal. It is not an original benchmark or a survey of current agency prices.
Start with the unit being measured#
| Claim | What would help establish it | What would not be enough |
|---|---|---|
| A task is faster | Comparable tasks with time and quality recorded | A striking demonstration |
| A team creates more value | Useful accepted outcomes over a defined period | More generated code |
| A product costs less | Equivalent scope, quality and lifecycle cost | A cheaper first prototype |
| Agency prices are falling | Comparable transaction or quote data over time | One supplier announcing a discount |
Before accepting a claim, ask about the baseline. A developer unfamiliar with a codebase, an expert maintaining their own project and a founder building a disposable prototype face different work. Tools and practices also change. A result tied to one period should keep that date attached.
What the METR studies actually support#
In its February 2026 update, METR restated that its early-2025 experiment found experienced open-source developers took 19% longer on assigned tasks when AI was allowed. The update also explained that the later experiment faced substantial selection effects: some developers and tasks were less likely to enter a study that sometimes required working without AI. METR judged the newer data an unreliable signal of the current productivity effect.[1]
A separate METR survey published in May 2026 covered 349 technical workers. Respondents reported median gains in the value of their work of 1.4–2 times, depending on the question. METR explicitly cautioned about the magnitude of self-reported gains.[2]
These findings should not be collapsed into “AI slows developers down” or “AI halves build costs”. The first concerns a particular experimental setting and period. The second is a survey of perceived changes in work value. Neither measures the price of a comparable startup product purchased from an agency.
The work around the code still belongs in the budget#
A delivery budget includes discovering the problem, defining the first journey, designing the experience, implementing it, checking it and operating it. AI may help with several of those activities. The economic result depends on how much effort changes in each one and whether new review or coordination work appears.
An integration can be quick to generate and slow to reconcile with a client’s actual data. A page can be quick to assemble and difficult to make understandable to the intended user. A useful prototype can reveal that the business needs a different workflow. That learning has value even when it does not reduce the eventual build invoice.
Ask a team to separate initial implementation from the evidence required for release. Our production-readiness checklist covers permissions, recovery and operational responsibilities that a short demo cannot establish.
A simple example shows why task savings do not equal project savings#
Suppose a fictional project budget is £40,000. Assume £16,000 relates to a set of implementation tasks and £24,000 to all other work. If the implementation portion becomes 25% cheaper, with scope and quality unchanged and no additional review cost, the saving is £4,000. The total falls to £36,000: a 10% reduction, not 25%.
This is arithmetic, not a market estimate. The assumptions could be wrong for your project. The point is to make the share of affected work visible. If faster implementation leads the buyer to request more features, the same budget might instead buy more scope. If review costs rise, part of the saving may disappear.
A proposal should tell you which of those outcomes it expects. Otherwise “AI-powered delivery” is a description of a tool choice, not an explanation of the economics.
Ask where the benefit appears in an agency proposal#
Does the agency promise a lower price, an earlier usable release, more experiments or better support within the same budget? Ask for a bounded milestone and the evidence that would demonstrate it. Compare the same scope, quality requirements, handover and support period across proposals.
The commercial model matters too. Under a fixed fee, a supplier may keep part of an efficiency gain in exchange for carrying delivery risk. Under time and materials, lower effort may reduce the invoice, but only if rates, scope and other work remain comparable. A retainer may turn the gain into more available capacity. Our pricing-model guide explains the distinctions.
The Cabinet Office’s agile contracting guidance links commercial choices to delivery uncertainty.[3] The practical implication for a buyer is to define what is fixed and what can change, rather than assuming a new tool makes every dimension predictable.
Measure one real release before extrapolating#
Choose a meaningful outcome and record elapsed time, team effort, tool costs, review effort and defects that escape into use. Include the work needed to support the result. Keep the comparison fair about scope and the experience of the people involved. If conditions differ, report those differences.
Then decide what the result changes. Perhaps you can test more ideas cheaply. Perhaps a narrow application is now viable. Perhaps the constraint has moved to distribution, data access or customer adoption. Those are useful discoveries even when they do not support a universal claim about falling software prices.
For planning your own release, use the MVP cost guide as a set of illustrative scenarios, then seek a proposal against your actual scope. The question worth answering is how much your next dependable outcome costs, and what evidence would make that estimate more reliable.
Keep the study limitations beside the result#
The May 2026 METR survey used a convenience sample, not a representative cross-section of the software industry. About 2% of emailed invitees responded. The 349 respondents included several technical occupations, and the reported value gains reflect their perceptions. Those details limit any claim about a typical developer, a particular product or an agency price.
| Evidence | What it measures | What it does not establish |
|---|---|---|
| Early-2025 METR experiment, discussed in its 2026 update | Task completion time in the particular developer/task setting | A universal effect of current tools across all development |
| METR early-2026 survey | Self-reported changes in technical work value | Causal productivity gains or representative industry prices |
| Your matched delivery record | Effort, cost and accepted outcomes under your stated conditions | A market-wide conclusion without broader evidence |
Keep the original study date, population and measurement with any quoted finding. A newer publication may describe older tasks. A percentage about time and a multiplier about perceived value are not interchangeable measures.
Add review cost to the savings calculation#
Return to the fictional £40,000 project above: a £4,000 implementation saving reduces the total to £36,000 only if other costs stay unchanged. If additional review costs £2,000, the revised total is £38,000, a net saving of £2,000 or 5%. If the scope or quality changes, record that too.
Use the worksheet to enter the baseline, revised estimate, actual cost, evidence and uncertainty for each workstream. Keep discovery, design, implementation, review, integration, launch, tools and support separate. That makes it possible to see whether work disappeared or moved to another person.
For a real buying decision, ask what benefit the supplier commits to and how it will be observed: earlier usable delivery, lower fee, more validated experiments or more capacity. A tool choice can support any of those, but does not prove them without the relevant evidence.
Put this guide to work#
Frequently asked questions#
Does faster coding mean a cheaper software project?
Not necessarily. Coding is one part of the total, and review, integration, operation or expanded scope can offset a saving. Compare the full cost of an equivalent accepted outcome. The worked example shows how a task-level change translates into a smaller total-budget change.
Did METR prove that AI always makes developers slower?
No. The early result concerned experienced developers and particular tasks in an early-2025 setting. METR’s later update discusses challenges in measuring newer effects. Preserve that context instead of turning one experiment into a universal claim.
Does the 2026 survey prove productivity doubled?
No. It reports perceived changes in work value across a self-selected technical sample, with different question formulations producing different estimates. Self-report and convenience sampling limit causal and industry-wide conclusions. It is not a study of matched agency invoices.
Should an agency pass every AI saving to its client?
That depends on the commercial agreement. A fixed-fee engagement, time-based contract and capacity retainer allocate benefits and risks differently. Ask what is promised and compare the outcome and total terms rather than assuming a tool creates an automatic discount.
How can I measure the effect on my own project?
Record comparable scope, accepted quality, effort, tool charges, review and correction, elapsed time and support. Note differences in people and tasks. A small local comparison can guide your next decision without establishing a universal productivity rate.
Sources and methodology#
This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.
- METR: We are Changing our Developer Productivity Experiment Design ↗
24 February 2026. Explains the earlier result and selection problems in the follow-up experiment.
Accessed 16 October 2026 - METR: Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity ↗
11 May 2026. Survey of 349 technical workers; self-reports are not a causal estimate of agency costs.
Accessed 16 October 2026 - Cabinet Office: Contracting for Agile Guidance Note ↗
Published guidance, updated 20 June 2023. Its public-sector context differs from a private agency engagement.
Accessed 16 October 2026
Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.
Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.
MVP Build Editorial. “Is software getting cheaper to build, or just faster to prototype?.” MVP Build, 16 October 2026.
https://mvpbuild.xyz/markets/software-build-economics/