Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memorizing session transcripts isn't useful

12gramsofcarbon.com

Post reply on HN
Print view View original

141–150 of 168 posts

Re: Memorizing session transcripts isn't useful

#141

Post by cromka »

yoyohello13 wrote: post #89
slopinthebag wrote: post #72

Earlier quoted context omitted.

It doesn’t matter what materials or techniques you use to build a house. 99.99% of construction exists to achieve business outcomes, and velocity matters a lot more than using the right materials or techniques. Of course the house must pass safety inspections and stuff, but the materials and techniques don’t matter one bit for that. All that matters is you achieve the desired outcome, and I will ignore the glaring fa…

> Of course the house must pass safety inspections and stuff, but the materials and techniques don’t matter one bit for that. All that matters is you achieve the desired outcome, and I will ignore the glaring fact that you achieve the desired outcome by using the right materials and techniques. This analogy is more true than you think. This is why modern homes/appartments are trash. You can pass safety inspections us…

> This analogy is more true than you think. This is why modern homes/appartments are trash. You can pass safety inspections using subpar materials and the house will fall apart after a few years, but who cares right

Where do you live? Because where I live, new houses and apartments are superb. But I'm guessing we don't use two by fours and plaster walls to erect whole structures.

Re: Memorizing session transcripts isn't useful

#142

Post by dofm »

scosman wrote: post #131

The top of my ~/.claude/CLAUDE.md: > 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.

Does that second sentence provide value beyond getting that off your chest? ;-)

(Semi-serious question)

Re: Memorizing session transcripts isn't useful

#143

Post by sdesol »

prakharjain wrote: post #116
sdesol wrote: post #25

Earlier quoted context omitted.

> You don't need another layer I do think we need another layer, but it should be a routing layer. I am finalizing my pi-brains extension for Pi ( https://github.com/earendil-works/pi ) which does this: https://github.com/gitsense/pi-brains Right now "humans" need to define the routing rules for how to access information, but I will support what I call "knowledge agents" that can monitor conversations to inject conte…

It looks like an interesting experiment. But a hard problem since it needs to store useful information and be able to inject it at the right time. It will also need to not be redundant to the information already stored. What do you think is the potential value that you might get out of this, which is not already available with the existing options?

This is a hard problem, but one worth solving, I think, since it means less tokens and better AI reasoning. I believe LLMs are good enough that, if given the right context, it can very much solve almost all tasks.

