logoalt Hacker News

nzachtoday at 2:13 PM1 replyview on HN

I'm starting to think that 'memory' may be the wrong analogy for what we want.

I do think that having a set of token that are highly personalized to your project and to way you work is beneficial. I also think that the idea that this set of token will be constructed in the background without any work from the user is really appealing. So it's understandable that the 'memory' analogy became so popular.

But in my experience having a really good AGENTS.md file almost always produce better results than enabling memory.

Maybe we should start to think about how we 'train'/'onboard' agents into our projects, in a similar way that we do for new co-workers. Imagine if we could send the agent to our repo and ask it to learn our patterns and in the end we could quiz the agent to gauge how much it actually understood the project. Once he 'understands' the project we can start to use it to help with development.

In a very small scale (example, individual new features) I will sometimes ask the agent to explain me how things work (even though I already know how it works) so I can 'prime' the agent context with good data before starting any real work. But I'm not sure if this approach could be reliably scaled to work with any repo for any kind of work.


Replies

DanielHBtoday at 2:20 PM

When I was doing a really large refactor across the codebase I told Claude Code to explain how certain things worked currently and how I wanted things to look like after the migration and a plan on how to get there. Then I did several further clean sessions where I always started along the lines: "Using this plan {link} do X."

Works pretty well for "non-permanent" instructions (you don't want to put this info into your committed markdowns).

My main motivation was simply to save tokens, but it actually worked really well and improved speed as well.