131–140 of 168 posts
> Don't turn a one-off or area-specific comment into a durable memory without my explicit confirmation. You have a history of over-indexing on one-offs, and those memories end up getting cited to override well-tuned skills.
Blog posts like this just blow me away. > I believed this so strongly that my company built an entire product around this concept. I used to tell folks that "session transcripts were the new oil," that they were more valuable than the code itself. > […] > We don't really write code by hand anymore. Honestly, isn't this just influencer spam? What possible value is there in reading about people who used to have product…
>session transcripts were the new oil Something about this idea really resonates with certain personality types. I equate it to the Zettelkasten hype phase from several years ago. People (...like me..) got really wrapped up in the belief that the process was more important that the content. "Linking" was an "activity." Something good will happen as long as you (a) take notes on stuff and (b) link them to other notes…
Like ancient people? Because "new oil" whilst I get what it might imply sounds bad to me. Oil has been superseded in many places so "new oil" is like going backwards still.
Reference: data is the new oil is a term coined in 2006.
We're in 2026. See what I mean.
In a project my questions are usually revolved around the same topic. Having context carried across threads actually make a lot of sense.
In the general mode where I'm expecting models to be *stateless*, having memory is very annoying.
Earlier quoted context omitted.
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…
A) Context and prompting cuts the search space for next token generation. That’s pretty useful, as you mentioned. B) The other use of context is that it introduces entirely new information via RAG B will never go away (as others pointed out). A, well that’s just something we’re all going to keep getting surprised at. We’ll barely give it any direction or context and the newer models will simply find the happy path. T…
I agree with the take not to bother with a sophisticated memory system. Anything worth remembering should be in docs, guides, source comments, commit messages or tickets. You don't need another layer, every conceivable granularity is already covered by existing best practices
That is a sophisticated memory system though -- maybe not to you experienced humans!
Blog posts like this just blow me away. > I believed this so strongly that my company built an entire product around this concept. I used to tell folks that "session transcripts were the new oil," that they were more valuable than the code itself. > […] > We don't really write code by hand anymore. Honestly, isn't this just influencer spam? What possible value is there in reading about people who used to have product…
>session transcripts were the new oil Something about this idea really resonates with certain personality types. I equate it to the Zettelkasten hype phase from several years ago. People (...like me..) got really wrapped up in the belief that the process was more important that the content. "Linking" was an "activity." Something good will happen as long as you (a) take notes on stuff and (b) link them to other notes…
Earlier quoted context omitted.
It reminds me of the peak crypto days. Lots of resources consumed, many late nights, little to no value created.
I don't understand this line or reasoning. People use various cryptocurrencies to buy and sell legitimate products and services every day. Is the argument just that they could probably have done it some other way?
Earlier quoted context omitted.
The argument isn’t to not use better materials or techniques, it’s that inferior materials and techniques are fine because they don’t impact the end result, which is so obviously false when it comes to pretty much anything, but supposedly true when it comes to software.
I'm not sure who you saw arguing for inferior materials and techniques, but let me know when you find them. What you saw in this thread was someone arguing against the dimensions of "impressiveness" and "crassness" as valid things to care about when it comes to code. It's your mistake to assume that those are related to any meaningful concept of actual quality.
I clearly said elsewhere that I think they are predictive of problems with the person who writes it, and I fear I can generalise that to LLM tooling that generates it.
>We have found zero performance benefit on SWE tasks when agents have search access to their previous transcript sessions I refuse to believe this is true. The ability for an agent to find information from before a compaction is incredibly useful. At compaction time it's impossible to know what exactly may be still needed.
Earlier quoted context omitted.
I don't understand this line or reasoning. People use various cryptocurrencies to buy and sell legitimate products and services every day. Is the argument just that they could probably have done it some other way?
People do, but I personally don't know anyone who does. And I don't exactly live in a bubble, half of my friends were into crypto at one point or the other.
I do personally know people who pay for regular products with cryptocurrency. Including myself.