The UK government’s trial of AI coding assistants reported an average saving of 56 minutes per developer per working day.
That is an attractive number. It is also easy to misuse. A buyer sees nearly an hour saved and expects a smaller team, a lower quote or an earlier launch date.
I would not put any of those promises into a project plan from that figure alone.
Writing code is one part of delivering software. The work also includes understanding the business rule, finding the right data, agreeing edge cases, connecting old systems, testing the result, moving it into production and helping people use it. Faster coding can expose those other constraints sooner. It does not remove them.
After 27 years in technology, I care less about how quickly a team can produce code. I care about how quickly it can turn a real business need into software that works safely in the hands of a real user.
What the government trial measured
The Government Digital Service trial ran from November 2024 to February 2025. It made 2,500 licences available across more than 50 public sector organisations. The main analysis used 424 survey responses, and 73% of respondents had at least five years of coding experience.
Users reported saving 56 minutes a day on average. Of that total, 24 minutes related to creating code or analysis, 21 minutes to reviewing it and 10 minutes to learning.
The report is open about the limits. The time savings were self-reported. Answers for different tasks may have overlapped, and optimism may have pushed estimates upwards.
The available usage data adds useful context. GitHub Copilot users accepted 15.8% of suggested code lines. Only 39% of survey respondents said they had committed code suggested by an assistant.
Drafting routine code, explaining an unfamiliar section, searching for an example and starting a test can all save time. The trial does not show that a whole software project will finish 56 minutes earlier for every developer, every day.
Productivity depends on the work and the team
One universal percentage for AI coding productivity does not exist.
In 2025, METR studied 16 experienced open-source developers working on 246 real issues in repositories they knew well. With the early-2025 tools in that setting, the developers took 19% longer when AI was available.
By February 2026, METR said that result was out of date. Its follow-up study suggested newer tools were helping more, but participation bias and unreliable time measurement meant the researchers could not give a dependable current figure.
Both studies were serious attempts to measure real work. Their different results show why I distrust sales claims that turn one study into a guaranteed saving on your project.
DORA’s 2025 software development research describes AI as an amplifier. Strong teams gain more from it. Weak delivery systems produce their existing problems faster.
That matches what I see. An experienced engineer can ask for a small change, inspect the result, spot the missing case and reject a poor dependency. A team with vague requirements, weak tests and no clear owner can generate a large pile of plausible code before anyone notices it solves the wrong problem.
The bottleneck moves
AI coding tools reduce some of the effort in producing a first version. The saved time has to go somewhere useful.
Requirements need sharper answers
An assistant can build the instruction it receives. It cannot resolve a disagreement between finance and operations about when an order becomes revenue. It will often choose a reasonable interpretation and carry on.
That speed can hide an unresolved decision inside working-looking software. Someone still needs to define the rule, name the exceptions and confirm who has authority to decide.
Review becomes a bigger job
A developer can now produce more code in a day. Review capacity does not rise automatically with it.
Large changes are harder to understand and easier to wave through. Keep changes small. Ask for one behaviour at a time. Make the developer explain why the code is correct in this system, rather than accepting that it compiles.
The UK government’s guidance for AI coding assistants, updated in August 2026, puts responsibility on the programmer. They need to understand the resulting code and take responsibility as if they wrote every line themselves.
That is the standard I would expect from a supplier as well.
Testing carries more of the load
AI can generate tests. The same AI may repeat its mistaken interpretation in both the code and the test, giving you two files that agree with each other and disagree with the business.
Good acceptance tests start with examples supplied by the people who do the work. What happens when the order has two currencies? What if the customer record is incomplete? What if the accounting system is unavailable? What must never happen without approval?
Automated tests should cover those examples. A person should still watch the complete process run with realistic data before launch.
Integration keeps its old pace
Your supplier can generate a connector quickly. The old warehouse system still has its undocumented limits. The CRM still contains duplicate records. The third-party API still has a maintenance window and a rate limit.
These constraints sit outside the generated code. They need discovery, access, test data and conversations with vendors. AI helps engineers investigate them. It cannot make another company’s system behave differently.
Measure the result that the business buys
Lines of code and assistant acceptance rates belong inside the development team. A business buyer needs delivery measures.
Before introducing an AI coding tool, record a small baseline:
- Time from an agreed change to a live release.
- Percentage of releases that need urgent fixes or rollback.
- Defects found by users after release.
- Time spent correcting avoidable rework.
- Number of changes waiting for review, testing or approval.
- User adoption of the feature once it is live.
Run the tool with one team and one type of work. Compare the same measures after six to eight weeks. Keep it if releases arrive sooner without more failures or rework. Change the process if code arrives faster and waits longer in review. Stop paying for it if the business result stays flat.
This approach also gives developers room to use the saved time properly. They can improve tests, document an awkward integration, remove an old manual step or sit with a user and understand the next problem.
What to ask a software supplier
A supplier saying it uses AI tells you very little. Ask questions about the work around it:
- Which parts of this project will AI help with?
- Who reviews and accepts AI-generated code?
- How do you stop source code, customer data and secrets reaching an unapproved service?
- How do you check packages and dependencies suggested by the assistant?
- Which automated and business acceptance tests must pass before release?
- How will you show that any time saving reached my budget, delivery date or product quality?
The August 2026 government guidance warns teams to use trusted products, keep sensitive production data and secrets out of development environments, and check dependencies introduced by assistants against trusted sources. Those are reasonable contract questions for any UK SME.
Be wary of a quote that promises a large discount because the supplier uses AI. Lower effort may justify a lower price, but the supplier should explain the assumptions and keep the quality controls visible. A short quote with no discovery, testing, security review or release support is cheaper because work is missing.
Spend the saved hour on delivery
AI coding assistants are worth using. I use them. They remove repetitive work, help explore unfamiliar code and make a capable engineer faster on the right task.
The commercial benefit appears only when the saved time improves delivery. Put it into smaller changes, faster feedback, stronger tests and clearer documentation. Measure live outcomes. Keep a person accountable for every release.
If your team is considering AI coding tools, start with the delivery process around them. An AI readiness audit can expose the data, security and workflow gaps before licences spread. For a live build, AI implementation support should connect the tool choice to a measured business result.
Judge the purchase by working software released safely and evidence that it improved the business.