It is February 3, 2026, 9:00 AM.
I had Opus 4.5 repay some technical debt for the experimental repository of Capital's Long War, even though this technical debt was also created by it in the first place.
As I mentioned in my previous article, Reflections on AI Programming Practices: Avoiding OOP and Over-Compatibility, AI is currently not well-suited for writing object-oriented programming (OOP) code. Object-oriented programming requires a deep understanding and modeling capability of the business domain, which AI is currently unable to handle. Currently, even the SOTA model Opus 4.5 is no exception.
AI can repay technical debt through specific processes. This truly embodies the saying, "Every debt has its debtor"—at least I don't have to pay for the poor code it writes.
Let me emphasize the issues with OOP and over-compatibility once again.
At its core, programming involves modeling the world, which is a cognitive science problem. Most programming tasks require dealing with many unique business problems. This is especially true for experimental code, where the task itself often demands innovation. As a result, AI sometimes struggles to understand a new concept suddenly introduced by the user, leading to incorrect modeling and flawed code. For the few tasks that have already been thoroughly understood, there are usually well-modeled, high-quality codebases available... so why reinvent the wheel?
Over-compatibility essentially stems from AI's inability to determine whether certain code is still useful, making it hesitant to delete it. This leads to bloated, hard-to-maintain code. In object-oriented programming, states and methods, even if unused, may be retained because they are deemed potentially useful. The impact of this is similar to OOM (Out-Of-Memory), but while OOM causes process crashes, over-compatibility leads to cognitive collapse. This is a hidden pitfall.
Cognitive development is a spiral process of advancement. Whether for AI or humans, progress cannot be achieved overnight. How to maintain functionality and manage debt during this spiral process is an important topic. Interestingly, code—or experiments themselves—can help us gain insights, and these insights, in turn, help us write better code.
I am recording these reflections for future reference. It is a wonderful experience to jot down my thoughts while waiting for Opus to do its work.
