Last week at the Infoshare conference, Jon Kern — co-author of the Agile Manifesto — and I opened the Tech Trends stage with a talk about how AI is changing software delivery, engineering organizations, and ultimately the meaning of agility itself.
What made the discussion especially interesting was that we were not talking about AI as a futuristic concept anymore. We were talking about something many engineering teams are already experiencing every single day: systems are accelerating faster than organizations can fully understand and coordinate around them.
The more conversations I have with engineering leaders, platform teams, architects, and developers, the more I notice the same tension appearing almost everywhere. On one hand, AI is dramatically increasing our ability to generate software outputs. Teams create more code, more specifications, more pull requests, more architectural proposals, more tests, and more implementation ideas than ever before.
And yet, underneath that acceleration, many organizations quietly experience something very different: coordination becomes harder, shared understanding weakens, and complexity grows faster than teams can align around it. There’s already a term for that: comprehension debt.
This is especially visible in environments where “vibe coding” starts becoming normalized — situations where AI-generated output moves so quickly that people gradually stop deeply understanding the systems they are building.
The software may still compile, deploy, and even look productive from the outside, but internally, the delivery system slowly drifts away from human intent, shared context, and coordinated understanding.
And I believe this fundamentally changes what agility means in the AI era.
One of the most visible effects of AI-assisted software development is the explosion of output across the entire delivery lifecycle.
Teams generate:
This initially feels incredibly productive — and in many ways, it truly is. But engineering systems are not only production systems.
They are also coordination systems.
Every generated specification still requires interpretation. Every code change still requires understanding. Every architectural decision still affects dependencies, ownership boundaries, workflows, operational reliability, and long-term maintainability.
And while AI can dramatically accelerate generation, it cannot automatically create organizational alignment. This is where many organizations start experiencing subtle but important signs of strain.
Code reviews become slower despite faster implementation. Teams spend more time clarifying intent. Dependencies become harder to manage. Architectural consistency weakens. Developers increasingly rely on AI-generated explanations to understand AI-generated code. Conversations shift from deliberate reasoning toward reactive interpretation.
In many organizations, people already feel this tension intuitively, even if they struggle to describe it precisely.
The system appears faster on the surface.
But underneath, coordination becomes more fragile.
One of the most insightful observations Jon Kern recently shared is: “AI doesn’t create problems. It removes the delay between cause and consequence.” That sentence captures the current moment remarkably well.
AI amplifies how organizations already work. Strong systems become more adaptive. Weak systems become more unstable.
Organizations with:
often experience AI as a multiplier of effectiveness.
But organizations already struggling with:
frequently experience accelerated instability instead.
Because AI increases the speed at which organizational weaknesses propagate through the system.
And many of the earliest signs of that breakdown do not first appear in dashboards or deployment reports. They first appear in day-to-day work. Teams start experiencing:
People often recognize first when the system stops making sense. And that turns out to be incredibly important.
Traditional management approaches often assume something relatively simple: if delivery slows down, we should be able to identify the root cause and implement the right fix.That logic works reasonably well in environments where cause and effect remain visible and stable.
But modern software systems rarely behave that way anymore.
In complex engineering organizations, we often do not see the full picture clearly or right away. Signals appear across people, workflows, architecture, tooling, dependencies, communication structures, and organizational boundaries simultaneously. Causes become distributed. Understanding itself emerges gradually.
Teams notice friction locally. Experiences differ across groups. Patterns slowly become visible over time. Meaning is constructed collaboratively rather than discovered instantly.
Jon often describes this process as: “Sneaking up on the answer.” And that description feels increasingly accurate in AI-assisted engineering environments. Because AI dramatically increases the number of interactions, changes, dependencies, and generated artifacts moving through the delivery system at any given time.
No centralized management structure can realistically interpret all of that complexity directly. Organizations increasingly depend on distributed sensing and collective interpretation instead.
For years, many organizations treated Developer Experience — DevEx — primarily as a satisfaction or productivity initiative. Surveys. Sentiment tracking. Developer happiness metrics.
But that framing is becoming far too narrow for the AI era.
Because good DevEx systems are evolving into something much more important: organizational sensing and improvement systems.
The people doing the work experience the delivery system most directly while interacting with it every day. Developers do not only see Jira tickets, pull requests, or deployment pipelines. They experience the tradeoffs, the unclear boundaries, the dependency pain, the coordination gaps, the workarounds, the technical debt, the cognitive overload, and the hidden friction that metrics alone often struggle to fully explain.
This matters enormously because engineering metrics, while extremely valuable, only show part of the picture.
Engineering metrics are great at showing patterns. But they are built from many small, fragmented signals generated during day-to-day work.
DORA metrics can show slower delivery performance. Jira workflows may reveal increased rework or longer cycle times. Code review analytics may expose slower review processes.
But metrics alone rarely explain:
And that distinction becomes critically important in increasingly complex AI-assisted environments.
Take code review time — increasingly becoming a bottleneck as AI helps teams generate more code and changes faster than before.
Engineering metrics may show that reviews are slowing down. But without additional context, we still do not know what that actually means. Is friction increasing because reviews now require too many manual validation steps? Is clarity lower because AI-generated code is harder to reason about? Or is flow slowing down because changes now require coordination across too many repositories and teams?
The same metric can represent entirely different organizational realities. This is where DevEx becomes essential.
Engineering metrics show patterns. DevEx helps explain what those patterns actually mean — and what should change next.
A practical example illustrates this dynamic very clearly. Imagine a platform team building internal tooling used by more than 300 developers across an organization.
During one quarter, their biggest friction suddenly becomes specification clarity. On a DevEx survey question asking whether “Projects and task specifications are clear and well-defined,” the score drops by 19 points.
Importantly, this is not one isolated complaint. The signal emerges collectively across the team. And the comments explain the reason surprisingly clearly.
Specifications are increasingly generated with AI. They are long, detailed, technically impressive — but often missing clear priorities, boundaries, and intent. The distinction between what is critical versus optional becomes blurry. Developers gradually become unsure what exactly should be built.
Meaning starts breaking locally.
Now look at the operational metrics. DORA may show slower delivery. Jira may reveal more reopened tickets or additional rework. Cycle time may increase. But none of those metrics fully explain that shared understanding itself is breaking — why it is happening — or what should improve next.
At this point, two organizational scenarios become possible.
In the first scenario, the team notices the friction early. They simplify specifications, clarify expectations, introduce examples of clearer requirement structures, and openly communicate the issue with architects and stakeholders. Feedback loops remain short. The system adapts quickly.
But in the second scenario, nobody really notices the deeper coordination problem. The pressure becomes centered around generating more output with AI. Specifications are written with AI. Developers increasingly use AI to interpret them. The organization becomes progressively further removed from original human intent.
And slowly, the produced code drifts away from shared understanding.
Because this is a platform team, the friction does not remain local. It spreads into the work of hundreds of other developers who depend on the platform and its abstractions.
This is how relatively small gaps in understanding and action grow into much larger system problems.
This is why I increasingly believe that modern DevEx systems should not be viewed as reporting tools.
When done well, DevEx becomes an operational layer for continuous improvement.
Developers continuously sense and share friction and strengths. DevEx structures those signals across day-to-day delivery work — around clarity, flow, testing, reliability, coordination, AI-assisted work, and cognitive load.
AI can then amplify patterns by grouping comments, identifying recurring pain points, surfacing coordination gaps, and highlighting where attention is needed most.
But the real value is not the insight itself. The real value emerges when organizations turn those signals into coordinated action.
This distinction matters enormously because modern engineering organizations rarely fail due to lack of data. More often, they fail because understanding remains fragmented across teams, coordination happens too slowly, or organizations struggle to operationalize learning as systems continuously evolve.
The organizations that succeed in the AI era will probably not simply be the ones generating the most output.
They will be the organizations best able to:
while AI continuously accelerates change around them.
This is why pragmatic agility matters more than ever.
Not agility as a ceremony.
Not agility as process compliance.
Not agility as blindly accelerating output.
But agility as the organizational ability to continuously sense, understand, coordinate, and improve increasingly complex delivery systems.
Because in the AI era, the real bottleneck is no longer only producing software fast enough.
Increasingly, the real bottleneck is maintaining shared understanding while everything else accelerates.
