One factor in architecture rot is compromising on development cost
Categories:
Characteristics of rotten architecture include: lots of special-case handling, compatibility handling, severe coupling, and being too burdened to reform. All architectures gradually rot. A rotten architecture makes it hard to develop new features, fix bugs, and a small change affects everything, making testing and QA very difficult as well. I once saw a cross-industry development enthusiast post that restricting the abstraction behavior of models when writing code makes the code easier to understand. Code that is easier for humans to understand is also easier for LLMs to understand, enabling rapid development and fewer errors. I think cross-industry developers probably work on smaller projects and are used to pipeline-style logic. If there is an expectation of scaling up, the mindset cannot be limited to pipelines but should adopt a construction-worker mindset. Expecting to build a 30-story building means digging a 10-meter foundation; expecting water and electricity means reserving water and electrical shafts. This is goal-clear design. There is also goal-unclear design, such as reserving a socket somewhere in the house for a future appliance without knowing what it will be. Software engineering already has the SOLID principles to guide design. Often on the surface, following SOLID means crossing more files and writing more code to implement the same feature. In the short term, designed and non-designed code look almost identical to the boss, testers, and users; the benefits of design only show in the long run. A good architecture makes it easy to add features, change features, fix bugs, and introduces fewer problems. Designing often requires more thinking than just diving into feature development. Design requires considering granularity; directly tiling socket panels all over the house like ceramic tiles is another absurd approach. In the past, when considering development cycles, I would make trade-offs—when time was tight, I would skip design entirely and just add a few functions, leaving future issues for later. Now with AI, we can make the design granularity finer; the generated code is harder for humans to read, but the project is easier to maintain. With more abstraction, weaker models may indeed handle it poorly, so it is best to use the currently best model. If you are just writing scripts, the capability differences between models may not be very obvious. Regarding whether AI lowers the barrier to entry for developers? I am skeptical, because the learning path for new developers is already completely different from the past, so discussing whether the barrier is higher or lower may be meaningless—we do not know where the barrier has been moved to.
