AI has undeniably changed the day-to-day of software engineering - but not always in the ways the headlines suggest. Over the past two weeks, I’ve been reflecting on how tools like Claude Code and Cursor affect our work, why the hype around AI is missing the point, and why Domain-Driven Design (DDD) might just be the most valuable skillset in this new landscape.
This article brings those thoughts together, and brings them in an article format.
How AI Changed What We Do (and Didn’t)
AI tools can already do a lot:
- Generate decent code
- Write corresponding tests (the task most of us rarely enjoy)
- Help us explore unfamiliar tech
- Act as a rubber duck in tricky moments
The mechanical translation of requirements into code has become incredibly efficient.
But here’s what AI hasn’t touched:
- Making architectural decisions that will last for years
- Understanding complex business domains and their nuances (especially when “I need to talk to a human” still matters)
- Reviewing code for business logic correctness and unwritten organizational standards
- Designing systems that actually solve the right problems
- Bridging the gap between business needs and technical reality
The people I see thriving aren’t necessarily the ones who’ve mastered every AI tool. They’re the ones who’ve gotten really good at the human parts of engineering: understanding problems deeply, making thoughtful design decisions, and translating between domain experts and technology.
In short: we’re moving from being code writers to being problem translators and system architects.
Cutting Through the AI Hyperbole
The conversation around AI is often stuck at two extremes:
- “AI will replace all developers.” Code generation is improving fast, therefore software engineering is obsolete.
- “AI is just autocomplete.” Nothing’s changed, it’s business as usual.
Neither is true.
AI won’t replace software engineers, but it’s also not just fancy autocomplete. It’s a powerful tool. And like any tool, its value depends entirely on who’s using it and how.
The engineers who thrive are those who’ve invested in skills AI can’t replicate:
- Understanding business domains
- Architecting systems thoughtfully
- Translating between “what the business thinks it needs” and “what the technology should do”
That’s where Domain-Driven Design comes in.
Why Domain-Driven Design Is Your Superpower
AI is incredibly good at turning clear requirements into code. It’s terrible at figuring out what those requirements should be in the first place.
Vincent Quigley captured this well in a post I found enlightening: “First attempt will be 95% garbage.” AI confidently generates code that looks fine, but often misses the bigger picture. It has no memory between sessions, no real understanding of your business context, and no ability to learn from domain-specific mistakes.
That gap between what the business says they want, what they actually need, and what the technology should do about it - that’s where engineers add their real value. And that’s exactly what DDD is designed for.
Domain-Driven Design isn’t just about organizing code. It’s about becoming fluent in the language of the business domain you’re working in. It gives you the tools to:
- Ask the right questions when requirements are vague
- Spot the difference between stated wants and actual needs
- Design systems that evolve naturally with the business
- Communicate technical decisions in terms stakeholders understand
- Bridge the gap between domain experts and implementation details
- Provide the context that AI desperately needs to generate meaningful code
AI can help you implement domain models faster, generate tests, or refactor bounded contexts. But it can’t decide what those contexts should be. It can’t spot when generated code violates rules that live in tacit organizational knowledge.
The engineers succeeding in the AI era aren’t just code writers - they’re domain translators and AI orchestrators.
Same Game, Better Tools
All of this might sound like a revolution. In reality, it’s not new.
The best engineers have always been domain translators. They’ve always been the people who could understand complex business problems, break them down into manageable technical solutions, and communicate across the business-tech divide.
The fundamentals haven’t changed:
- Understanding users and their real problems
- Designing systems that can evolve with changing business needs
- Making architectural decisions that matter long-term
- Communicating technical concepts to non-technical stakeholders
- Bridging the gap between what people say they want and what they actually need
What has changed is:
- The speed at which we can implement once we know what to build
- The need to be explicit about domain context (because AI requires it spelled out)
- The importance of careful review and validation (because AI output isn’t inherently correct)
AI hasn’t rewritten the rules of great engineering. It’s just put a spotlight on them.
Closing Thought
That’s why I built domaindrivenjs - to make these ideas more accessible in the JavaScript/TypeScript world, where domain modeling often gets overlooked.
Because the future doesn’t belong to engineers who can just write code faster. It belongs to engineers who can think in domains, translate problems into systems, and use AI as a tool to amplify - not replace - those skills.