Does AI Make Software Development Faster? What Actually Shortens Delivery in 2026

The 10,000-hour problem

The team behind LabOperon had a clear goal. Take a laboratory's daily work (sample intake, testing, instrument schedules, results, release) out of spreadsheets and paper logbooks, and put it into one controlled system every analyst could trust.

The first estimate came back at 10,000 hours. For a normal-sized delivery team, that meant more than a year before the first analyst logged in. That was the visible problem: time and money. The harder one was the one nobody wanted to say out loud. Everyone involved had seen projects like this before, and knew that 10,000-hour estimates rarely stay at 10,000 hours. Underneath both sat a simple frustration. The lab already knew exactly how its work should run. Its SOPs described it in detail. Why should turning that knowledge into software take the better part of two years?

This is where 12Grids came in. We had seen the same pattern across more than 500 projects: most of the hours in a build are not spent writing code. They go into understanding the process, turning it into specifications, testing, fixing and documenting. So we didn't promise to type faster. We proposed changing where the hours went.

The plan had three parts. First, draft the requirements from what the lab already had (SOPs, forms, existing spreadsheets) and let the people who do the work correct them. Second, build with AI producing routine code and integrations from those approved specifications, with engineers reviewing every line before it was merged. Third, generate tests from every requirement and write the documentation as the work happened, not in a rush at the end.

The alternative was the familiar one: a long build, a late testing phase that exposes everything the specification missed, and documentation reconstructed under pressure before go-live. Instead, LabOperon was delivered in 5,300 hours against the 10,000-hour estimate, with better scalability and a stronger security posture than the original specification called for.

That result is not what most of the industry reports. The reason why is the most useful thing an IT leader can understand about AI in software delivery right now.

The industry's confusing answer

Ask whether AI makes software development faster and the research gives you every possible answer.

In a controlled study by GitHub and Microsoft researchers, developers using GitHub Copilot finished a single, well-defined coding task about 55% faster. A randomised trial with 96 Google engineers found AI features made them roughly 21% faster on a complex enterprise task. Then, in July 2025, the research group METR ran a randomised trial with experienced open-source developers working on codebases they knew well. With AI tools, they took about 19% longer, while believing the tools had made them around 20% faster. That finding has been debated since, including by the researchers themselves, and it may not hold for every kind of work. But the perception gap has not been explained away.

Meanwhile, adoption keeps climbing and confidence keeps falling. Stack Overflow's 2025 survey of more than 49,000 developers found 84% use or plan to use AI tools, while only 29% trust the accuracy of what those tools produce. Their most common complaint: output that is almost right, but not quite.

These results look contradictory. They aren't. Look closely and every one of them measures the same thing: how long a developer takes to complete a coding task. None of them measures what a CIO actually pays for, which is working software, delivered, in production, that the business can rely on.

Faster tasks, slower systems

The clearest evidence of the gap between those two things comes from system telemetry rather than surveys. Faros AI's 2026 engineering report analysed two years of data from 22,000 developers across more than 4,000 teams. Under high AI adoption, task completion per developer rose 34% and epics completed rose 66%. So far, so good.

Downstream, the picture reversed. Bugs per developer rose 54%. The ratio of production incidents to pull requests more than tripled. Median review time grew fivefold, and 31% more pull requests were merged with no review at all. Veracode's separate analysis of more than 100 models found AI-generated code introduced well-known security vulnerabilities in 45% of test cases, and that security performance had not improved as models got better at producing code that works.

Engineers have a name for what's happening here. Amdahl's law says that speeding up one part of a process only speeds up the whole by the share of time that part represents. In business software, writing code is typically well under half of the total effort. Speed it up dramatically, and the remaining work (clarifying requirements, reviewing, testing, fixing, documenting) becomes the bottleneck. Worse, faster code generation feeds more work into exactly those stages.

That is why a team can be busier than ever and still deliver on the old timeline. AI made the smaller half faster and quietly made the larger half heavier.

HOW AxON APPROACHES THIS

This is the problem AxON, our AI delivery platform, was built to solve. Rather than applying AI only where code is typed, AxON puts it to work across the whole delivery (scoping, design, build, testing and documentation) with engineers accountable for every output. It is model-agnostic by design: each task goes to the model best suited to it, not to a single vendor. It is also built to use models efficiently, which keeps both our delivery costs and our clients' running costs down. AxON is how we build, not something clients license. What they receive is standard code and complete documentation they own outright.

It isn't the model

Much of the online debate treats this as a question of which model or tool is best. That is the wrong question, and it goes out of date every few weeks.

