AI Coding Agents: What Really Changes for Software Developers (and What Doesn't)

Agentic Coding and DDD: Lessons from Marco Heimeshoff

When a seasoned Domain-Driven Design practitioner starts building software with AI agents, does it feel like starting over? For Marco Heimeshoff, the answer is no. "Nothing really changed," he says. "Only the weights got shifted."

This post collects the key ideas from our interview with Marco in Avanscoperta's Small Talks series: From One Agent to Many: Skills, Harnesses and Multi-Agent Systems.

Marco Heimeshoff is a Software Developer, DDD expert, trainer, facilitator and he is also the co-founder of the KanDDDinsky conference in Berlin. Over the past months he has moved his focus to agentic AI development, and in the interview he talked with Max Trense, Principal AI Engineer at sevDesk, about skills, harnesses and how the developer's job is changing.

Is DDD still relevant when AI agents write the code?

More than ever, according to Marco. Agentic development started as a detour for him: a way to draft tests or sketch an architecture faster during a client project. Within a few months, he noticed that "all the things we know from Domain-Driven Design actually help massively in creating software using agentic development."

Two DDD tools give him the best return on investment: ubiquitous language and bounded contexts. Both exist to manage mental load, so that a group of people shares a clear definition of what each term means. Marco's insight is that language models face the same constraint. Even a million-token context window has a limit on how much modeling and coding fits into one session.

"Having a clear language definition, clear terminology and meaning, concise in a bounded context, means your large language models really think in the same structure that you do."

The result, he says, is a collaboration that feels less like operating a machine and more like working with "thinking entities".

He is also clear about what this does not mean. Vibe coding is not the new development: you still need to be a developer who understands what is produced. But a team with a solid DDD background can now deliver "a magnitude more output with real focus on what the customers need", because the busywork gets automated.

Collaborative modeling with an LLM: the unsolved part

If ubiquitous language is the easy win, collaborative modeling is the hard frontier. Marco calls it the most valuable and most challenging practice in DDD: shared understanding leads to deeper cohesion in what you build and better prioritization.

With language models, it does not work yet, at least not the way it works in a room with a wall full of sticky notes. "Collaborative modeling with a large language model doesn't work until they get proper telepresence and are part of the room," he says. For now, the only way to align our mental models with the model's is conversation, spoken or written.

This is where Marco expects the highest return on investment. His near-future work is building tools, skills and agents that support collaborative modeling, so that language models understand what really needs to be built.

Should you use an agentic framework or build your own harness?

Marco built his own harness, Agentheim, out of frustration with other people's frameworks. He felt the same way years ago about CQRS frameworks: they help you get started, but their opinionated decisions "weigh you down and keep you stuck in whatever other people decided."

He tried many of them: Get Shit Done, BMAD, Superpowers, and nWave by Marco Consolaro, Alessandro Di Gioia and colleagues, which tackles similar problems with different opinions. "By now it's like the JavaScript frameworks from back then," he jokes. "There are more agentic frameworks out there than there are people coding in them."

None of them matched how he likes to work, regardless of the domain:

1. A big modeling session up front for discovery.
2. Detailed refinement and modeling sessions once there is enough understanding.
3. Implementation of the architecture.
4. A defined review process.

So he described his own workflow. With LLMs, you can point the model at what you like elsewhere: the Kanban flow of one framework, the domain modeling of another. In about half an afternoon, he had his own set of skills, agents and commands. Later he added memory: stateful memory for tasks and which bounded context they belong to, plus accumulated knowledge such as domain understanding and architecture decision records (ADRs).

Agentheim is open source, but Marco does not present it as the way to work:

"I'm not saying this is the best way to work, but that's the way I work. Use it as inspiration. Learn from it, how it works and how it solves my problems. Then adapt it or build your own from scratch, because that's not hard to do. It just takes time."

One detail stands out. An agentic development framework is a domain in itself, so at some point Agentheim started building itself. Marco has a project inside Agentheim that modifies Agentheim, which is why it evolves so quickly.

Which skills do software engineers need now?

Marco's answer is almost provocative: the same ones as before. Learning has always been the real bottleneck, for individuals, teams and whole companies. That means learning about the domain, about customer and stakeholder needs, and about technical possibilities. Coding was the production bottleneck. It consumed so much time that builders often got stuck thinking about the tool instead of the problem.

Now that writing code can be largely automated, the skills that matter most are:

• Collaborative learning and collaborative modeling, including building psychological safety and exploring needs in depth.
• Domain modeling and precise description in language.
• Architectural thinking: understanding the pros and cons of different decisions.
• Fast learning cycles: short bursts of experimentation, then depth where it's needed.

What loses importance is typing code yourself. Reading and understanding it does not. "Writing code itself is basically something you can automate," Marco says, "but you still need to read it in most places." You need a deep grasp of detailed decisions because of security, performance and correctness concerns.

Not a win for everyone

Max suggested this was good news for most engineers. Marco pushed back. He sees two broad kinds of developers:

• Problem solvers, for whom code was always a means to an end. "Those people are having a field day right now."
• Technology tinkerers, who love spending three days on a bug and becoming experts in technical solutions. For them, the part of the job they cherish is being automated. What's left is more conversations, more modeling sessions and more talking to users.

"The shift is real, and I don't think it will go back. Many developers will lose joy in what they were doing, because the thing they like to do gets automated and the thing they don't like to do becomes their new job. That is a problem."

His advice is candid and, as he admits, not easy to hear: your job is not a purpose in itself. "Solving problems is the job we are needed for." If you can find joy in solving problems in a different way, there is hope. He applies this to himself too, since much of what consultants do can now be done by language models.

Max, a self-described introvert, added a hopeful note. Meetings with non-technical roles used to drain him. Well-facilitated modeling sessions changed that, so it's worth trying different collaborative techniques before writing them off.

How do you review code when AI writes more than you can read?

Max raised a common fear: if AI ships code faster than ever, review becomes the bottleneck. On top of that, can you really own code you didn't write?

Marco starts from Alberto Brandolini's bullshit asymmetry principle: refuting nonsense takes far more effort than producing it. With LLMs this runs at an accelerated pace, because models "can produce slop way faster than you can even attempt to clean it up." That makes well-drawn context boundaries even more important, because they tell you where to spend your review effort.

Architecture can also reduce line-by-line review. With a proper hexagonal or onion architecture, where only commands and events cross the boundary, you can test the entire outer surface of the domain model. Then you can verify that the code works "without reading the code even". You still want it well written, so humans could take over if the models stopped working. That's a risk you choose to take.

The question shifts from "do we review every line?" to what do we need to review here: every line, the system's behavior, or all possible data variations in a given area?

Slow down

Marco's most counterintuitive advice: some clients ask how to get better at agentic development, and he tells them to slow down, or stop.

"Just because it's possible doesn't mean you should rush towards it. Take the pace that you as a team can actually sustain. The delivered software is not the code being written. It's the product being tested and implemented, solving the problem."

If coding is no longer the constraint, you don't need to fill the freed time with more code. Spend it on modeling and architectural reviews. Otherwise, "code reviewing will break your neck."

How do you keep up with a field that changes every week?

Marco doesn't pretend to have this solved. "We are still somewhere between chaotic and complex here. There are no good practices yet." He has never run an edition of his agentic development workshop without changing the content mid-workshop. During the most recent one, a new fast, cheap classification model and new frontier models came out, and he spent the weekend exploring what they meant.

His recommendations:

• Don't be a completionist. Don't chase good or best practices. Figure out what works for you right now.
• Run small, controlled experiments. One per week, one per month: find your own pace.
• Start a community of practice inside your company. People who keep an eye on what's out there, and who can also say "this is too much for us right now."
• Throttle the stream of innovation. In any overhyped market, trying every new thing costs more than it's worth.
• Join communities and follow people with good advice. Marco mentions Matt Pocock and his skills.
• Solve actual problems. This is the one that works best for him, because "nothing carries as far as motivation." Don't try a new model because everyone else is. Try it when you have the problem it was built for.

Asking how to keep up with all of AI, he says, is like asking how to keep up with everything in computing. Narrow it down. For software development, his short list of what's at the leading edge right now: agent harnesses and how to build your own, doing proper Domain-Driven Design with agents, and knowing when to use fast classification models versus slower inference models.

Learn more with Marco

Marco runs a hands-on Masterclass on Agentic Development at KanDDDinsky in Berlin on 12–13 October, and his The Agentic Developer Workshop online. Its content will be updated with whatever comes out before then, including local models and "system one and system two thinking".

Watch the full Small Talks episode "From One Agent to Many - Marco Heimeshoff and Max Trense".