Bitrock Software Engineering Manager Luca Tronchin attended KanDDDinsky 2026 in Berlin. In the following article, he shares his key takeaways and insights from two days spent exploring the powerful interplay between AI, agentic systems, and Domain-Driven Design, offering a compelling read on why domain modeling is more critical today than ever before.
In mid-October, I spent two days in Berlin at KanDDDinsky, the European Domain-Driven Design community conference. This year’s theme was how DDD and agentic development strengthen each other. I expected demos of agents writing code for us. Instead, I found fourteen sessions that, from different angles, reached the same conclusion: AI makes us faster, but on its own it does not bring us any closer to what the business actually needs.
In this article, I share the ideas I brought home and why, in my view, they make modeling practices more important today than they were before AI.
AI multiplies, confusion included
Roman Sachse’s opening keynote, drawing on his work at a 150-year-old German logistics company, gave the key for reading the whole conference: AI is a multiplier and a multiplier applied to zero gives zero. Where there is a solid domain, with processes and structure, AI adds enormous value. Where there is only fluff, it amplifies the fluff.
Vlad Khononov said the same thing from an architectural point of view: AI multiplies the benefits of modularity, but also the damage when modularity is missing. A Big Ball of Mud is the ideal ground for an agent to produce chaos faster. Beija Nigl confirmed it with a concrete experience: a legacy codebase with no tests or documentation, taken over with a mandate to use AI for everything. When the team understood the domain, AI sped them up; when they did not yet understand it, AI led them astray with complete confidence.
The bottleneck was never the code
If AI writes code ten times faster, why don’t products ship ten times sooner? Susanne Kaiser answered with a figure that stuck with me: in a study of 500,000 developers using coding agents, pull requests grew by 86% and lines of code by 958%, but production releases by only 20%. The work piles up before it reaches the user.
As Susanne Kaiser pointed out, quoting Eli Goldratt’s Theory of Constraints, any improvement made outside the bottleneck is an illusion: AI does not remove bottlenecks; it exposes them. And the bottleneck, as Marco Heimeshoff and Alberto Brandolini repeated, was never writing code. It is understanding what the software is supposed to mean. Without a clear domain, an LLM makes things worse before it makes them better: it amplifies every ambiguity in the language, at full speed and with full confidence.
In the closing keynote, Andrea Magnorsky also showed the price of this acceleration. According to Faros AI telemetry from 22,000 developers, with heavy AI adoption, the epics completed per developer grow by 66%, but incidents per pull request rise by 243% and bugs per developer by 54%. In an Australian survey on the perceived benefits of AI, “speed” took 36% of responses and “better code quality” 0%.
Roman Sachse added an observation I find illuminating. AI has drastically shortened every loop that runs through an artifact: an idea is tried on Monday and evaluated on Tuesday. But everything that runs through people and organizational structures takes as long as it did before. That is where the transformation is now being played out.
Bounded Contexts and Ubiquitous Language: the foundations of agents
The most concrete part of the conference was about building reliable agentic systems. Marco Heimeshoff flipped the usual perspective: not AI helping us model, but modeling making AI work. The answer is not a better prompt; it is the harness: the whole system built around the model so it does reliable work without anyone watching every step.
And what holds a good harness together is exactly what DDD has spent fifteen years getting good at. Bounded contexts give each agent a small, well-fenced world, with a slim context that keeps the model from wandering and wasting tokens. Ubiquitous Language pins down intent, so what the agent builds is what the business asked for. The practical advice I took home: start from existing harnesses, then build your own, tied to the domain and to the parts of the domain each task needs.
Susanne Kaiser added a detail that seems small but is not: LLM performance drops when names in the code lose their meaning. Consistent, intention-revealing naming serves people and machines alike. Golo Roden completed the picture from the data side: event sourcing preserves not only what happened, but why, when, and in what order. That is exactly the context most AI systems lack, as they retrieve text but not meaning.
Features, futures, and the cost of ownership
A quote from Kent Beck came back in at least three talks: the economic value of a project is not just the sum of the features it has today, but also of its “futures”, the options for what it can do tomorrow. AI speeds up building features, but it can burn future options just as fast. Susanne Kaiser’s slides cite research showing that applying AI to code that is already problematic brings a 60% higher risk of defects, and that productivity gains vanish within a couple of months under the weight of complexity and technical debt.
Xin Yao reminded us that Ward Cunningham’s original technical debt metaphor was not about badly written code: it was about learning. We build with what we know today, we learn by using the software, and yesterday’s good design is no longer enough. In other words, today’s value is tomorrow’s technical debt. With AI-generated code, this loop gets shorter, and the debt piles up faster.
Then there is a question we will hear more and more often: if building is this cheap, why not generate everything? Because cheap to generate does not mean cheap to own. The initial build accounts for roughly 20–30% of an application’s lifetime cost; the rest is maintenance, operations, support, and evolution. Jacopo Romei took the same principle outside software, telling how he founded his companies: the most irreversible decisions should be postponed until they help you understand future opportunities, rather than closing them off too early.
The part AI doesn’t do: modeling together
Alberto Brandolini’s talk, from the creator of EventStorming, was the most revealing one for me. He described rewriting a personal piece of software with AI, playing every role himself: domain expert, customer, developer, architect. Alone, it is easy and powerful. But it is a huge simplification compared to real projects, where knowledge has to be drawn out of domain experts with effort and people have to agree on a common model. Here AI does not help: it tends to approve, it does not push back, and it does not surface the doubts a good modeling session brings to light.
Xin Yao went further: the deepest debt in many teams is not technical; it is social. It builds up when assumptions go unnoticed, when mental models don’t change, when nobody takes responsibility for deciding under uncertainty.
Andrea Magnorsky’s closing keynote brought the conversation back to people. Starting from a story of layoffs at a company in crisis and from greenfield projects where everyone says yes but each person imagines a different product, she proposed a three-step cycle: build community, understand, act. Among the concrete tools: making the decision process explicit with Architecture Decision Records and Andrew Harmel-Law’s advice process, where anyone can make an architectural decision after seeking advice from those affected and from those with experience in the area.
And a simple social contract: listen to understand, not to respond, and not to meet in the middle. At a time when, according to a survey she cited, 72% of tech workers worry about layoffs and 84% report burnout, it is a reminder worth as much as any technique.
What it means for those who build software
I came back from Berlin with a stronger conviction than the one I left with. AI does not make Domain-Driven Design obsolete: it makes it indispensable. For those of us at Bitrock who work on software projects with our clients every day, this translates into a few concrete choices:
- Fix the domain, boundaries, and ownership before accelerating with AI, because AI amplifies whatever it finds;
- Treat bounded contexts, ubiquitous language, and naming as requirements for agents, not as optional good practices;
- Judge every piece of generated software by its cost of ownership, not only by how fast it comes into being;
- Make explicit how decisions are made, because deciding well under uncertainty is a team effort;
- Keep domain experts and the business at the center, with collaborative modeling as the moment where value is created.
As Susanne Kaiser said at the end of her talk, none of this is new. But today it is needed more than ever.
Author: Luca Tronchin, Software Engineering Manager @ Bitrock