[flagged]
Memorizing session transcripts isn't useful
91–100 of 168 posts
Re: Memorizing session transcripts isn't useful
#92I'm not sure how well this take will age.
Its certainly true at the moment, but give it 10 years and we might have systems that are much cheaper and much better at context management than they are now.
(Apologies to anyone who is under the impression that we were very likely going to be at the singularity in 10 years time. Possible != very likely)
Re: Memorizing session transcripts isn't useful
#93Earlier quoted context omitted.
Of course? I'm still better than sonnet or opus, just slower and much more expensive. Sometimes it takes me a day or more to find the one line fix or abstraction necessary, while claude can hammer through a hundred line fix in under an hour.
Sounds like your definition of better is pretty narrow. Quick and cheap are two of the three fabled: "Fast, cheap, and good: choose two"
[deleted]
Re: Memorizing session transcripts isn't useful
#94I found that if you allow any low value things into memory, Claude will notice that established pattern and start trying to add low value memories at an ever increasing pace.
Explains why it made so many memories on my work machine, but never made one on my personal one. Maybe the project size also affects it.
Re: Memorizing session transcripts isn't useful
#95Earlier quoted context omitted.
Sounds like your definition of better is pretty narrow. Quick and cheap are two of the three fabled: "Fast, cheap, and good: choose two"
"more good" seems like a pretty decent definition of better to me. The words you are looking for are "cheaper" and "faster"
In coding we usually change it to "cheap, fast or correct: choose two"
I reject your correction: I present the options as nouns, not modifiers to the work. Maybe I should say "Cheap, Fast, or Good" as a compromise.
Re: Memorizing session transcripts isn't useful
#96Earlier quoted context omitted.
Of course? I'm still better than sonnet or opus, just slower and much more expensive. Sometimes it takes me a day or more to find the one line fix or abstraction necessary, while claude can hammer through a hundred line fix in under an hour.
Sounds like your definition of better is pretty narrow. Quick and cheap are two of the three fabled: "Fast, cheap, and good: choose two"
"good" can take lots of different meanings. Generally though, I want as little code as I can get away with. A majority of code lifecycle cost isn't in writing it.
Re: Memorizing session transcripts isn't useful
#97Thats interesting, but what was the methodology?
is the conclusion really that its just more important to create proper artifacts from any tricks that got the llm to understand the code better?
is the tool for searching the history just bad?
Re: Memorizing session transcripts isn't useful
#98I'm not sure how well this take will age. Its certainly true at the moment, but give it 10 years and we might have systems that are much cheaper and much better at context management than they are now. (Apologies to anyone who is under the impression that we were very likely going to be at the singularity in 10 years time. Possible != very likely)
Sure, but it’s equally likely that we hit a point where scaling becomes economically unviable because we can’t come up with enough algorithmic improvements to break free of the tyranny of log linear scaling. (I’m not sure how many 2x in token cost people would be willing to pay)
Re: Memorizing session transcripts isn't useful
#99Strong disagree on this.
I have Claude/Codex keep logs [1]. It's just prompted in my AGENTS.md [0].
> Every session must produce one of: a session log OR a plan, and end with a written summary appended to it. Default to a log; reserve plans for substantive design work.
It's incredibly valuable. For example today I started a few sessions off like this:
- What's the status of my work on Renovate?
- I was recently working on X, find that
- Did we fix the issue with backups? What are the next steps?
- This bug came up again. Didn't we fix it already?
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
Re: Memorizing session transcripts isn't useful
#100Isn’t this just a form of the bitter lesson? Our attempts to make engineered context and agents will simply be made obsolete with bigger and better models. Those transcripts are probably extremely useful for lesser capable models, and near unnecessary for frontier ones, maybe?
interesting take. I think I disagree, but I like this take a lot and I had to think about it.
First, I think that models still need a context layer. One way to think about 'context' is as a form of compression. You provide the model context because it makes it easier for the model to figure out what to do. Even in a world with infinite model capacity and infinite model context, this is still useful because it allows the model to avoid rederiving everything from first principles every time. As long as models perform better using fewer tokens and as long as we care about token spend, context is a useful (necessary?) shortcut.
Once you bite that you need some form of context layer, the question is which. Here I do agree that it is better to work with what the models will find familiar (markdown files colocated with code, for eg). But this speaks to over-engineered solutions not understanding their main user (the agent) more than it does the need or lack there of.