AI is changing software development at a remarkable pace. But after listening to Atlassian’s State of AI SDLC series, I came away thinking the most important story is not how much faster we can write code. It is what happens to the rest of the organization when we do.
The series brought together people approaching the shift from very different angles, including Atlassian co-founder and CEO Mike Cannon-Brookes, Vercel CEO Guillermo Rauch, Atlassian Chief Product and AI Officer Tamar Yehoshua, DX Deputy CTO Justin Reock, Dropbox engineering leader Uma Namasivayam, and leaders from companies including Honeycomb, 1Password, and Lovable. They talked about coding agents, AI adoption, developer productivity, product management, context, governance, and what happens when agents become active participants in the software development lifecycle.
There was plenty of evidence that AI is already having a real effect. Adoption among developers is approaching universal levels in some datasets. Engineers report saving hours each week. At Dropbox, AI-authored code represents a significant portion of what gets merged. Across the industry, more code is being produced and development work is moving faster.
The more interesting pattern, though, was the gap between those individual gains and what happens across the organization as a whole. Making code faster does not necessarily make the organization faster. In many cases, it simply moves the bottleneck.
We accelerated one part of a much larger system
For years, writing code was one of the expensive parts of software development. It required specialized skills, significant time, and a lot of human effort. AI is changing that quickly, but writing code is still only one part of getting an idea into the hands of a customer.
Someone has to decide what should be built. Requirements have to be understood. Decisions and context need to reach the people, and increasingly the agents, doing the work. The result has to be reviewed, tested, secured, deployed, monitored, supported, and eventually understood by the people expected to use it.
One of the most useful questions raised during the sessions was what would happen if your code throughput tripled tomorrow. For many organizations, the answer is probably not that customer value would triple with it. Review queues would grow. Testing could become a constraint. Security teams would have more changes to evaluate. Product teams would face more decisions. Customers and internal teams might not even be able to absorb the increased pace of change.
That idea came up repeatedly in different forms. DX and Dropbox discussed increasing code and pull request throughput while watching pressure move into review and other parts of the lifecycle. Atlassian described a similar challenge internally: accelerating coding does not solve the planning, coordination, review, and operating work surrounding it. Honeycomb’s Liz Fong-Jones made the same point from an operational perspective, arguing that when writing code gets cheaper, validation becomes more important.
The technology is speeding up one station in a much longer process. The constraint moves somewhere else.
Adoption and impact are not the same thing
Uma Namasivayam from Dropbox put a useful distinction around this: adoption is not the same as impact.
Much of the AI productivity conversation still starts with usage. How many developers have an AI coding tool? How much code is AI-assisted? How many hours do engineers say they are saving? Those are legitimate measurements, but they describe what is happening at an individual step. They do not necessarily tell us what happened to the system.
If an engineer completes something in two hours instead of two days but the work still spends three days waiting for review, the organization did not capture the full improvement. If an agent can build something almost immediately but the requirements were incomplete, we created the wrong thing faster. If teams can ship more frequently but nobody has a reliable way to understand what changed, why it changed, who owns it, or what depends on it, increased velocity can create more work somewhere else.
AI can be doing exactly what it promised while the overall system fails to capture all of the benefit. The productivity of one step and the throughput of the whole system are different things.
AI is exposing problems that were already there
AI did not create fragmented knowledge, unclear ownership, outdated documentation, inconsistent processes, manual handoffs, or decisions trapped in meetings and chat threads. Those problems existed long before coding agents arrived.
Humans have simply gotten very good at compensating for them. We ask the person who has been here for eight years. We message someone in another department. We interpret an incomplete ticket based on experience. We know which document is current and which one quietly became irrelevant.
A capable person can navigate a surprising amount of organizational ambiguity because people fill in gaps constantly. Agents change the economics of that ambiguity.
Brian Houck from DX described context as a potential next bottleneck for AI-assisted development. The challenge is not creating mountains of documentation. Too much irrelevant or outdated context can make an agent less effective. The challenge is making the right context accessible, current, understandable, and useful.
That means decisions need enough history to make sense later. Standards that once lived in someone’s head may need to become explicit. Ownership has to be identifiable. Important knowledge has to exist somewhere an agent can actually reach it.
AI did not create the context problem. It made the cost of poor context much harder to ignore.
Faster execution changes the value of decision-making
The same shift is happening on the product side. Tamar Yehoshua at Atlassian and Elena Verna at Lovable both talked about what happens when building and testing ideas becomes dramatically easier. Product managers can prototype more quickly. Engineers can explore alternatives instead of debating them for weeks. People outside traditional engineering roles can build things that previously required a development team.
That is an enormous opportunity, but it changes where the scarce resource sits. When execution gets cheaper, deciding what is worth producing becomes relatively more important. A company can now make a good decision and act on it faster. It can also make a bad decision and act on that faster.
The answer cannot be to compensate by wrapping every AI-enabled action in another approval layer. Organizations need better ways to establish intent, provide context, define boundaries, and determine where human judgment actually matters. As agents take on more execution, people spend more time deciding what should happen, making tradeoffs, reviewing results, and determining whether the output is actually good enough.
Guillermo Rauch made a related point about the continuing importance of human taste. If everyone has access to highly capable models, simply producing something becomes less differentiating. Knowing what good looks like becomes more valuable.
The hard part starts moving from “Can we build this?” toward “Should we build this, what exactly are we trying to accomplish, and how will we know if we got it right?”
We may be measuring the wrong part of the change
AI transformation is easy to measure through activity: licenses activated, prompts submitted, tokens consumed, code generated, pull requests created, hours reportedly saved.
Those numbers can tell us whether people are using AI. They do not necessarily tell us whether the organization is getting better because of it.
A more useful place to look may be where work waits. How long does an idea take to become something useful? Where does it stop? Where does somebody have to reconstruct context? What happens when work crosses a team or system boundary? Where has additional output from one part of the organization created more work for another?
DX’s work on value-stream measurement gets at this directly. If AI makes one portion of a process faster, the only way to understand the real impact is to look at the full path the work takes. Otherwise, a local productivity gain can look like organizational transformation even when the customer experiences very little change.
The question is not only whether AI made a person faster. It is whether that speed survived the trip through the rest of the organization.
The bigger AI opportunity may be outside the prompt box
Better models will matter. Better agents will matter. But the next phase of AI adoption may depend just as much on everything surrounding those tools.
Context has to travel with the work. Ownership has to be clear. Systems need to connect. Review and validation need to keep pace. Governance has to provide real boundaries without turning every action into a manual approval. Processes built entirely around human execution need to be reconsidered for a world in which humans and agents both participate.
That is a much larger change than deploying an AI coding assistant. It also explains why some of the most important AI work inside a company may not look like AI work at all. It may look like cleaning up ownership, connecting information, eliminating handoffs, clarifying how decisions get made, improving testing, or redesigning a process that has accumulated years of workarounds.
AI is making execution faster. In doing so, it is showing us exactly where the rest of the organization is not.
The companies that get the most value from this shift will not simply be the ones that generate the most code or deploy the most agents. They will be the ones that get better at turning ideas into outcomes across the entire system.
The bottleneck moved. Now we know where to look.
