In 2025, 68% of developers in Atlassian’s survey said AI saved them more than ten hours a week. In 2026, only about a quarter say so. Yet 87% say AI helps them ship faster. Both numbers hold, and together they tell the story of Atlassian’s new State of Developer Experience report: AI speeds up writing code, but the time it saves disappears into meetings, searching for information and checking what the AI produced. Other studies from the past months, from Google’s DORA team to METR and Stack Overflow, reach the same conclusion by different routes. For engineering leaders, the lesson is that the operating model around AI now matters more than the tools.
What the Atlassian report actually measures
Atlassian surveyed 1,155 developers and 405 engineering leaders in 2026, across company sizes, industries and countries. The answers describe what people experience, not telemetry such as deployment frequency or cycle time. The report itself warns that an association, for example between a clear AI strategy and less friction, is not proof of cause and effect.
It also helps to know who is talking. Atlassian sells Jira and Confluence, and in November 2025 it completed the acquisition of DX, a developer productivity platform. When the report recommends a “shared system of record”, it is also describing its own products. That does not make the numbers useless, but it is a good reason to read them next to other studies.
AI is now everywhere in engineering. 95% of developers and 96% of leaders say their organisation actively uses it, and only 2% of developers don’t use AI at all.
Where the time saved goes
Developers like what AI does for their own work: 87% ship faster and 80% deliver more without working longer hours. But only 28% report noticeably less friction than before AI. Half say the friction is about the same, just of a different kind.
The biggest time drains are the same as last year:
- finding information (51%)
- meetings (50%)
- context switching between tools (45%)
- technical debt (44%)
- lack of direction or unclear requirements (40%)
- silos and poor collaboration (31%)
New work comes on top. Almost half of developers spend four or more hours a week managing AI tools, 65% spend time fixing AI work that missed the original intent, and 29% call reviewing AI output a source of friction in itself. Atlassian connects the dots: when context is hard to find, meetings become the way to force alignment. And the faster code gets written, the faster fragmented context turns into a problem.
Telemetry tells the same story. Faros AI’s AI Productivity Paradox report followed more than 10,000 developers in 1,255 teams. Teams with high AI adoption merged 98% more pull requests, but review time rose 91% and pull requests grew 154% larger. At company level, Faros found no link with better DORA metrics or quality.
Review is the new bottleneck
If code is produced faster than a team can review it, the waiting moves to the review queue. LinearB’s 2026 benchmarks report, based on more than 8 million pull requests, finds that AI pull requests wait 4.6 times longer before someone picks them up. Once picked up they are reviewed faster, but only 32.7% of AI pull requests are accepted, against 84.4% of manual ones.
That caution is justified. In March 2026, research group METR asked four maintainers of scikit-learn, Sphinx and pytest to review 296 AI-written pull requests that had passed all of SWE-bench’s automated tests. They would not merge roughly half of them, because of poor style, code that breaks something else or a fix that doesn’t really solve the issue. Passing the tests is not the same as a good pull request.
Developers feel this too. In Sonar’s State of Code survey of more than 1,100 developers, published in January 2026, 96% don’t fully trust AI-generated code, yet only 48% always check it before committing. 38% find AI code harder to review than code from a colleague. And according to DX, which collects data from more than 500 organisations, the share of AI-written code rose from 34% to 52% between the first and second quarter of 2026. Over the same period code maintainability went up 3.8%, while developers’ confidence in the changes they push to production fell 6.1%.
Atlassian sums it up as a tension between speed and quality: 59% say AI-assisted output is better, but 73% say AI-driven speed can come at a cost to quality. AI improves the task in front of you, but also produces output without context that adds to testing and review.
Do developers feel faster than they are?
The best-known counterpoint comes from METR. In a randomised controlled trial from 2025, 16 experienced open-source developers worked on 246 real tasks, randomly assigned with or without AI. With AI they took 19% longer. Beforehand they expected to be 24% faster, and afterwards they still believed they had gained 20%.
A follow-up study in late 2025 pointed in a more favourable direction, but METR itself calls it very weak evidence. More and more developers refused to take part because they no longer wanted to work without AI, and those who did join held back some tasks. The researchers believe developers are now probably sped up, but cannot say by how much, and are redesigning their approach.
The takeaway for anyone trying to prove AI’s value: what people experience and what gets measured can be far apart. Atlassian’s numbers are experiences too.
Daily use, conditional trust
The 2026 Stack Overflow Developer Survey, with more than 30,000 respondents, shows how deep AI already runs. 73% of people who use AI coding assistants or agents use them daily, and a third of daily users work with AI four or more hours a day. Claude Code (66%) and GitHub Copilot (59%) are the most used agents, and open coding models that run offline, such as Recursive’s Flint, are widening the choice.
Trust stays conditional. 48% trust AI when the answer is easy to verify, and only 16% for most tasks that aren’t important decisions. Developers mostly use AI to write code in familiar areas (67%) and to debug (61%). Only 20% use it to deploy, operate or troubleshoot production systems.
A clear AI strategy makes the difference
The strongest positive signal in the Atlassian report is not about tools. Only 17% of developers and 23% of leaders say their organisation has a clearly communicated AI strategy across the whole software development lifecycle that is actually being implemented. Developers who see one report less friction far more often.
With a clear strategy, 41% report noticeably less friction, against 22% where the strategy is inconsistent or poorly communicated. The share saving more than ten hours a week is higher too, 37% against 22%. And half of those developers say their organisation has clear visibility into AI tool costs and manages them, against 11% where there is no formal strategy.
What such a strategy contains shows in what developers ask for: AI with persistent context across the codebase, team history and earlier decisions (65%), AI that completes multi-step work end to end (54%) and help to write plans clear enough for agents to execute reliably (48%). That context is what lasts when models change, as we argued in models are rented, context is owned.
Google’s DORA team got there by another route. Its report on AI-assisted software development, based on nearly 5,000 respondents, concludes that AI mostly amplifies what is already there: teams with good habits gain, and without that discipline technical debt, review work and instability grow. DORA’s AI Capabilities Model lists seven conditions, starting with a clearly communicated stance on AI. The others are healthy data, accessible internal knowledge, strong version control, working in small batches, a user-centric focus and a quality internal platform. The idea that the system around the model matters more than the model itself also runs through Google’s work on Harness². And DORA’s 2026 ROI report warns of a J-curve: productivity dips first, because of the learning curve and the extra review burden, before the gains arrive.
Measure AI usage and you get more AI usage
How do you show that AI pays off? Many organisations reach for whatever is easiest to count. 60% of developers say AI use is treated as a productivity signal in their organisation, and 41% sometimes use AI more than necessary because they feel expected to. Leaders see the risk: 81% agree that measuring AI use can create the wrong incentives, 59% worry about performative AI use, and only 42% have metrics that separate real gains from mere activity.
The industry already has a word for it, “tokenmaxxing”. In an r/sysadmin thread with more than 150 comments, someone asked how to inflate their AI usage because management tracked it and low users would be called in. Commenters mocked the policy and compared it to paying developers per line of code. In June, DORA published a piece on the trend: token leaderboards are a vanity metric, and the way to see AI’s impact is through existing delivery and quality metrics.
The gap is wide. 37% of leaders measure hours worked, while only 17% of developers think that is a good measure. The other way round, 41% of developers prefer the SPACE framework, which combines satisfaction, performance, activity, collaboration and flow, while only 20% of leaders use it. Atlassian proposes better questions: are teams shipping valuable changes with more confidence, are developers waiting less for context and approvals, and is quality improving without hidden review or rework?
Juniors are learning with less of a safety net
If engineering work shifts towards setting intent, validating output and guarding architecture, where do new developers learn that? 37% of leaders hired fewer junior developers in the past year, and 32% prioritised mid-level or senior talent. 51% are not confident that juniors are building real computer-science fundamentals rather than pattern-matching on AI. Only 11% are very confident.
At the same time, juniors get productive faster. In separate DX research, the median time to a new developer’s tenth pull request fell to 30 days in the second quarter of 2026, less than half the figure from early 2024. But they learn AI with less support. 37% use AI informally for most of their work, and only 8% see AI officially standardised in their organisation, against 26% of senior engineers. For companies that already struggle to find engineering talent, a thinner junior pipeline today could mean fewer senior engineers later.
What engineering leaders can do now
- Write down your AI stance and make it visible. Which tools, for which steps from planning to deployment, with which rules for data and review. DORA and Atlassian both see the biggest difference here.
- Invest in shared context. Documentation, decisions and team history that people and agents can find reduce the biggest time drain: finding information.
- Plan for review capacity. Keep AI pull requests small, ask for evidence such as test results and what wasn’t tested, and count review as real work.
- Measure outcomes, not tokens. Lead time, stability, quality and satisfaction, for example with DORA metrics or DX Core 4. AI usage is a diagnostic, not a goal.
- Protect the junior learning path. Mentoring, reviews that explain, and work that gradually carries more responsibility.
- Listen to your developers. 66% say leadership doesn’t understand their pain points, up from 44% in 2024. Without that picture, you write the wrong strategy.
Frequently asked questions
Does AI really make developers more productive?
For individual tasks it usually does: 87% of developers in the Atlassian report and more than 80% in the DORA report experience a productivity gain. Controlled studies such as METR’s show the gain can be smaller or less certain than people think, and at team level much of it is lost to review and friction.
Why does AI save less time than last year?
Atlassian points to three explanations: developers no longer count gains on individual tasks as extra, AI has not fixed organisational bottlenecks, and managing and checking AI output takes time of its own.
How many developers trust AI-generated code?
Few trust it fully. In Sonar’s survey 96% don’t fully trust AI code, and in the Stack Overflow survey 48% trust AI mainly when the answer is easy to verify.
How should you measure AI’s impact on an engineering team?
Through outcomes rather than usage: delivery speed, stability, quality, developer satisfaction and business impact. Frameworks such as DORA, SPACE and DX Core 4 help. Token and usage statistics only show whether tools are being used.
Typing faster was never the problem
This year’s studies disagree less than their headlines suggest. AI makes the step from idea to code cheap, and that makes everything else more expensive: knowing what to build, checking what was built and deciding whether it can go to production. Roll out AI as a faster typewriter and you get more code and the same waiting. Treat it as a change in how the whole team works, with shared context, review rules and honest metrics, and the gains reach the customer. As Taroon Mandhana, Atlassian’s CTO for AI and Teamwork, puts it in the report, the models will keep changing, and the context that holds a team together is what lasts.
