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 are able to review and refactor the generated code through an architectural lens. Being a "great coder" is not sufficient. You want to keep your job in an AI world? Learn software architecture.