October 22, 2026

What Atlassian's 2026 DevEx Report Confirms (and Misses) About AI and Developer Productivity

Anita Zbieg PhD

CEO Network Perspective

AI adoption is widespread. Turning it into delivery gains is still unfinished work. Atlassian's State of Developer Experience Report 2026, based on a survey of 1,500+ software practitioners, finds that 95% of developers say their organization uses AI in engineering, but only 17% of developers say their company has a clear, actively implemented AI strategy across the SDLC.

The tension at its centre is one we know well. 87% of developers say AI helps them ship faster, yet only 28% report noticeably less friction in their day-to-day work than before AI.

Over the past few months we've published our own research on the same question: a 250-engineer study of AI-assisted delivery, interviews with engineering leaders, and collaboration and delivery data from the organizations we work with. Here we put those findings side by side: where Atlassian's survey confirms what we see, where our data adds detail, and what engineering leaders can do with both.

The biggest friction isn't code. It's coordination

Atlassian's top three sources of developer friction in 2026 have little to do with writing code: finding information (51%), meetings (50%) and context switching between tools (45%). Finding information has now led the list two years in a row.

Developer friction in 2026: finding information 51%, meetings 50%, context switching between tools 45%, technical debt 44%, lack of direction or unclear requirements 40%, and silos or lack of collaboration 31%. Five of the six displayed categories are classified as coordination-related.

Source: Atlassian's 2026 DevEx report. Grouping these friction categories as coordination-related is Network Perspective's interpretation; categories can overlap.

The report ties these together. When context is hard to find, teams fall back on meetings to force alignment, and faster implementation only makes the fragmentation louder.

Our collaboration data shows the same pattern one layer deeper. At a ~600-person European software vendor, some functional areas carried more than 30 hours of meetings per person per week. Mapping who met with whom pointed to a structural problem, not just meeting habits: too many teams had to align before anything shipped, and product managers sat at the busiest intersections.

The company rebuilt IT around four product-aligned Business Units. A year later, the same measurement showed about 5,300 fewer meeting hours a month across ~207 people. The largest unit went from 37 to 22 hours of meetings per person per week; another barely moved.

What we'd add to Atlassian's finding: meeting load can flag a problem, while the collaboration network helps locate it. A survey can rank the pain. Locating the dependency that causes it takes data on how work actually moves between teams.

AI saves time, then spends much of it again downstream

Both surveys report AI time savings alongside substantial work after code generation. Atlassian finds 87% of developers say AI helps them ship faster, yet 49% spend four or more hours a week managing AI tools and 65% spend time correcting AI work that missed the original intent.

Our 250-engineer study put hours on both sides of that ledger. Engineers reported saving about five hours a week with AI and spent about three reviewing, validating and reworking its output. Those reported hours imply estimated gross capacity worth ~14% of engineering time, but only ~6% remained as estimated net capacity: nearly 60% of the gain was absorbed downstream.

Atlassian also describes a speed-quality tension. 59% of developers say AI-assisted output is higher quality, while 73% say AI-driven speed can come at a cost to quality. Atlassian DX telemetry from 500+ companies sharpens it: between Q1 and Q2 2026, code maintainability rose 3.8% while change confidence fell 6.1%.

One possible explanation for that confidence drop is difficulty understanding generated code, rather than correctness alone. In our survey, engineers trusted code they understood and distrusted code they couldn't explain, even when it looked right. Trust was high for bounded, clearly specified work and fell with complex business logic, evolving requirements and large generated changes. That helps explain why review and rework can consume so much of the time saved.

Delivery telemetry reveals another structural effect. In merge-request data from large European engineering organisations, pull requests keep growing, and larger changes were strongly associated with longer lead times. In one, lead time fell in every size class while the mix drifted toward bigger changes; in our worked example, a 25% process improvement reaches the dashboard as 11%, and the missing 14 percentage points are what we call the drift tax.

A clear AI strategy helps, if it targets where your value leaks

Only 23% of leaders and 17% of developers in Atlassian's survey say their organisation has a clearly communicated, actively implemented AI strategy. Where developers do see one, the picture changes on every measure Atlassian tracked.