The choice today is genuinely global. Closed frontier models come from OpenAI (GPT), Anthropic (Claude), Google (Gemini) and xAI (Grok). Open-weight families such as Meta's Llama, France's Mistral, and China's DeepSeek and Alibaba's Qwen can be hosted privately. Regional models matter too: the UAE's Technology Innovation Institute builds Falcon, and Jais was developed in the UAE for Arabic. On the tooling side, teams use GitHub Copilot, Cursor, Claude Code, OpenAI's Codex, Gemini Code Assist, Amazon Q Developer and JetBrains AI, among many others. Leaderboards reshuffle monthly.

For an organisation commissioning software, four criteria matter more than any benchmark:

1. Fit for the task. Different models are stronger at different work: reasoning over long documents, generating code, following strict formats. Mature teams route tasks rather than standardising on one model.
2. Where the data goes. For EU and Gulf organisations especially, hosting location and data handling can rule options in or out before quality is even considered. Open-weight models allow self-hosting when data cannot leave your environment.
3. Cost per completed task, not price per token. A cheaper model that needs three attempts is not cheaper.
4. Governance. Can you log what was generated, by which model, and who approved it? In regulated industries, that record matters as much as the output.

The model is a component. The delivery system around it decides the result.

What actually shortens delivery

If coding is the smaller half, the gains come from applying AI to the larger half, carefully, with people accountable. In our experience and in the better research, five changes make the difference.

1. Put AI on requirements. Most rework starts with a misunderstood requirement. AI can draft user stories, data definitions and process maps from existing SOPs, forms and screens in days. The people who do the work then correct them. The draft is fast; the validation is human.
2. Generate tests from every requirement. When each requirement produces its own test cases, coverage rises and every requirement can be traced to the tests that prove it. Testing stops being a late phase and becomes part of building.
3. Produce documentation as a by-product. Technical documentation, user guides and traceability records can be drafted from the work as it happens. Engineers verify them. Nothing is reconstructed at the end.
4. Protect review capacity. Review is where AI-accelerated teams jam. Keep changes small, let automated checks and AI pre-review catch routine issues, and reserve senior engineers for architecture, security and judgement.
5. Measure estimate against actual. Given the perception gap, a team's sense that AI is helping is weak evidence. Hours estimated at scoping against hours actually logged is strong evidence. It is how we arrived at LabOperon's 5,300 against 10,000, and at 3,000 against 5,500 for the Pharma Now operating system.

What AI won't speed up

Honesty about limits is what makes the rest credible. AI shortens the work. It does not shorten the waiting.

Stakeholder approvals take as long as they always did. So do third-party integrations that depend on another organisation's timetable, decisions about migrating legacy data, user training and adoption, and regulatory or validation review in industries such as pharmaceuticals and financial services. A realistic plan accounts for all of these. A vendor who promises to halve your calendar time without asking about them is guessing.

What this means for your budget

If you commission software rather than build it, the research has three practical consequences.

First, be careful with any quote that simply claims AI savings. A vendor billing by the hour who is genuinely faster earns less for the same work, which is an awkward incentive. Ask how the saving reaches you: a lower fixed price, more scope for the same budget, or an earlier delivery date. Any of the three is reasonable. "Trust us" is not.

Second, budget for review and testing rather than assuming they shrink. The Faros data suggests they grow when AI output rises. A plan that protects them is a plan that will hold.

Third, if the software itself will include AI features (search over your documents, an assistant, automated reports), ask for the monthly running cost in writing before you sign. Token prices are falling, but total AI bills are rising across most enterprises because usage grows faster than prices fall. Knowing the number in advance is the difference between a planned cost and a surprise.

Five questions to ask whoever builds your next system

1. Where exactly do you use AI: only in coding, or also in requirements, testing and documentation?
2. Who reviews what AI produces, and how do you stop review becoming the bottleneck?
3. Can you show estimated against actual hours on a real project?
4. What happens to test coverage and documentation on your AI-assisted projects?
5. Which models do you use, where is our data processed, and what will any AI features cost us to run each month?

A clear, specific answer to all five is a good sign. "We use AI everywhere" followed by enthusiasm is not.

The bottom line

Does AI make software development faster? At the level of individual coding tasks, often yes. At the level of delivered projects, only when AI is applied across the whole lifecycle, when review capacity is protected, and when results are measured rather than felt. The model matters less than the method around it.

If you want to see what that looks like on your own backlog, we map one process in two weeks and give you a scope, an estimate and a monthly running cost, yours to keep either way.

Frequently asked questions

Does AI reduce software development cost?

It can, mainly by reducing hours across requirements, testing and documentation. Coding speed alone rarely changes total cost much, because review and rework absorb the gain.

Which AI model is best for software development?

There is no single answer, and rankings change monthly. Choose by task fit, data location, cost per completed task and governance, and expect to use more than one.

Is AI-generated code safe?

Not by default. Independent testing has found frequent security flaws in AI-generated code. It needs the same review, testing and security checks as any other code, arguably more.