Blog
AI Amplifies What Is Already There
Posted on 2026-10-26 - 4 minute read
Key takeaways
- Speeding up one part of a system does not speed up the whole. Overall performance comes from how the parts fit together.
- AI acts as an amplifier. It makes a good flow better, and it makes bottlenecks and friction worse.
- Clear, intent-revealing naming helps humans and LLMs alike. Bounded contexts and ubiquitous language still matter.
- Code is cheap to generate, but not cheap to own. About 90% of lifetime cost sits in maintenance and evolution.
- Domain-Driven Design, Wardley Mapping, and Team Topologies work well together as one toolset for flow.
Why local optimisation fails
Many organisations sprinkle AI on their systems and expect delivery to accelerate. Susanne opened by explaining why they are usually disappointed. Drawing on systems thinking, she reminded us that a system is more than the sum of its parts. So the useful question is not how to make parts faster. It is how to reduce bottlenecks.
She walked through common sources of friction. Teams hand work over and wait in queues. Tightly coupled architecture causes side effects and rework. Fuzzy domain models make code hard to reason about. Teams take on too much, and cognitive load grows. Too much work in progress leads to constant context switching. Most of the room recognised at least one of these.
What the research says
Susanne then turned to recent research, and the results were sobering.
- One paper found that LLMs understand code through two channels: structure and human-readable naming. When names were obfuscated, performance dropped sharply, and the models began to hallucinate domain meaning.
- A Carnegie Mellon study saw a three to five times velocity spike in the first month of AI use. It was then cancelled out by a 30% rise in warnings and a 41% rise in code complexity.
- A CodeScene analysis found that AI-generated code caused a 60% higher defect rate when applied to problematic code.
- The DORA report describes AI as an amplifier of both strengths and pain points.
Her conclusion echoed the Theory of Constraints. Any improvement made away from the bottleneck is an illusion.
Building foundations for continuous change
So what should we do? Susanne proposed treating organisations as sociotechnical systems, and optimising for flow rather than speed. Her approach combines three perspectives.
- Start from user needs. Use jobs to be done to see what users are trying to achieve.
- Categorise the problem space. Domain-Driven Design separates core, supporting, and generic subdomains. Invest most in the core, and consider buying or outsourcing the rest.
- Modularise the solution space. Use collaborative modelling such as Event Storming to find bounded contexts. Place them on a Wardley Map. Then align them to stream-aligned teams, supported by platform and enabling teams from Team Topologies.
She packaged this as the Architecture for Flow canvas. It is a conversation starter, not a rigid framework. You assess your current situation, then design an ideal future as a working assumption. You can skip steps or add your own.
Guardrails for humans and machines
Susanne closed with guardrails that help people and AI at the same time:
- Focus on flow and reduce bottlenecks.
- Invest in your differentiators.
- Keep a user-centric focus.
- Aim for loose coupling, consistent naming, and healthy code.
- Align teams to streams of change.
None of this is new, as she said. What has changed is the cost of ignoring it. AI now magnifies the consequences.
What attendees said
This was probably one of the most meaningful talks of the conference for me personally. The importance of flow is fully clear to me, and the tools and order of use are really powerful.
Crisp, clear structure, logically presented. A great teacher.
The overview of scientific papers at the beginning was so valuable. I will prioritise reading on this topic.