Reported outcomes by AI strategy, in order: noticeably less friction, saving 11+ hours weekly, clear AI-cost visibility. Clear and actively implemented: 41%, 37%, 50%. In progress: 24%, 22%, 16%. Inconsistent or poorly communicated: 22%, 22%, 15%. No formal strategy or not sure: 29%, 27%, 11%. Association, not causation.

Source: Atlassian's 2026 DevEx report. The strategy groups show associations, not evidence that strategy alone caused these outcomes.

Atlassian frames this as an association, not proof of cause, and that's the right reading. Still, the gap is large, especially on cost governance, where half of developers with a clear, actively implemented strategy report clear AI-cost visibility, versus about one in ten in the no-formal-strategy or not-sure group.

Our research suggests what a working strategy contains. The highest-performing AI teams we studied weren't using better models but better delivery practices: they brought AI in after decisions had been made, kept humans in the loop deliberately, and favoured smaller, reviewable changes. That is an operating model, not a tool rollout, which is exactly Atlassian's point.

The caveat comes from fifteen engineering leaders we asked where AI gains leak. Almost none said review; leaders named varied constraints, from product definition and requirements to QA, validation and demand. AI can shift the bottleneck to the next weakest step. A strategy borrowed from another company may therefore optimise the wrong constraint.

Atlassian's capability wish list points the same way. 65% of developers want AI with persistent context across the codebase, team history and prior decisions, and 48% want help making plans and specs clear enough for agents. Our respondents described the same boundary: AI works best once the decision is made and struggles when asked to resolve it.

Measuring AI usage rewards activity, not impact

Atlassian's measurement findings are the most uncomfortable in the report. 60% of developers say AI use is treated as a productivity signal in their organisation, and 64% of leaders believe greater AI usage correlates with better outcomes. Yet 81% of leaders also say measuring AI use can create the wrong incentives, and only 42% think they have metrics that separate real gains from activity.

Leaders' current productivity measures versus developers' preferred measures: hours worked 37% vs 17%; story points completed 36% vs 26%; code written or changed 35% vs 17%; deployment frequency 35% vs 19%; AI tool usage 26% vs 12%; SPACE framework 20% vs 41%; cannot or should not be measured 16% vs 33%. Different questions compare current use with preference.

Source: Atlassian's 2026 DevEx report. Leaders describe current measurement practices; developers describe preferred measures. Lower selection is not the same as rejection.

The split is sharpest on activity measures. Leaders are about twice as likely to use hours worked, code volume and AI tool usage as developers are to endorse them, while developers favour the SPACE framework and a third say productivity can't or shouldn't be measured at all.

We've documented three ways familiar metrics mislead once AI arrives. Story points re-anchor to the team's new speed, so a real gain appears for a sprint or two and then vanishes from the velocity chart. Lead time hides a mix shift toward bigger changes. And rewarding individual AI consumption may encourage people to talk to a model instead of each other, which risks thinning the team's communication network in ways conventional flow metrics can miss.

Atlassian's own summary adds that 41% of developers use AI more than necessary because they feel expected to. That is the incentive problem in one number. It also raises a collaboration risk: more model interaction need not mean better coordination between people.

Atlassian recommends anchoring on outcomes (its DX Core 4: speed, effectiveness, quality, business impact) and treating usage and cost as diagnostic signals. We agree, and would add one question to the scorecard: not how much AI engineers use, but how much of the value it generates survives the delivery system. We call that Agentic Experience, and track it through time spent in each delivery segment, review and rework, plus demand-side measures such as scope injection and committed-versus-completed work. Those measures matter because freed capacity can be absorbed before it ever reaches delivery.

Two magnifying glasses show a fast laptop user producing colored blocks and two people reviewing a block, with a backlog behind them and fewer blocks reaching an open box.

Judgment moves to the centre, and juniors need clearer guardrails

Atlassian finds engineering shifting toward judgment rather than being replaced by AI orchestration. In the full PDF report's role-shift table, half of developers say their role broadly feels the same, but 41% report more responsibility for validating the quality and safety of AI output, and 29% report more cross-functional coordination.

