
Avani Prabhakar, Atlassian's Chief People and AI Enablement Officer, published three lessons on November 10 from rebuilding the product development lifecycle for nearly 10,000 R&D employees. This is a Kill List entry, and the thing to kill is the number the post opens with.
The short version
- From Atlassian's 2026 State of Developer Experience research, as Prabhakar reports it: in 2025, 68% of developers said AI saved them 10 or more hours a week; this year 26% do, and 49% spend four or more hours a week managing AI.
- Her read is that the bottleneck moved to deciding what's worth building.
- Her three lessons then count what shipped: agents prepare fixes for 52% of vulnerabilities, about 50 engineering days a week; two Confluence features in 2 and 4 developer weeks against estimates of 30 and 40; more than 50 PMs and designers shipping over 100 engineering-approved production changes in three months. Kill hours saved as the AI number.
- It is a self-report, it fell by two thirds in a year, and the same survey shows where the hours went. The column the post does not have is landed, with the behavior that moved for a customer.
- Of 39 agents I appointed, 13 produced output nothing outside the fleet read, which I only knew because I counted. Put the column before Prabhakar's tasks, skills, roles sequence, and the 100 changes will carry a number next to them that is not 100.
What Atlassian reports
The post is a good one and the numbers in it are real work. Three lessons, each with a count.
Learning 1, "Aim human attention where it changes the outcome." An automated pipeline identifies vulnerabilities, proposes fixes, and runs tests before an engineer gets involved, so the engineer starts from a proposed solution and decides whether it is safe to ship. "Agents now prepare fixes for 52% of vulnerabilities," saving roughly 50 engineering days a week.
Learning 2, "Context should travel with the work and compound." Spec-driven development: teams use AI to define what to build and how, capture the decisions in shared specifications that people review and refine, and "those same specifications become Jira tasks that agents execute and update." In a Confluence pilot, "engineers shipped two production features in 2 and 4 developer weeks," against historical estimates of 30 and 40.
Learning 3, "Widen contribution, protect craft accountability and ambition." In an internal initiative, "more than 50 PMs and designers shipped over 100 engineering-approved production changes" in three months, with engineers scoping the changes, reviewing the code, and upholding standards. Her sequence for changing roles: "tasks first, skills second, roles third."
And the frame around all three, from the same research: "In 2025, 68% of developers said AI saved them 10+ hours a week." This year, just 26% do. Her conclusion is that as agents generate code, designs, and prototypes in minutes, "the bottleneck moves to deciding what's worth building," so leaders should redesign the handoffs between product, design, and engineering rather than add AI to individual jobs.
68% to 26%
Kill hours saved
Start with the 68% and the 26%. That number was a self-report about time. Developers were asked how much AI saved them, and in a year the share saying ten or more hours fell by about two thirds, while 49% said they now spend four or more hours a week managing AI.
The drop is being read as a signal about where the bottleneck went. I read it as a signal about the question. Hours saved was always the wrong unit, because a developer cannot see their own saved hours once the work changes shape. In 2025 the agent wrote a function and the hour it would have taken was visible. In 2026 the agent writes the function, opens the PR, and the developer spends the hour reviewing, correcting, and re-prompting, which the same survey counts separately as managing AI. The hours did not get saved or unsaved. They moved, and the question kept asking about the place they left.
Jakob Nielsen made the general version of this point the next day, in a piece on open and closed questions in user research: a self-report is not behavior, and when the two disagree, the observed data should win. Atlassian has the observed data. Its three lessons are made of it. What they count is the thing to look at closely.
What the three lessons count
Fixes prepared for 52% of vulnerabilities. Two features in 2 and 4 weeks against 30 and 40. One hundred production changes from 50 people who had never shipped one.
Every one of those is a count of something built or shipped. That is a better number than hours saved, and Atlassian deserves credit for publishing counts instead of sentiment. But the post says the bottleneck moved to deciding what to build, and then measures three things after the decision and nothing after the ship. Not one of the three has the column that would tell you whether the decision was right: what moved for a customer once the fix, the feature, or the change was live.
I argued the same thing about the same company last week in Atlassian's Agents Write 50% More in Jira. Count What the Humans Closed.: the shareholder letter counts what agents create and never the pair, created and closed. The PDLC post has the same shape one level up. It counts shipped and never landed.
The column
I have been on the wrong side of this with my own fleet. By April I had appointed 39 scheduled agents. When I audited them, 13 produced output that nothing outside the fleet read. Appointed was 39. Read by a person was 26. I only knew the second number because I counted, and the dashboard that showed 39 had looked like progress for months.
So the replacement for hours saved is two columns next to every shipped item, the ones I asked Reddit to add to its 700-prototype dashboard in Reddit Has 700 Prototypes on a Dashboard. The Column It Needs Is Shipped.: shipped, with the reviewer's name, and landed, with the behavior that changed for a customer. For the 100 changes, how many are in a flow a customer now completes differently? For the two Confluence features, which metric moved in the weeks after the 2 and the 4? For the 52% of fixes, how many shipped, and how many were reverted?
Prabhakar's sequence for changing roles is tasks first, skills second, roles third, and it is the right order for the people. I would put one thing before tasks: the column. Once shipped and landed are on the dashboard, widening contribution is safe, because the 100 changes will carry a second number next to them that is not 100, and that number is the one a CPO can run the organization on. The Product Leadership thesis is that the org chart was calibrated to a build cost that collapsed and leadership work now is deciding which coordination roles stop being necessary. You cannot make that call from hours saved, and you cannot make it from shipped. You can make it from landed.
The 2026 CPO Insights Report, which I read in Twelve Builders, Twelve Products, Zero Landings, found that CPOs' number one internal challenge is now speed to market and the bottleneck moved from building to launching. Atlassian's three lessons are the building half, done well. The bottleneck did not move to deciding. It moved to landing. Count there.
This week
Take the last ten things your AI-assisted process shipped. Next to each, write the reviewer's name and one behavior that changed for a customer, or the word none. The share that reads none is your version of 13 of 39, and it is a better number to bring to the next review than hours saved.
Related answer: Should hours saved be the AI adoption metric?
Sources: Avani Prabhakar, "3 lessons from rebuilding Atlassian's product development lifecycle for people and agents," Inside Atlassian, November 10, 2026, read in full; the 68%, 26%, 49%, 10,000, 52%, 50 days, 2 and 4 weeks against 30 and 40, 50 people, and 100 changes are Atlassian's as she reports them, and the 2026 State of Developer Experience report and the AI PDLC Playbook were not opened. Jakob Nielsen, "Closed vs. Open Questions in User Research: AI Makes Free-Form Answers Cheap to Count," November 11, 2026, read in full, for the point about self-reports. The 39 and the 13 are my own, from the posts linked above.
Frequently asked
What does Atlassian's AI PDLC post say?+
Avani Prabhakar, Atlassian's Chief People and AI Enablement Officer, wrote on November 10, 2026 that Atlassian is redesigning its product development lifecycle for nearly 10,000 R&D employees around three lessons: aim human attention where it changes the outcome, let context travel with the work and compound, and widen contribution while protecting craft accountability. Her framing is that with agents generating code, designs, and prototypes in minutes, the bottleneck moves to deciding what's worth building.
What is the 68% to 26% number?+
From Atlassian's 2026 State of Developer Experience research, as Prabhakar reports it: in 2025, 68% of developers said AI saved them 10 or more hours a week; in 2026, 26% do, and 49% spend four or more hours a week managing AI. It is a self-reported figure, and it fell by about two thirds in a year.
Why kill hours saved as the AI number?+
Because it is a self-report about time, and the same survey shows where the time went: into managing the agent. The drop says developers stopped being sure how to answer the question, not that the tools stopped working. Jakob Nielsen's general point the next day applies: self-reports are not behavior, and observed data should win when they disagree.
What do Atlassian's three lessons actually count?+
Agents prepare fixes for 52% of vulnerabilities, saving roughly 50 engineering days a week. In a Confluence pilot, two production features shipped in 2 and 4 developer weeks against historical estimates of 30 and 40. In an internal initiative, more than 50 PMs and designers shipped over 100 engineering-approved production changes in three months. All three count what was built or shipped. None counts what happened after.
What is the landed column?+
Two columns next to every shipped item: shipped, with the reviewer's name, and landed, with the behavior that changed for a customer. Of 39 agents I appointed, 13 produced output nothing outside the fleet read; appointed was 39 and read by a person was 26, which I only knew because I counted. The 100 changes need the same second number.
Where does the column go in Prabhakar's sequence?+
Before it. Her sequence for role change is tasks first, skills second, roles third. The column comes before tasks, because once shipped and landed are on the dashboard, widening contribution produces a number next to the 100 that is not 100, and that number is the one the CPO can run the organization on.


Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn