RE:CZ

Reflections on AI Programming Practice: Avoiding OOP and Over-Compatibility

AI Software Engineering

👤 Software developers, AI technology enthusiasts, programming beginners, engineers concerned with code quality and maintainability
This article documents the author's failed experience with AI programming (Vibe Coding), finding that AI-generated object-oriented code is of poor quality and structurally messy, leading to technical debt explosion. The author analyzes reasons including AI's insufficient design capability for OOP paradigms, lack of architectural guidance, and excessive backward compatibility. Key recommendations are proposed: avoid using object-oriented programming and shift to procedural and functional programming; guide AI to understand Occam's Razor principle to reduce code bloat. These measures aim to enhance the quality and maintainability of AI-generated code.
  • ✨ AI-generated object-oriented code is of poor quality, structurally messy, leading to technical debt explosion
  • ✨ AI has insufficient design capability for OOP paradigms and lacks business domain modeling
  • ✨ AI lacks architectural guidance, adopts lazy strategies, resulting in bloated code
  • ✨ Excessive backward compatibility increases code complexity and maintenance costs
  • ✨ Recommend avoiding OOP and shifting to procedural and functional programming
📅 2026-01-07 · 693 words · ~4 min read
  • AI Programming
  • Object-Oriented Programming
  • Functional Programming
  • Code Quality
  • Technical Debt
  • Occam's Razor
  • Backward Compatibility

Today is 2026-01-07.

A major failure using Vibe Coding—the code quality written by the AI was too poor to be usable. I had no choice but to completely rewrite the ZEN project, switching to traditional, old-school programming methods to implement it.

I used AI to generate code from scratch. After multiple iterations, the engineering quality began to collapse. New features couldn't be integrated, bugs emerged endlessly, the code structure became chaotic, and even deleting functionality became exceptionally difficult. These are classic symptoms of exploding technical debt. Consequently, I decisively intervened and decided to rewrite the entire project. A key issue I identified was that the OOP code written by the AI was particularly poor in quality. For every new feature, it would simply create a separate class and then punch a hole in other related classes to call it, resulting in a large number of useless classes and methods. This isn't object-oriented programming; it's more like requirement-checklist-oriented programming.

The reasons, I believe, are as follows:

  1. AI's design capability for the object-oriented programming paradigm is insufficient, likely due to a lack of modeling of business domain concepts.
  2. AI doesn't distinguish between writing one-off code and code for long-term maintenance. It lacks architectural guidance and resorts to a lazy, "hack it together" strategy.
  3. There is a lack of an AI-friendly scaffolding, making the bootstrapping process from scratch quite challenging for the AI.
  4. AI is overly conservative in its handling of compatibility requirements, leading to bloated code.

The Object-Oriented Myth

I believe AI is currently not well-suited for writing object-oriented programming code. Object-oriented programming requires a deep understanding and modeling capability of the business domain, which AI currently cannot handle. Ironically, even humans often struggle with this. In contrast, procedural and functional programming are more suitable for AI because they focus more on data transformation and processing rather than the state and behavior of objects.

If you use object-oriented programming, you need the AI to be proficient in design patterns and refactoring to produce high-quality OOP code. However, with procedural and functional programming, the AI only needs to focus on algorithms and data structures to write decent code.

So, what are the benefits of object-oriented programming? Encapsulation? Inheritance? Polymorphism? In the age of AI, these seem less critical because they were born from the need to write less code and facilitate team collaboration—concerns that are irrelevant to AI. Instead, code readability, maintainability, and testability are key. These qualities are more easily achieved through functional and procedural programming.

Excessive Backward Compatibility

AI is overly conservative about backward compatibility, resulting in bloated code. AI always tries to preserve all old features and interfaces to avoid breaking existing code. However, this approach often backfires because it increases code complexity and maintenance costs. Sometimes, removing old features and interfaces can simplify the code and improve performance. But AI struggles to make such trade-offs because it lacks an understanding of business requirements and user behavior.

If AI treats all public exports as must-keep artifacts, it introduces these interfaces casually when creating new features but later treats these garbage interfaces like treasures during maintenance, afraid to delete them. The result is increasingly bloated code, rising complexity, and more bugs.

After I tried guiding the AI to adopt a "allow breaking changes" strategy, the situation improved significantly. This indicates we've pinpointed the problem. However, it also raises a new issue: how to manage the risks associated with breaking changes?

We must make AI understand Occam's Razor: "Entities should not be multiplied without necessity." In other words, code should be as simple as possible, avoiding unnecessary complexity and redundancy. New features and interfaces should only be introduced when truly necessary. This is the only way to maintain clear and maintainable code.

If AI doesn't separate design and coding tasks, achieving this becomes very difficult.

Conclusion

  1. Emphasize avoiding OOP and shift towards procedural and functional programming. This is a crucial shortcut that can significantly improve the quality and maintainability of code generated by AI.
  2. Guide AI to understand Occam's Razor, avoid excessive backward compatibility, and reduce code bloat.

I haven't yet figured out solutions for other issues, such as the scaffolding problem and architectural guidance.

See Also

Referenced By