Generative AI for Writing Code? And Designing Software, too?
Within a knowledge domain, there must be a final step in its evolution, so should it happen for software design
At the end of the day, software design is logic and logic, as a discipline, has reached definitive results.
A knowledge domain is a logic building that, like any other building, can grow up to a certain height, then falls due to the weight its height implies.
Software design is a knowledge domain, and so it behaves. Yet, nobody seems aware of its limits and final destination. The common understanding is that, like any other technological stuff, software design will evolve forever and improve. That’s simply unrealistic.
Writing code vs. prompting the generative AI to write code
The no-code movement, more and more relevant thanks to the generative AI, allows isolating a fact that was before too entangled with other facets to appear: writing code is not the crucial step in developing software. Machines are taking over it.
If drawing solutions is more and more automated, what matters is drawing the problem.
That’s a huge difference compared to the world before the generative AI. You can ask human developers to start writing code to deliver a solution for a blurred-defined problem. Human developers are aware that they don’t exactly know and understand what problem they are solving, but they start.
From the software design point of view, it makes no sense. From a commercial standpoint, perhaps. What’s wrong here is that developers are doing something related to the domain of the problem, but the problem is not defined enough to design what’s worth it. That’s inefficiency by design. That’s why it makes no sense.
Nowadays, when drawing solutions is increasingly automated, the point is that the generative AI cannot be aware that the problem – the prompt you submit – is blurred. For the generative AI, the prompt is always exact, regardless of its meaning: it takes everything literally.
So, to take advantage of the no-code world, the problem must be strictly defined by humans sensitive to the meaning, not only words.
It’s likely that software developers, at least the low to mid-level ones, lose their role soon. That’s something definitive. As cars made no longer convenient horses for many ranges of travel, the same is happening with generative AI against human software developers.
Domain-driven design (DDD) helps beyond who/what writes the code
Building a model is a matter of convenience. Overall, every model is wrong. Like a map that contains enough conventional information to travel from place A to place B, nothing more, a model is a set of concepts that help solve a problem. Nothing more.
Given a context, if a model is efficient in solving problem X, the same model can be highly inefficient – or ineffective at all – in solving problem Y within the same context.
Once you get that the value of the software consists in the problem it solves, it becomes clear that it’s not a matter of coding.
Sure, the software is made up of code, but who cares about who/what writes it as far as it works?
DDD is a meta-language to build models that some pieces of software can implement.
This article is not the right place to talk about DDD; I wrote some articles on this topic:
What’s relevant here is that DDD is the candidate to be the definitive approach in designing software, so that a definitive approach may exist.
Why is DDD definitive?
Problems and solutions.
Questions and answers.
Models and implementations.
Logic and code.
The left part of the list above it’s about deciding what’s valuable. Instead, the right part is delivering that value through an artifact.
DDD is definitive because it focuses on the distinction between the left and right parts of the list above. More, DDD roots in crafting the language to describe business domains, so it’s a meta-language: its high level of abstraction and proven effectiveness make it the definitive way of designing problems.
Try something different for the same purpose: you’ll reinvent DDD. That’s why it’s definitive. DDD has to to with crafting purposes.
Conclusion
It’s pivotal to distinguish between automation and autonomy.
Automation has existed since informatics was born: the word “informatics” itself contains the word “automatic.” From Wikipedia:
In 1956, the German informatician Karl Steinbuch and engineer Helmut Gröttrup coined the word Informatik when they developed the Informatik-Anlage[13] for the Quelle mail-order management, one of the earliest commercial applications of data processing. In April 1957, Steinbuch published a paper called Informatik: Automatische Informationsverarbeitung(“Informatics: Automatic Information Processing”).
Every kind of machine is automated, and we are used to it.
When you turn the key to switch your car on, you experience an automation we have been used to for more than a century.
Now, we start to experience telling a car to take us to a specific destination: that’s autonomy.
Software-wise, we are used to any automation: from generating snippet code to the release pipelines and so on.
Now, we start to tell a generative AI to write the code for specific purposes.
Yet, as it’s meaningless to ask a car the destination we want to reach, the same is valid for software. Even if possible, it’d be meaningless to ask a generative AI what problem we want to solve.
Humans must stay in charge of deciding what problems to solve, and DDD is the human language for crafting and modeling problems. It is a human language because it is based on meaning, not just on word usage statistics.
