Same. Everybody builds one, and then eventually realizes it makes the model stupid and confused. The right solution is pretty much always developer documentation in the repo, in roughly the same shape you'd make developer docs for humans that you want to be able to get up to speed about your codebase really quickly.

This has the benefit of being something you can easily read over every now and then to make sure the model hasn't baked in some random comment you made about a specific circumstance a month ago and made a weird religion out of it.

Also introduces massive confirmation bias. Majorly gimps the model. I remember I was exploring hexagonal architecture on chatgpt and then future conversations with open ended architecture questions just gave me those same patterns.

“Oh damn look its recommending something that looks like hexagonal architecture. I guess hexagonal is a really good - hey wait a second …”

Agreed. Claude Code often tries to write one-off decisions and transient problems into memory. And when such things appear in the context, Claude will start doing questionable actions, because it saw something unrelated and wrong somewhere in its context

I strongly agree. This is becoming a general principle along the lines of “code comments that describe what the code does are bad.”

Memory just ensures there is a fairly high level of drift and inaccuracy in your context. Unless YOU are manually curating it.

Its similar to wiki systems where your agent produces tons of documentation and decision records, etc. Its a bunch of assertions about your codebase that you aren’t vetting and which is at most 90% correct. Thats good enough for a feature or bug fix that you can validate with tests but for the love of god throw the details away. You don’t want to codify that. It’s polluting the context and gimping the model.