Years ago, Martin Fowler wrote an excellent article about the anemic object anti-pattern here: https://martinfowler.com/bliki/AnemicDomainModel.html Assuming you agree with his perspective (let’s not debate his article, OK?)… it is obvious that AI follows this anti-pattern almost exclusively, and it’s quite difficult to control with CLAUDE.md or other instructions. Instead of creating code which does this: Object1 and Object2 have all the business logic All UI implementations use Object1 and Object2 to manipulate model data, and focus exclusively on display and user interaction You end up with this: Object1 and Object2 are little more than structures with no behavior. UI implementation A has all the business logic embedded needed to do what the uesr wants UI implementation B has additional, or different business logic, often duplicated or redundant UI Implementation C duplicates or reinvents business logic that is also present in A and B. This creates tremendous technical debt over time. Because the business logic is scattered shotgun-style all over the various UI implementations, future implementations of new features cannot rely upon reusable code and often must copy/paste or create variations of existing business logic. It also means that the business logic is not private to Object1 and Object2 but exposed such that everyone who works in the system must understand the internals of those objects. Letting Claude code a feature based upon a spec I write. I do not dictate archtectural principles. Though I do include architectural objectives in Claude.md (“Objects have behavior, do not create anemic models”), Claude usually ignores that advice and follows the anti-pattern. I get the feature working. Then I always have an architectural refactor session. This is always necessary on new code, but seldom needed for bug fixes and enhancements to code. But, it’s tedious. I’m curious how people deal with this problem. Any thoughts? submitted by /u/garywiz
Originally posted by u/garywiz on r/ClaudeCode
