AI doesn’t fix your bottlenecks. It amplifies them. DORA’s report on AI-assisted software development [1] confirmed that AI amplifies existing flow and exposes brittle processes and frictions. If your flow is good, AI makes it better. But if you have a lot of painful bottlenecks and frictions, AI makes the pain worse.
If the underlying system does not evolve, increased speed, e.g., through AI-accelerated code generation, turns into decreased software delivery throughput (lead time for changes, deployment frequency, failed deployment recovery time) and increased software delivery instability (change fail rate, rework rate), according to the DORA report.
This has profound implications on how we think about AI adoption. And it’s why I believe the foundations we build – in our architecture, our teams, our strategy – matter more now than ever.
The Bottleneck Illusion
From a systems thinking perspective, optimizing one part of the system will not improve the performance of the whole. As Dr. Russell Ackoff has stated, “a system is more than the sum of the behavior of its parts. It’s a product of their interactions. The performance of a system depends on how the parts fit—not on how they act taken separately.” [2]
Or, as Eli Goldratt’s Theory of Constraints explains, “any improvement made anywhere besides the bottleneck is an illusion.” [3] If writing code was never been the bottleneck, but rather the handoff to another team for review, testing, or deployment, then AI-accelerated code generation doesn’t increase throughput. It increases inventory. More work piles up at the constraint, and the system’s overall performance doesn’t improve.
What is Preventing Flow?
The focus should be on flow, not just speed, as also emphasized in the DORA report. Optimizing flow of change isn’t about going faster, but about removing blockers to flow. Ideally, teams shall fully own the entire end-to-end flow of change from first idea to deliver value to customers with minimal interruptions and bottlenecks.
In my experience working with organization across different industries, the blockers tend to cluster around four areas: team ownership, team dependencies, software architecture and quality, and work management.
When teams don’t fully own the entire end-to-end flow – from planning, designing, and developing through testing, releasing, and running their parts of the system – they depend on other teams to get their work done. That dependency introduces repeated handoffs as blocking dependencies with communication and coordination overhead leading to wait times and delays.
When dependent teams are unavailable or unable to keep up with the demands placed on them, they become a constraint that slows down the entire system.
From a software architecture perspective, tightly coupled systems impedes the flow of change, as changes in one part of the system can have unpredictable side effects on other parts, increasing the risk of defects and rework. From a software quality point of view, accumulated technical debt leads to fragile codebases that are hard to maintain long term.
Messy architecture with blurry boundaries makes it difficult to establish clear ownership boundaries in the first place, leading to a potential “not my job” syndrome with a lack of accountability and delayed decisions. Business logic mingled together in messy models with no clear modularity increases the mental effort required to understand any piece of code. Teams often end up owning too many or overly large parts of the system, exceeding their cognitive capacity and becoming delivery bottlenecks themselves.
When teams lack clear priorities and focus, they try to work on too many things at once. High work-in-progress, frequent interruptions, and context switches all impede the flow of change and stretch out feedback loops.
Each of these blockers impeding the flow of change is painful enough on its own.
Now Add AI to This
So what happens when adding AI-accelerated code generation into a system that already has these problems?
AI mirrors the structures it finds. AI doesn’t truly understand domain meaning the way humans do. It statistically infers meaning from patterns in surrounding context. Without clear boundaries, AI doesn’t know where one domain concept ends and another begins. In a big ball of mud with messy models and fuzzy boundaries, AI fills in the gaps with plausible-looking but semantically wrong code – it hallucinates domain meaning. It picks up whatever naming and patterns it finds in the codebase, and if those are inconsistent, it propagates and amplifies the inconsistency. Without architectural guidance, it mirrors and generalizes the existing structure, creating more coupling in already tangled code.
AI amplifies organizational frictions. AI generates code faster, but if writing code wasn’t the bottleneck, the extra speed just creates a bigger queue at the handoff. More PRs, more changes per day – but with the same team capacity, cognitive load goes up, not down. The frustration of already overloaded teams increases. Before AI, unowned code areas grew slowly because developers were reluctant to touch them. AI has no such reluctance. It generates into unowned areas just as confidently as anywhere else, so the volume of code nobody owns, and nobody feels responsible for grows much faster.
AI helps you build the wrong things faster. AI doesn’t distinguish between core differentiators and commodity. Without strategic guidance, it happily custom-builds solutions for non-differentiating problems that already have commodity or off-the-shelf alternatives. Teams then end up spending review and maintenance effort on custom code of non-differentiating components.
Focus on Flow, Not Just Speed
The DORA report emphasizes focusing on flow, not just speed. Optimizing the flow of change isn’t about going faster – it’s about removing the bottlenecks that AI won’t fix for us.
Ideally, teams should fully own the entire end-to-end flow of change – from idea to delivering value to customers – with minimal interruptions and bottlenecks. That requires building solid foundations.
Building the Foundation: Connecting Strategy, Architecture, and Teams
One approach is combining Wardley Mapping, Domain-Driven Design, and Team Topologies to design, build, and evolve adaptive socio-technical systems optimized for a fast flow of change. In short: Architecture for Flow as a holistic toolset [4].
Understanding where change comes from. To build a foundation for continuous change, the first step is to understand what drives it. Change is driven by user needs. The needs of external or internal customers are strong candidates for identifying customer-driven streams of change – and teams and systems should be structured around them to ensure a fast flow of change where it matters most.
Mapping the business landscape. Wardley Mapping helps create a shared understanding of the business landscape: the value chain that connects user needs to the components that fulfill them, along with the evolutionary stage of each component. It enables assessment of efficiency gaps – for example, whether components are being custom-built even though they are not core to the business, or whether more evolved alternatives could be leveraged. It also clarifies where investment and innovation make the most sense. The map becomes a visual tool that guides decision-making.
Determining where to invest. Domain-Driven Design helps partition the problem domain into subdomains with different strategic value. The core domain provides competitive advantage and should be built in-house. Supporting subdomains are specialized but non-differentiating – the build-or-buy decision is more nuanced here. Generic subdomains like authentication or registration are neither specialized nor differentiating, and existing solutions should be leveraged wherever possible. This categorization provides strategic guidance for focusing development investments where they create the most differentiating value.
Modularizing the solution space. Moving away from a monolithic big ball of mud toward a modular, well-encapsulated, loosely coupled system requires good decomposition boundaries. DDD’s bounded contexts group related business behaviour together, enforce high cohesion, and serve as well-defined ownership boundaries. Designing them involves close collaboration between domain experts and development teams – techniques like EventStorming help explore the domain together and identify bounded context candidates.
Aligning teams to the system and strategy. Bounded contexts serve as well-defined team ownership boundaries for stream-aligned teams – cross-functional, autonomous teams aligned to a continuous stream of customer-facing work. Platform teams provide self-service capabilities that support the stream-aligned teams’ flow. The interaction modes between teams — collaboration, X-as-a-Service, facilitating – evolve over time as the system matures.
The Canvas: From As-Is to To-Be
To bring these perspectives together in practice, I developed the Architecture for Flow Canvas [5]. It provides just enough structure to guide organizations through assessing the current state and designing an ideal future – without being a rigid framework.
The current state assessment involves analyzing existing teams and their dependencies, assessing the current flow of change to identify blockers, and mapping the business landscape. From there, you gradually move into designing the future: categorizing the problem space into subdomain types, modularizing the solution space with bounded contexts, envisioning the future landscape on a Wardley Map, and aligning future teams and their interactions.
The ideal future is not a big upfront design. It’s a first working assumption – an initial direction for movement that gets course-corrected as you gain more insights.
Flipping the Script: AI on a Solid Foundation
So what happens when AI is added to a system with these foundations in place?
With modular, well-encapsulated bounded contexts, AI infers meaning from patterns that are now semantically coherent. Business logic is grouped together rather than scattered across the system. The hallucination of domain meaning is significantly reduced, and AI-generated code is better aligned to the domain. Consistent naming within bounded contexts means AI amplifies consistency rather than propagating inconsistencies. With loose coupling between bounded contexts, AI mirrors good structure and reinforces modularity instead of creating more coupling.
With strategic guidance from subdomain categorization, AI-assisted development is directed toward core domain differentiators. Teams no longer spend effort on AI-generated custom code for non-differentiating components. Development effort – human and AI-assisted – focuses on value creation, not reinvention.
With bounded contexts as well-defined ownership boundaries, every line of AI-generated code supposed to fall within a team’s responsibility. Reducing unowned code growing unchecked.
With teams optimized for cognitive load, the increased output from AI remains within the team’s ability to review, understand, and maintain. AI increases the throughput of a manageable scope rather than flooding an already overloaded team.
With cross-functional, autonomous stream-aligned teams owning the entire end-to-end flow, there are no handoffs for AI-generated code to pile up at. AI acceleration actually translates into increased throughput – not just increased inventory. And platform teams providing self-service capabilities ensure the infrastructure can absorb the increased pace, keeping the flow smooth and reliable.
Not New Because of AI, but Essential for AI
The combination of Wardley Mapping, Domain-Driven Design, and Team Topologies helps unlock blockers to flow, architect for change and leverage modularity, focus development investments on differentiators, close efficiency gaps, and align teams to streams of change.
The importance of applying these foundations isn’t new because of AI. But it has now become essential for AI – providing guardrails for safe AI adoption.
The question isn’t whether AI will change how we build software. It already has. The question is whether your foundations are ready for the acceleration.
Resources:
- [1] DORA’s State of AI-assisted Software Development report, 2025
- [2] Dr. Russell Ackoff: “Beyond Continual Improvement”
- [3] Eliyahu M. Goldratt: Beyond the Goal: Eliyahu Goldratt Speaks on the Theory of Constraints (Gildan Media, 2005)
- [4] Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies (Pearson, Addison-Wesley Signature Series (Vernon), 2025)
- [5] The Architecture for Flow Canvas