It is not possible to deny that a massive shift has happened. It's hard to say the exact percentage of code that is now generated by LLMs. But what is obvious - this number rapidly grows. A lot of people are questioning the role of a software engineer and whether such a profession will exist in a couple of years.
However, LLMs are not working autonomously. They need someone to orchestrate them, providing a specification and validating an outcome. The more precise the specification is, the better the result you can expect. Basically, this rule applies to any development process.
Moreover, an LLM produces much more suitable code when given an example. The example could be a short code snippet, but it would be much better if it followed the project's codebase style and approaches.
Finally, the generated code should be reviewed and tested carefully.
Evolution of Communication
Language is a way to communicate with other people. And sometimes it is not an easy task. It happens to be quite difficult to express thoughts or to understand other people's ideas. Language allows one to express something in an endless number of different ways. Speaking is not deterministic, but humans handle that complexity in most cases.
Computers, on the other hand, understand only 0 and 1. The problem is - people don't.
Programming languages were designed to fill this communication gap. They have strict rules for expressing what needs to be done so it can be clearly translated into what the computer understands. The program will do exactly what you tell it to do via programming language.
But what happened recently is that we can now communicate with coding agents in any language, and the agent translates it to the programming language of our choice. And here comes a problem - speaking is too ambiguous. And if the code base is also too ambiguous, no agent will be able to generate proper and reliable code that fits your needs, especially business logic.
You tell it to make a change to tenant management, but there are places in code where it is called client.
You tell it to add some functionality for a buyer, but it is also called a consumer, purchaser, and, again, client.
You tell it to add a new entity - client, because this is how it was called in meetings, but there are already plenty of things named as client in the code.
And each time you have to explain what is what, and you may still miss some tiny detail.
Of course, the good-to-go approach is to tell the agent to collect knowledge about the domain. But it is hard to aggregate the domain knowledge if the domain is not clearly defined.
Meet your new colleague
In addition to overcoming difficulties in communication between teams, you now need to overcome difficulties in communication with AI Agents. To reduce the number of hallucinations, you need to provide it with clear instructions and a summary of project knowledge so it can rely on them instead of repeating the same research every time. You need to be precise with terminology and in describing the results you want to achieve. It is very similar to onboarding a new colleague to the project.
What is Domain-Driven Design?
Domain-Driven Design - is a concept of having code base that reflects the business logic. It unites two worlds - technical and product commands, so they can understand each other better and work together more efficiently. I often see that Domain-Driven Design is defined as a set of patterns. However, patterns are only tools to achieve the final goal, and it is not mandatory to follow all of them.
From an engineering perspective, use cases reflect what's going on in real life, and the code becomes more than just a set of random get/set calls. Why is it a good thing? Any request for a change to business logic can be easily translated into an existing code base. The question, "How does this feature work?", does not require a week of investigation. Of course, real life is much more complicated, and such a state cannot be reached from the decision to apply DDD to the project from day one. It is the process of evolution to become business-centric, not framework-centric or infrastructure-centric. It requires hard work, with both engineering and product teams involved, to define and shape the domain.
Is it still relevant?
So, what advantages does Domain-driven design provide for AI-first development?
- Writing in DDD-style makes code more readable -> review process will become easier and faster;
- The domain layer literally repeats domain logic -> easy to notice if some use case is missing or doesn't do what is expected because the logic isn't scattered throughout the project;
- Domain-centric code is easy to cover with unit tests that check domain logic, not just getters and setters -> code becomes easier to maintain and extend; easy to notice that something is broken;
- Ubiquitous language makes the communication easier not only with humans, but also with LLMs -> less confusion means less hallucinations;
- Bounded contexts could force making smaller changes -> change will be applied to a context, not affecting the whole project with unpredictable consequences;
Domain-driven Design solves the same problem as before - decreases ambiguity and brings clarity to the development process, but now with the new party involved. Product and engineering teams, along with AI-agents, share the same knowledge.
Would I still apply DDD to a project? Definitely.
It may seem like such concepts are now outdated. Why bother with such things when an AI agent can write code for us, fix bugs, and answer questions about the product? But all of these rely on an input context. When the input becomes messy, the quality of the outcome drops drastically. Same as with simple old manual engineering - you must keep the bar high to maintain high-quality results.
The article cover is a fragment of Oleksandr Bohomazov's artwork "Sawyers".
Top comments (1)
the point about ubiquitous language hitting differently in the AI context really resonates. I've noticed that when a codebase has inconsistent naming across bounded contexts, prompting an agent to make a change ends up requiring a lot of extra clarification. half the prompt ends up being "when I say X I mean this, not that other thing called X over in the payment module." DDD-style clarity reduces that overhead significantly. one thing I'd add: explicit aggregate boundaries also help agents scope changes correctly. without them, an agent making a "small" change to one context often reaches across into unrelated areas with unintended side effects.