In July 2025 the research nonprofit METR published a randomized trial of AI coding tools on real work. Sixteen experienced open-source developers completed 246 tasks in their own repositories, and each task was randomly assigned to "AI allowed" or "AI not allowed". With AI, tasks took 19% longer. Before the study the same developers expected AI to speed them up by 24%. After it, they still believed it had made them about 20% faster.
That gap between felt speed and measured speed is the useful part for anyone buying software. Vendors now advertise AI-accelerated delivery and price it in. Some of the saving is real. Most of the claim is about typing, applied to a budget that is mostly not typing.
This note covers what the 2025 data says, where the hours in a machine-learning project go, and what to ask a vendor who quotes you an AI discount.
What the 2025 data says
Four sources, four methods. None of them supports the idea that a project costs half as much because the code was written with an assistant.
| Source | Method | Finding |
|---|---|---|
| METR, July 2025 | Randomized trial: 16 developers, 246 tasks, repositories averaging 22k+ stars and 1M+ lines of code | 19% slower with AI; developers believed they were about 20% faster |
| Stack Overflow Developer Survey, July 2025 | Survey, 26k–34k answers per question | 84% use or plan to use AI tools; 46% distrust their accuracy, 33% trust it; 66% name "almost right, but not quite" as the top frustration |
| Google DORA report, September 2025 | Survey of nearly 5,000 technology professionals | 90% use AI at work; AI adoption is linked to higher delivery throughput and, still, to lower delivery stability |
| Bain Technology Report, September 2025 | Industry research | Teams with assistants see 10–15% productivity gains; writing and testing code is 25–35% of the time from idea to launch |
The METR result has limits that its authors state plainly: a small sample, experienced developers on large codebases they already knew, and early-2025 tools (Cursor Pro with Claude 3.5 and 3.7 Sonnet). It does not show that AI slows everyone down. It shows two narrower things. Self-reported speed-ups are not evidence. And on mature, complex code, the time spent prompting, waiting, reviewing and correcting can cancel the time saved on writing.
The surveys point the same way from a different angle. Use is routine: 51% of professional developers in the Stack Overflow survey use AI tools daily, and DORA's respondents spend a median of two hours a day with them. Confidence is not: 45% of Stack Overflow respondents say debugging AI-generated code takes more time, and 30% of DORA's respondents report little or no trust in AI-generated code. DORA's summary is that AI amplifies what a team already is. Strong teams get faster. Teams with weak tests and slow feedback ship more changes and break more of them.
Why cheaper typing does not mean a cheaper project
Bain's two numbers are enough to see the ceiling. If writing and testing code is 30% of the time from idea to launch, and an assistant makes that part 30% faster, the whole project gets 9% faster: 0.30 × 0.30 = 0.09. If code became free and instant, the other 65–75% of the work would still be there. Engineers know this as Amdahl's law: speeding up one stage of a pipeline is bounded by the share of time that stage takes.
The rest of a project is specification, data work, integration, review, testing, evaluation, deployment and operation. Each has its own reason not to shrink at the same rate.
- Specification is a conversation with the people who own the problem. An assistant can draft the document. It cannot decide that the metric is margin rather than revenue.
- Data work is mostly finding out what a column means, who owns the table, and why some rows are duplicated. Writing the SQL was never the slow part.
- Integration time goes into another team's API, credentials, rate limits and release windows.
- Review gets heavier. More generated code per day means more code to read per day, and code that is almost right is the most expensive kind to review because it looks finished.
- Evaluation and operation run on a calendar. You wait for a week of traffic, a month-end close, or a holdout group to accumulate enough data.
DORA's stability finding is the measured version of the review point. Teams ship more changes, and without strong automated tests and fast feedback loops, more of those changes fail.
Where the hours go in an ML project
The table below is illustrative. It is our rough split for a mid-sized machine-learning project, such as a recommendation or forecasting system wired into an existing product, together with our assumptions about how much AI assistance saves in each phase. The percentages are planning opinions, not measurements. Replace them with your own and redo the sum.
| Phase | Share of hours | Hours of 600 | Assumed AI saving | Hours saved |
|---|---|---|---|---|
| Discovery: metric, baseline, specification | 10% | 60 | 0% | 0 |
| Data access, cleaning, feature pipelines | 25% | 150 | 15% | 22.5 |
| Modelling and experiments | 15% | 90 | 20% | 18 |
| Integration with your systems | 15% | 90 | 20% | 18 |
| Testing, evaluation, code review | 15% | 90 | 0% | 0 |
| Deployment, monitoring, rollback | 10% | 60 | 10% | 6 |
| Demos, acceptance, handoff | 10% | 60 | 0% | 0 |
| Total | 100% | 600 | 64.5, about 11% |
The reasoning behind each row:
- Discovery gets nothing because its output is decisions, and decisions come from the business.
- Data work gets a modest saving. Assistants write queries, parsers and validation checks quickly, but most of the hours go into waiting for access and understanding the data.
- Modelling and integration get the largest saving because they contain the most pattern code: training loops, API clients, serialisation, configuration.
- Testing and review net to zero. Assistants write test scaffolding fast, and the extra generated code adds review time. Teams with strong test suites may see a gain here; teams without them may see a loss.
- Deployment saves a little on configuration templates. Waiting for a canary release to collect traffic does not get shorter.
At our published ML engineer rate of €50 per hour, 600 hours is €30,000 and 64.5 hours is about €3,200. That is the order of magnitude of an honest AI discount on a project of this shape: real, worth having, and nowhere near half. It also happens to land inside Bain's 10–15% range, which is a sanity check rather than a proof.
Bain's other figure is the more interesting one. Companies that redesigned the whole process around AI, rather than only handing out assistants, reported 25–30% gains. That saving comes from changing what happens between the lines of code: how specifications are written, how review works, how releases are tested. It is a process change, and it costs effort before it pays. Bain also notes that three out of four companies say getting people to change how they work is the hardest part.
How the developer's job changed
The work moved from writing to specifying and checking. A developer with an assistant spends less time on the first version and more time on three things.
- Precise instructions. The assistant does what the specification says, so a vague specification now produces plausible wrong code faster.
- Reading and correcting output. This is where the "almost right" frustration lives. Wrong code that fails loudly is cheap. Code that passes the obvious test and fails on the edge case is expensive.
- The checks that make speed safe. Tests, evaluation sets, type checks, staged rollouts.
For machine-learning work the third point carries most of the weight. A model change that looks right in a notebook can lower a business metric in production. An assistant can write the evaluation harness. It cannot decide what the evaluation set should contain, or what a regression costs the business.
Where the savings show up
Our view, which is an opinion and not a measurement: assistants cut real time on
- prototypes and throwaway analysis, where almost right is good enough to learn something;
- code with a clear pattern: API clients, data classes, configuration, schema migrations;
- unfamiliar libraries, where the assistant replaces an hour of reading documentation;
- first drafts of tests and documentation, which a person then corrects.
They save little on decisions, waiting, coordination and review. A credible AI discount should be consistent with that split.
What to ask a vendor promising an AI discount
- Where exactly did AI cut hours? Ask for the estimate by phase, with and without assistance. A discount that cannot be placed in a phase is a sales discount. That is fine, but it should be called one.
- Who reviews AI-written code, and how? Ask whether a person reviews every change, what they check, and whether review time is in the estimate.
- How is quality measured? Tests on the critical paths, an evaluation set for model behaviour, a change failure rate. If the answer is that the code works, ask how they know.
- What happens when generated code is wrong in production? Monitoring, rollback and an on-call owner belong in the plan, not in a later change request.
- Where does the repository live? If the code sits in the vendor's account until the final invoice, you cannot check any of the above while it still matters.
How we handle it
Our rate card is published per role and per hour, so any estimate we give can be checked as hours times rate, phase by phase. You see a working demo every week, the repository lives in your organisation from the first day, and each milestone is invoiced only after you accept it. Typical project ranges are published next to the rate card, and a teardown prices discovery, proof of concept and production separately. If AI assistance makes a phase faster, it shows up as fewer hours on the invoice, not as a promise in the proposal.
Sources
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Stack Overflow, 2025 Developer Survey: AI, July 2025 — https://survey.stackoverflow.co/2025/ai
- Google, How are developers using AI? Inside our 2025 DORA report, September 2025 — https://blog.google/technology/developers/dora-report-2025/
- Google Cloud, Announcing the 2025 DORA Report, September 2025 — https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- Bain & Company, From Pilots to Payoff: Generative AI in Software Development, September 2025 — https://www.bain.com/insights/from-pilots-to-payoff-generative-ai-in-software-development-technology-report-2025/