Complex Systems Are Uncontrollable
Complex (as compared to complicated) systems cannot be controlled.
Much of the dysfunction you find in organizations, and most of the problems you find in software development, come from the fact that people—engineers in particular—believe that complex systems (in the Cynefin sense) can be understood and controlled. They can not. You cannot predict how a complex system, be it organizational or software, will behave. Put another way, a metric-focused analytical approach to improvement or control does not work and never will work. Metrics are always weak indicators, too focused on a single aspect of the system as a whole, and actions taken on those metrics are always unpredictable at the system level. At best, you can observe the system and continuously adapt to the inevitable surprises.
There is a connection between complication and complexity, of course. Simpler complex systems are easier to manage than complicated ones. Good architecture _should_ move you towards simplicity. No architecture, however, resolves the inherent complexity of a large software or organizational system. The best it can do is reduce the complexity.
LLMs (and many of the people who use them) do not understand architecture. Consequently, LLM-based code generation usually results in overly complicated, hard-to-manage solutions. To my thinking, you cannot use an LLM effectively in a production environment unless you can review and refactor the generated code through an architectural lens that moves you towards simplicity. Being a "great coder" is not sufficient. You want to keep your job in an AI world? Learn software architecture.
First, I agree. I’d like share some observations from a few recent experiments.
What I’ve been finding extremely interesting lately is that the LLMs know many architectural concepts very well.
They may not apply them implicitly, but when explicitly directed to use them they ‘understand’ the pattern languages.
Two example experiments.
I recently used a LLM to build a simple application using Hexagon pattern. Because of this I was able to direct the LLM to change very particular parts of the code and leave the rest alone. Example, change adapter xxx.
Second experiment. What if I have a system with several hexagons? How do I grow the individual ones and simultaneously integrate them?
To the rescue DDD with its language for describing these sorts of issues: bounded contexts, aggregates, policies,domain and integration events.
What occurred to me in the process is that these patterns describe degrees of freedoms we want in our architecture and the desire to be able to tweak them independently.
This might seem like a stretch but this lead me down the path of reviewing the concept of entropy with its idea of degrees of freedom and the possible relationship to the single responsibility principle.
So yes, I think it helps to know architecture and yes these LLMs are an interesting development.