Atlassian just published The Agentic Pivot, a survey of more than 1,100 engineers and engineering leaders conducted by Prolific in Q2 2026. It is one of the clearest snapshots yet of where engineering organizations actually stand with AI, and it confirms something we hear from engineering leaders every week: getting teams to use AI was the easy part.
The widest gap in the report
Engineering leaders who say they need a governed system of record for AI-assisted work, versus those who have built one.
The harder part is everything that comes after. Turning individual experimentation into an operating standard. Moving review, testing, and monitoring at the same speed as generation. Knowing, with evidence rather than intuition, whether the investment is paying off.
Below, we walk through the report’s findings section by section, with the data laid out so you can compare it against your own organization. Then we get to the part we care most about: what this means for how engineering leaders should measure AI over the next year.
Atlassian’s headline: 88% of leaders say they need a governed system of record for AI-assisted work, and only 19% have built one. Around that gap, the report identifies five findings that define the pivot.
94% of engineering leaders say their organization uses AI somewhere. That number is so high it has stopped being informative. It counts everything from IDE autocomplete to browser chatbots to production-integrated agents. The more useful question is how teams describe that use.
| Mode | Share of leaders |
|---|---|
| AI supports individual tasks like coding, debugging, and documentation | |
| AI supports team collaboration and knowledge sharing | |
| Agentic workflows that run with limited human intervention |
More than a third of organizations already run agentic workflows. That is a big number, and it is the one Atlassian calls the more meaningful marker of progress. But the next table is the one that should shape your planning.
| Integration level | Share of leaders |
|---|---|
| Experimental and limited (informal, few areas of the SDLC) | |
| Experimental but extensive (informal, many or most areas) | |
| Formal but limited (official standard, few areas) | |
| Formal and extensive (official standard, many or most areas) |
Two thirds of organizations are still operating informally. The single largest group, 39%, uses AI extensively but without any official standard. That is the most exposed position of all: high usage, with no shared rules for what happens when a tool fails, a model changes, the team turns over, or an auditor asks how a decision was made.
Atlassian makes a point we think is exactly right. The difference between an experiment and a standard is not measured in usage. It is measured in what happens downstream when something goes wrong. It is also why license coverage is the widest and least informative number in most organizations, a point we unpack in our guide to the best AI adoption benchmarks for large engineering teams.
The report’s central argument is that AI did not simply speed up the software development lifecycle. It reshaped it. Implementation, the phase engineering has spent most of its history optimizing, is compressing. Everything around it is expanding.
Code review is where the pressure shows first. Around three quarters of leaders say AI has accelerated code generation, yet nearly 8 in 10 teams still review AI-generated code through the same PR process they used a decade ago. That process was designed for a different volume, a different velocity, and a fundamentally different kind of author.
When generation speeds up and review doesn’t, the throughput gain doesn’t compound. It queues. If you rolled out AI coding tools and watched end-to-end cycle time stay stubbornly flat, this is the most likely explanation. The work got faster at one gate and piled up at the next.
The report frames the gap between AI output and AI trust as the defining constraint of this phase. Generation is up across every dimension measured. Willingness to let that code move through the SDLC without a human check has barely moved.
| Trust level | Leaders | ICs |
|---|---|---|
| Zero trust (mandatory line-by-line review) | ||
| Guarded trust (non-critical code gets minimal review; core logic reviewed) | ||
| High trust (AI output trusted by default) | ||
| Full autonomy (AI ships to production, no manual gate) |
Guarded trust dominates: AI writes, humans check. That is a sensible posture today. It is also, as the report notes, unsustainable as volume grows. And there is early evidence it is already costing something. Atlassian’s DX research tracked two signals between Q1 and Q2 2026:
Developers understand the code better, and trust what they are shipping less. That divergence is worth watching closely in your own data. It is the kind of signal that never shows up in an adoption dashboard.
The first reason trust isn’t scaling is that governance around AI-generated work has barely changed.
| Approach | Leaders | ICs |
|---|---|---|
| Traditional peer review (unmodified PR process) | ||
| Automated guardrails (AI scanners, linters, sandboxes) | ||
| Shift-left governance (prompt libraries, spec-first, AI templates) | ||
| Decentralized or ad hoc (no formal guardrails) |
Notice the gap between leaders and ICs on automated guardrails: 35% versus 20%. Leaders believe more guardrails are in place than the engineers doing the work experience. That kind of perception gap is common, and it is exactly why self-reported data needs to be checked against what the delivery system actually records. We cover how to set that up in how to measure AI adoption across large engineering organizations.
About one in five teams has no formal guardrails at all. For those teams, the quality bar sits entirely with individual developers, and the burden of catching AI-specific failures shifts all the way to production.
The second reason is context. When AI writes a function, it has the local code. What it lacks is the organizational context a senior engineer carries automatically: what shipped last quarter, what broke in the last major incident, what the security team said never to do again. Acceptance criteria live in tickets. Standards live in wikis. Architectural decisions live in Slack threads and people’s heads. An AI reviewer without that context can check syntax and code quality, and not much more.
Missing governance and missing context produce a specific downstream cost. The reasoning behind AI-assisted decisions gets lost. When you ask an AI to explain a past decision, it does not retrieve a record. It produces a plausible account of what its process might have been.
| Confidence | Leaders | ICs |
|---|---|---|
| Very confident | ||
| Somewhat confident | ||
| Not very confident | ||
| Not confident at all |
The people closest to AI output are the least confident it can be explained later. Only 15% of ICs are very confident. The report reads this well: the problem isn’t fear, it’s uncertainty. Most engineers can probably reconstruct the reasoning. They just wouldn’t stake anything on it.
Review isn’t just gatekeeping anymore. It is the moment where reasoning is either captured or lost.
For decades, software delivery ran as a sequence of roles owning phases. PMs wrote requirements, engineers implemented, DevOps deployed, QA verified. AI is dissolving those walls. Designers ship working prototypes. PMs write acceptance criteria that agents consume directly. Engineers do more product thinking.
When asked how AI has changed the scope of a typical engineer’s role, leaders split three ways: 44% say it is unchanged, 33% say it is broader and more generalist, and 23% say it is narrower and more specialized. Atlassian’s interpretation is that the role hasn’t changed titles, but it has changed weight. That matches what we argued in AI didn’t kill engineering jobs. It raised the bar.
| Skill | Leaders | ICs |
|---|---|---|
| Effective and secure use of AI and automation in the workflow | ||
| Deep technical excellence (core stack, system design, secure coding, testing) | ||
| Product thinking and customer-centric decision making | ||
| Ownership mindset and continuous improvement | ||
| Cross-team collaboration and clear technical communication |
Leaders put AI fluency first. Engineers put deep technical excellence first. Leaders are saying get good at AI; engineers are saying make sure the AI is good. Both are right, and a mature measurement practice has to account for both: how well teams use AI, and how good the resulting work actually is.
As implementation gets cheaper, the judgment around it gets more expensive. Leaders still rely more on humans than AI for security and compliance (80%), architecture and system design (68%), and product scope and requirements (62%). These aren’t areas where leaders refuse to use AI. They are areas where decision quality matters more than execution speed.
70% of leaders and 67% of ICs believe AI has shortened the time it takes junior engineers to contribute meaningfully. Atlassian’s DX data supports this: median time to a new engineer’s 10th PR dropped to 30 days in Q2 2026, less than half of what it was in Q1 2024. A small minority, around 5%, say AI has slowed juniors down, likely where new engineers learn to generate code without learning to understand it. That is another case where speed alone would give you the wrong answer.
Much of the public conversation frames AI as a way to reduce engineering headcount. The leaders in this survey describe something very different.
| Choice | Leaders | ICs |
|---|---|---|
| Invest more in quality and testing | ||
| Take on more projects | ||
| Prioritize reducing tech debt | ||
| Expand into new product areas | ||
| Reduce dependency on contractors or backfill hiring |
Quality and testing wins with both groups. Cutting capacity comes last with both groups. And this isn’t just a hypothetical. When leaders describe where AI-saved time actually goes today, the pattern holds:
| Use of saved time | Leaders |
|---|---|
| Additional research and discovery | |
| Additional code quality and security checks | |
| Up-leveling engineering skills | |
| Improving work-life balance | |
| Addressing tech debt | |
| Contributing to the team knowledge base | |
| Contributing to areas outside software development |
Atlassian’s DX research adds one more data point: the innovation ratio, meaning the share of engineering effort spent on new features versus maintenance and toil, has stayed flat for 12 months. Meanwhile, 87% of leaders expect AI to increase output capacity over the next year.
Put those together and the picture is clear. AI gains are real. They are just flowing into research, quality, security, and skills rather than into more features shipped.
This is the finding we would underline twice. Atlassian points out that internal engineering gains such as faster cycles, fewer defects, and deeper test coverage may not show up right away as more features or more revenue. Organizations that measure AI purely through output velocity or cost reduction, the report warns, may misread the signal entirely.
We agree, and we’d go further. If your AI dashboard is a seat count, a license utilization chart, or a lines-of-code-generated number, you are measuring adoption, not impact. And adoption, as this report makes very clear, is the part everyone has already figured out.
There is also a methodological point worth making. The report is candid that all of its data is self-reported and reflects perception rather than measured behavior. That is appropriate for a survey, and perception genuinely matters. But it is exactly the gap engineering leaders face inside their own organizations. Your board, your CFO, and your auditors will eventually ask what AI actually changed. “Our engineers feel faster” won’t be enough. If you are building that answer now, start with our playbook for measuring AI adoption, impact, and ROI in engineering, which includes a 90-day plan to a board-ready ROI story.
| SDLC stage | What the survey found | What to measure in your own data |
|---|---|---|
| Planning | 82% of leaders say AI accelerates research; 64% spend saved time on discovery | Time from spec to first commit, share of work with clear acceptance criteria, rework traced back to unclear intent |
| Implementation | The most compressed phase; about three quarters report faster code generation | AI-assisted share of merged code, coding time per PR, AI tool usage by team and by tool |
| Testing and quality | 65% would invest extra capacity in quality first; 35% use AI-specific guardrails | Test coverage trends, defect escape rate, change failure rate for AI-assisted versus human-authored changes |
| Review | Nearly 8 in 10 teams use an unmodified PR process; only 15% of ICs are very confident they can reconstruct AI reasoning | Review time, review depth, pickup time, PR size, and rework on AI-assisted PRs |
| Ship and monitor | More code reaching production, observed with the same tools as before AI | Deployment frequency, time to restore, and incidents linked to AI-assisted changes |
Atlassian proposes three moves: make intent and context explicit before code is generated, govern and orchestrate the planned and unplanned loops that agents now work inside, and make agent work traceable and observable from prompt through production. We think those are the right priorities. Here is how we’d make each one measurable.
If generation is up and review is flat, your PR queue is the constraint. Track review time, review depth, and rework on AI-assisted changes separately from human-authored ones. Averages that blend the two will hide the problem.
If leaders are reinvesting the AI dividend into quality, then quality is where ROI shows up first. Change failure rate, defect escape, and rework are the leading indicators. Deployment count is a lagging one. Our breakdown of how to measure AI ROI on your engineering team walks through the before-and-after comparison.
Traceability from prompt to PR to production is what turns guarded trust into earned trust. It is also what lets you answer “why did we ship this?” six months from now, when the engineer who prompted it has moved teams.
Surveys tell you how your teams feel. Engineering data tells you what happened. You need both, and you especially need to know when they disagree, as they do in this report on guardrails and on reasoning confidence.
Only 6% of organizations have formalized AI across most of the SDLC, which means most have pockets of mature practice next to pockets of pure experimentation. Find your best-performing teams, understand what they do differently, and use that as your internal standard.
The organizations that pull ahead over the next year won’t be the ones with the most AI usage. Everyone has usage. They’ll be the ones that can see, govern, and prove what AI is doing across the whole delivery system, from spec to production.
Experimental adoption was the simple part. The competitive advantage now comes from the system built around it, and you can’t build a system you can’t measure.
Waydev measures AI adoption, impact, and ROI across engineering organizations, so you can move from how your teams feel about AI to what the data shows.
Book a demoSource: Atlassian, The Agentic Pivot (2026). Research conducted by Prolific on behalf of Atlassian in Q2 2026, drawing on two surveys: 364 engineering leaders (engineering managers, heads and directors of engineering, VPs, CTOs, and founders) and 750 individual contributors. Organizations ranged from under ten to over five thousand employees; 55% of leader respondents were in Europe and 41% in North America. All data is self-reported. Some questions allowed multiple selections, so totals for those items exceed 100%. Where the report gives slightly different figures for the same metric in different sections, this post uses the figure that appears most consistently.
Ready to unlock your SDLC productivity?
