Software projects run late because coding was never the bottleneck. Developers spend roughly 16% of their week writing code. The other 84% goes to finding information, waiting on decisions, and switching between tools. AI accelerates the 16%. The delay lives in the 84%, and almost nobody has pointed a tool at it.
Sixty-eight percent of developers say AI saves them more than ten hours a week.
Fifty percent say they lose more than ten hours a week to organisational friction.
Same survey. Same year. Same 3,500 developers across six countries. Atlassian published both numbers in its 2025 State of Developer Experience report and drew the only conclusion available: "we're right back where we started."
A full working day, handed to your engineers by a machine, and quietly repossessed by your own company before Friday.
If you signed off on an AI tooling budget last year and your release dates haven't moved since, this is why. Not because the tools underdelivered. They delivered exactly what they advertised. They delivered it into a system that was never rate-limited by typing speed.
Why doesn't AI make software projects faster?
Ask a CFO what a software engineer does all day and the answer is: writes code. Ask a VP of Engineering and you'll get something more sophisticated with identical arithmetic underneath — capacity is counted in developer-days, and developer-days are assumed to be days of building.
They aren't. Atlassian's 2025 report puts coding at 16% of a developer's working week, a figure it takes from an IDC Survey Spotlight published in February 2025. Six and a half hours out of forty. The other thirty-three and a half go somewhere else entirely: hunting for the API doc that was accurate in March, waiting on someone three timezones away to confirm whether a field is nullable, sitting in the standup that exists because last week's standup resolved nothing.
Now drop an AI coding assistant into that week. It's a good tool. Assume — with no evidence, purely to be generous — that it makes the coding portion thirty percent faster.
Thirty percent of 16% is under 5% of the week. Two hours.
You didn't buy a faster project. You bought Tuesday afternoon.
None of this surprised Atlassian. Their head of DevOps evangelism had made the argument a year earlier, and flagged at the time that it was a controversial thing to say: a coding assistant can make a developer's day feel better without making the organisation ship any faster. Coding was never the friction. Sharpening the one tool that wasn't dull doesn't do anything for the thing that is. Twelve months and 3,500 respondents later, the 2025 numbers closed the argument in his favour.
The developer productivity paradox is what happens when individual engineers get measurably faster and the organisation shipping the software does not. It isn't a mystery. It's a ratio.
| Share of the developer's week | What an AI coding tool does to it | |
|---|---|---|
| Writing code | 16% | Accelerates it, substantially |
| Everything else — finding information, adapting to new technology, context-switching, cross-team coordination, waiting on decisions | 84% | Essentially nothing |
AI is aimed at 16% of the problem. Sources: IDC Survey Spotlight (Feb 2025); Atlassian State of DevEx 2025.
And while you were buying that Tuesday afternoon, the bottleneck moved. Tech debt — the thing with a line item on every engineering roadmap ever written — dropped out of Atlassian's top five friction sources in 2025. Cross-team collaboration climbed. Most organisations are still funding last year's bottleneck with this year's budget, then measuring the result in story points.
There is a quieter finding in the same report that should bother you more than any of the headline numbers.
Atlassian asked developers what they actually do with the time AI hands back. The answer: improve code quality, build new features, write documentation.
Read that list again. Almost all of it sits inside the 16%.
The dividend from the coding portion is being reinvested, near enough entirely, into the coding portion. Not because engineers are short-sighted. Because it is the only part of the week they are permitted to touch. Documentation is the one item on that list that reaches into the 84% — and it is the first thing cut when the sprint tightens.
So you gave your team ten hours a week, and they spent it on the one sixth of the job that was already working. They were right to. Nobody gave them permission to spend it anywhere else.
Where does the time actually go?
Before the list, one number that matters more than the fifty percent: ninety percent of developers lose at least six hours a week to this. Six hours is most of a working day. So this is not a tail of badly run outliers you can comfortably assume you aren't in. It's the distribution. If your company is normal, it is in this data.
Atlassian's top three, in order: finding information. Adapting to new technology. Context-switching between tools.
Read them again. Not one is a coding problem. Every one is a knowledge-location problem. The information exists. Someone in your company has it. It is almost certainly written down somewhere. Your developer just cannot find it inside the nineteen minutes they have before the next call.
Here is a Tuesday.
A developer needs to know whether the payment webhook retries on a 500. The answer exists. It is in a Slack thread from fourteen months ago, in a channel that got archived during a reorg, written by someone who left in April. So the developer does the rational thing: asks in the team channel, gets nothing for four hours, and starts something else while waiting.
That task didn't cost four hours. It cost four hours plus a context switch, and the switch cost more than the question did. Multiply across every developer, every day, for a quarter. That is your delivery date.
Now notice which friction climbed Atlassian's list in the same year tech debt fell off it: collaboration with other teams.
That one matters because it is the only category on the list a developer cannot touch. An engineer can refactor a bad module on their own initiative on a quiet Friday. They cannot make the platform team prioritise the API change. They cannot pull the compliance sign-off forward. They cannot force a decision out of a meeting that has been rescheduled three times. The friction growing fastest is precisely the friction that sits above their pay grade — which means it is sitting at yours.
How do you actually fix a late project?
None of this requires hiring anyone. It requires you to look at a part of the week you have never measured.
-
Measure the wait, not the work. You already track story points, velocity, cycle time. All of them measure the 16%. Start logging one number instead: hours between a developer being blocked and being unblocked. You will not like it. That's the point — you cannot argue with a number you collected yourself.
-
Give every blocking question a named human and a clock. Not a channel. Not a committee. A person, with an agreed maximum time to respond. Most four-hour waits are not waits for a decision. They are waits for someone to notice a decision was needed.
-
Write the answer where the next person will trip over it. The webhook answer will be needed again in November. If it lives in a Slack reply, it is gone. Put it next to the code — a decision log in the repo, a comment on the endpoint. The rule is not "document everything." It's "when a question costs four hours, its answer gets a permanent address."
-
Point AI at the 84%. You already own the tools. Turn them on the part of the week that's actually bleeding — searching internal docs, summarising the thread, drafting the spec nobody has time to write. AI agents aimed at internal workflows are unglamorous next to a coding assistant, and they touch five times more of the week. Atlassian's own framing: AI improves developer experience when it's pointed at real friction points, not at the one task that was never a friction point.
-
Ask your developers. Actually ask. Atlassian's step one, and it's step one because it's free. The people losing the ten hours can tell you exactly where the ten hours go. Nobody has asked them.
The uncomfortable part
Sixty-three percent of developers now say their leaders don't understand their pain points. Last year it was 44%.
Nineteen points in twelve months. The same twelve months in which AI adoption went nearly universal and reported time savings jumped sharply.
That is not a coincidence, and Atlassian's own reading is blunt about it: leaders are pocketing the AI savings and leaving the friction exactly where it was. The engineer gets the tool. Gets the gain. Watches it drain into the same queue it always drained into. Then gets asked why the date moved.
On the report's own numbers, a 500-developer organisation is losing something like $7.9M a year to this — a modelled figure rather than a measured one, but the model is not generous.
Tooling gets bought because tooling is purchasable. You can approve it on a Tuesday and announce it on a Wednesday. Fixing who owns a decision, or killing the four-hour wait on a nullable field, means changing how your company works. No vendor sells that. No invoice arrives. No one writes a press release about it.
So the money goes where the invoice can go.
Start with the question, not the tool
Your engineers already know where the time goes. They have known for years. The survey didn't uncover anything they couldn't have told you over a coffee — and 63% of them say their leaders don't understand it anyway.
So ask. Not about the roadmap. About the last thing that made them sit and wait.
Fix that one thing. Then watch what it does to the date.
Frequently asked questions
Why are software projects still late if AI writes the code?
Because writing code is only 16% of a developer's week. The other 84% goes to finding information, waiting on decisions, and switching between tools. AI accelerates the coding portion, which was never the constraint. The delay sits in the 84%, untouched.
Does AI actually improve developer productivity?
Yes, individually. In Atlassian's 2025 survey of 3,500 developers, 99% reported some time saving and 68% reported saving over 10 hours a week. But 50% also lose over 10 hours a week to organisational friction, so the gain rarely reaches the delivery date.
What is the biggest cause of software project delays in 2026?
Organisational friction, not engineering capacity. Atlassian's 2025 data ranks the top drains as finding information, adapting to new technology, and context-switching between tools. Notably, technical debt dropped out of the top five — the bottleneck moved, while most budgets did not.
How much does developer inefficiency cost a company?
Atlassian's 2025 report models a 500-developer organisation losing roughly $7.9M annually to organisational inefficiency, based on developers losing about 10 hours each per week. It's a modelled estimate, not a measured figure — but the assumptions behind it are conservative.