Junior developers are where this gets risky. 91% already use AI for coding and debugging, and Atlassian DX data shows the median time to a new hire's 10th pull request fell to 30 days in Q2 2026, less than half its Q1 2024 level. Yet only 8% of juniors say AI is officially standardised across their work, against 26% of senior engineers.

Our research shows why that combination matters. In two teams using the same AI, a mature team used it to generate test types it had been missing, split PRs smaller and shipped fewer defects; a less experienced team produced oversized PRs that often had to be rewritten from scratch. In these cases, AI amplified the team's existing practices.

The usual fix can create a new problem. Blanket senior-review requirements can protect quality, but risk routing review load through your scarcest people and making them the bottleneck. One leader we spoke to put the better fix upstream: if juniors are judged at review against standards nobody gave them during the work, the standards arrived too late.

In a separate seniority breakdown, Atlassian reports that juniors are more likely than seniors to say cross-functional coordination increased (62% vs. 51%). The report does not give enough detail on the response bases to compare these rates directly with its overall role-shift figure. That's the layer where we see AI gains leak most: not in the pipeline but in the handoffs between people, where one person generates quickly and another has to understand, review and reconcile the result.

Where we read it differently

Atlassian's report combines survey responses from 1,500+ practitioners with DX telemetry. Its survey findings capture friction, trust and incentives that telemetry can miss, but those perceptions still need to be considered alongside measured delivery outcomes.

The clearest evidence comes from METR's randomized controlled trial: experienced open-source developers believed AI had made them 20% faster when, measured, they were 19% slower. METR's 2026 follow-up suggests gains may have increased since early-2025, but says selection effects prevent a reliable estimate of the current productivity effect. It also reiterates that self-reported speedups can be quite unreliable.

Telemetry tells the same story at scale. Faros AI analyzed 10,000 developers across 1,255 teams, comparing each team's lowest-adoption quarters with its highest-adoption quarters. Merged pull requests rose 98% and review time rose 91%, while company-level metrics stayed flat. Google's DORA 2024 report found every 25% increase in AI adoption associated with an estimated 1.5% drop in delivery throughput and 7.2% drop in stability.

So 87% of developers feeling faster need not contradict flat delivery outcomes. Local coding gains can coexist with more work in review, testing, release and coordination. That is where any gain has to survive.

That's why our main addition to Atlassian's "operationalise AI" message is about sequence: diagnose before you prescribe. Bain estimates that writing and testing code take only 25–35% of the time from idea to launch, so faster coding does little while other steps stay bottlenecked.

And the bottleneck moves. In a separate dataset focused on already-high adoption, Faros's latest data shows more work reaching production as AI use intensifies, but time in QA is up 300.6% and monthly incidents are up 125.4%. A clearly communicated strategy is associated with less friction, but its content should come from where your own delivery system is constrained, and that differs from one organisation, and one team, to the next.

What engineering leaders can do this quarter

Pair perception with behaviour. Run a DevEx survey alongside collaboration and delivery data, so "AI makes me faster" can be checked against where time actually goes.
Report net, not gross. Track hours saved against hours spent on review, validation and rework, and report what survives to delivery.
Find your leak before fixing it. Check review and rework, specification clarity, QA, handoffs between teams and scope injection, then fix the step that is actually constrained.
Make reviewability a standard. Treat small changes as a team contract, load conventions before coding starts, and put an automated self-review pass in front of human reviewers.
Segment the average. Break AI impact down by team maturity and size; one company-wide number can hide teams quietly accumulating debt.
Stop rewarding usage. Retire AI-usage targets as performance signals, and watch whether collaboration between people thins as AI use rises.
Fix structure, not just calendars. If meetings top your friction list, map which dependencies force them before launching another meeting-hygiene campaign.

The bottom line

Atlassian's survey, our research and independent studies point the same way. Developers report faster individual work, but those gains do not automatically carry through to delivery. In our own study, reported hours implied estimated gross capacity worth ~14% of engineering time, with only ~6% remaining after review and rework.

That gap isn't a verdict on AI. It's the operating-model work still ahead: clearer specifications, reviewable changes, healthier handoffs between teams, and metrics that track outcomes rather than usage. These are levers engineering leaders can act on. Start with one question: how much of the value AI generates actually survives your delivery system?