If this works, it means we can probably get by with smaller models (since it doesn't need to know everything). LLMs are pattern matchers, and if you can provide them with the right shape (context), they should produce the expected output.

For my solution to work, you need business buy-in, which I don't think will be a problem. Enterprise wants to know how tokens are being spent, so I can see them wanting structured analysis during code reviews.

What may also not be obvious is that the information is ultimately designed to live with your code. Lessons and notes are designed to be mapped to files, so if you want to know why a piece of code is implemented in a certain way, you can have the LLM filter by files to help find the needle in the haystack.

It is a hard problem, but the only missing piece is discipline, which I believe business leaders will not have an issue with enforcing since we are ultimately talking about eliminating/significantly reducing the bus factor in our code.

If you look at https://github.com/gitsense/smart-ripgrep, you can get a better sense of how context can be injected when it is needed.

Re: Memorizing session transcripts isn't useful

#144

Post by irthomasthomas »

andai wrote: post #37
general_reveal wrote: post #5

Isn’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?

Yeah, the question is whether this applies to all of context management. I've been using a custom harness based on https://minimal-agent.com/ (itself based on swe-mini-agent), which is like 50 lines for the core logic. Bash is all you need. For small tasks, I find it's about 8x faster (and uses 8x fewer tokens) than the standard harness for each model. For bigger tasks I haven't tested it much. It seems to work too b…

In think in all cases where I've seen it compared CC performed worse than a minimal harness.

Re: Memorizing session transcripts isn't useful

#145

Post by jenniferhooley »

dofm wrote: post #110
jenniferhooley wrote: post #74

Earlier quoted context omitted.

Programmers can use smaller models like deepseek v4 flash for 98% of the same productivity as SOTA models and cost (true cost) around $10-$30 a month. So I doubt most people who heavily use them are too concerned. It's only vibe/hobby coders who really need SOTA and they probably don't think about it much.

To what extent does that ameliorate the problem? Are you not, by developing this way, making yourself more interchangeable, less indispensable, than ever before?

No. Anyone who doesn't code with AI - while retaining a deep knowledge and understanding of the problem domain - is falling behind.

I hate to say this tbh, I loved hand-writing code. I made a great living for 20 years, and I absolutely loved it and was quite good at it.

Hand-typing code is just slower now; there’s no two-ways about it. You are either going to be slow and a bad hire for businesses, or you figure out how to adopt AI into your workflow to speed up.

One thing I think people don't realize is that deep knowledge of programming, performance, architectural, and domain specific trade-offs makes a skilled engineer about 1000X faster than someone without those skills -with AI. But yes, now unskilled people can actually make apps/software. They just tend to be slow, and their products are full of bugs, security flaws, and abysmal performance.

So we went from: Skills = can or cannot ship any software at all. Now we are at: Skills = can ship better software much faster than unskilled people.

I was actually faced with this recently. I decided to learn Rust and port one of my side projects to it. Initially, I moved extremely slowly, and the AI made truly horrific architectural decisions because I didn't have the knowledge of how to direct it, especially compared to my primary languages.

However, once I gained a firm grasp of Rust, I was better able to properly direct the AI to fix fundamental issues and architect things properly. My speed increase multiplier proved to be directly proportional to my growing knowledge of both the language and the domain.

Skill and knowledge combined with AI, when used appropriately, absolutely multiply your speed and quality. I really think once you understand what AI can do, and how to utilize it to produce better code, faster than before, there truly is no going back.

I'm finding a path forward that I actually enjoy now and don't really see losing my value (no telling how things will change in the future), I can have more time to focus on really quality/solid/performant and useful systems with less time just typing one character out at a time.

You could have talked to me 3 months ago and I'd never imagine I'd say the above btw. I REALLY enjoyed code writing and earlier AI models without harnesses were pretty useless for anyone skilled at development. Now with stuff like deepseek Flash I feel like I have a happy medium of 100% directed/fast code turnaround, less typing, more deep focus on architecture, systems, and the actual end product.

Re: Memorizing session transcripts isn't useful

#146

Post by gopher_space »

techpression wrote: post #87
csomar wrote: post #68

Earlier quoted context omitted.

I am now in the process of fixing code I wrote using AI. I have come to the realization that AI can't really write software and I am annoyed that it took me that long (months) to realize that.

This is quite terrifying to me, because I have a feeling I will soon come to the same conclusion. I’m starting to see some really glaring omissions in code I’m responsible for (using Opus) that at first (and second) look seemed fine, but really isn’t.

From my perspective it felt like understanding that the machine has no desires helped refine my usage.

I can ask it to be curious, and it will reply with what people think curiosity should look like, but it’s a simulation of an emotion it will never be driven by.

The ramifications become apparent when you engage in activity like cross-domain discovery.

Re: Memorizing session transcripts isn't useful

#147

Post by irthomasthomas »

general_reveal wrote: post #129
theahura wrote: post #100

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…

>Chain of reasoning is a lot of context to guide token generation, but we simply see that newer models don’t need that context to get to the answer

I thought each new generation typically used more reasoning tokens?

Re: Memorizing session transcripts isn't useful

#148

Post by wrs »

My current technique, which seems to have improved maintainability, is to guide Claude to write commit messages specifically focused on "why this was done", "what changed in the theory of operation", and "what changed in the code". Then just reviewing the commits for a file or dir gives it a ton of useful context distilled from the sessions that produced them. Also, making a docs dir with concise .md files explaining the theory of operation and updating them with every commit.

Re: Memorizing session transcripts isn't useful

#149

Post by ErroneousBosh »

aranw wrote: post #12

t once had to tell claude 3-4 times to stop assuming the state of a system was the way it kept iterating it was cause it was in it's memory. I repeatably told it to otherwise and it just never updated it's memory and instead kept referencing it's memory about the state of a particular system

Yeah but you also know humans that do that too, right? I know I do.

Re: Memorizing session transcripts isn't useful

#150

Post by ErroneousBosh »

dofm wrote: post #9

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…

> inscrutable prediction machine

"Spicy Autocomplete", I've heard it called.

Post reply on HN