The code was beautiful. It didn't matter. The Domain Engineer sale starts today.

Hey Mailwal!

I'm not afraid to say that Domain-Driven Design may become one of the most important tools in agentic coding.

When anyone can generate code fast, nobody can afford to stay a coder who blindly implements Jira tickets.
Why pay 10 engineers to copy-paste tasks from Jira to Claude if one person can do it?

Even though the software engineering market is changing, I think that the bigger shift is still ahead of us.
AI labs like Anthropic are a good indicator of the future: they pioneered agentic coding at extreme scale.
If we leave the hype behind and look at their data, they are not hiring fewer engineers.
The important detail is what kind of engineers they hire: since early 2025, the share of juniors among technical hires has dropped from 27% to 9%.

It's easy to assume "I'm safe, I'm a senior with 10 years of experience". But in 2026, 10 years of turning tickets into code don't make you a senior engineer.
Claude can't solve every ticket on its own. Forget the tales about fully autonomous agents in complex production environments: especially in domains where it can't copy an existing approach. But one senior engineer with Claude can now solve many more tickets at once.

Whether we like it or not, it's now easy to fall behind enough to struggle to find a new job.
But the good news is that our job is not disappearing, especially for people who have a product-engineering mindset.

DDD to the rescue?

I said at the beginning that DDD may become one of the most important tools in agentic coding.
That's because it gives you tools for problems that agents can't solve:

• what problem should the system solve?
• what are the most important parts of the system?
• how do we gather knowledge from domain experts and make sure the software meets their needs?
• how do we split (modularize) the software so more people can work on it efficiently?
• how do we implement it so it's hard to break?

Someone may say "I'll create a DDD skill that will ask all those questions for me, hold my beer".
I test this idea with frontier models from time to time.

Recently, I dumped all relevant knowledge from our trainings into a skill and tried it with Fable and Opus 5.5.
With this skill, I started a long planning session to ensure the requirements and architecture would be right.
After the spec was complete, Claude started the implementation.

Half a day later, after burning almost the entire weekly token budget of my 20x plan, it finished.

The code was elegant. But it didn't matter: the outcome was useless.
Even though during planning the model prepared beautiful wireframes and assured me of perfect UX, I still haven't used it. It was technically correct, but unusable from the user's perspective.

History likes to repeat itself: I've seen such codebases before.
They were technically excellent, but useless for a real user.
The one difference is that we no longer need to write this beautiful code manually.

It's a caricature of Domain-Driven Design. Code like this is the reason people consider DDD overengineering.
But DDD cares about the user's problem more than about beautiful code.

If it crossed your mind that "it's not my job, it should be done by a product manager and put in a Jira ticket", you have been caught in another DDD trap. The user's problem is your job too.
That mindset is a fast track to becoming an unhirable engineer in times when beautiful code is cheap to build.

Does this story mean that coding agents are useless?
Not at all: agents are excellent for iterating on the initial implementation they created.
I don't expect them to one-shot a perfect implementation. I've built such sophisticated software before, so I know why the first version doesn't work and how to steer the next one.

But how can you learn to make these decisions if you don't work with the code yourself?

That's why we created The Domain Engineer training.
You build a food delivery platform in Go, in your own IDE, by hand or with a coding agent.

Along the way, you make the decisions from the list above, like which parts stay CRUD, which need careful modeling, and where to split the modules. It will give you expertise and confidence that the direction in which you are driving agents is right.
It's a safe environment: if you break something, you break it here, not at work. Don't risk your reputation and promotion by learning new patterns in production.

The sale runs until November 4.

See what you'll build in The Domain Engineer

Why learn with us?

First, we are pioneers of idiomatic Domain-Driven Design in Go.
Our DDD example repo is the most starred Go DDD example.
Our e-book is a reference for many teams on how DDD should be implemented in Go and has been downloaded more than 60k times.

We don't have good data yet to know if you must code by hand or with an agent to learn most efficiently.
But we support both ways, and we provide special agent instructions so you don't just one-shot the training without reading anything.

Setup takes a minute: the CLI prepares the whole project, and you open it in your IDE.
If you're stuck, you can ask the AI mentor, which knows the codebase and every exercise, or Miłosz and me on Discord.

It's all built on 18 years of our backend experience.
We give you knowledge that has been battle-tested in multiple types of projects, and we are sure it works.

That's why you can return the training up to 30 days after the cohort starts. No reason is required: we will pay you back in full. It's self-paced so you can go with the cohort or finish at your own pace.
All the risk is on our side.

Lastly, this is timeless knowledge, and you keep the training forever. You pay once, and receive all future updates for free.

The sale runs until November 4, and the cohort starts on November 5. The price goes up after every sale, and the next one is in spring 2027.

I'm joining The Domain Engineer

PS: We issue invoices. You can use your training budget and have your company pay for it. Add your tax ID at checkout. We also have bulk discounts for teams (10+ licenses) and payment via wire transfer. If you're applying for a training budget, start the process today. Corporate procurement takes ages. Pay now, and have it reimbursed later when the budget is approved.

Any questions or doubts? Reply to this email. I read them all.

Cheers,

Robert