Live data from Hacker News

Memorizing session transcripts isn't useful

12gramsofcarbon.com

81–90 of 168 posts

Re: Memorizing session transcripts isn't useful

#81
post #48

Earlier quoted context omitted.

Oh god, I just realised this really is the logical parallel to all those TV crime dramas set in the early 1900s.

It’ll be the programmers version of those civil war reenactments.

Leet code competitions will be as relevant as sailing regattas.

Re: Memorizing session transcripts isn't useful

#82
post #21

Earlier quoted context omitted.

I am a freelancer recovering from severe burnout so the answer is a sort of irrelevant no. I'm trying to rebuild my life so I am in an experimenting and learning phase rather than a massive coding phase, and most of my code work is maintenance of things I have built. That which I do code, I am still coding by hand, though I am dealing with other people's Claude output and I am really unimpressed by it. It's often rat…

> That which I do code, I am still coding by hand, though I am dealing with other people's Claude output and I am really unimpressed by it. It's often rather crass. Unfortunately the point of code is rarely to impress people (certainly not other engineers) or to avoid being "crass." 99.99% of code exists to achieve business outcomes, and velocity matters a lot in many contexts. A lot more than elegance or impressiven…

I’ve worked at many companies where this idea of velocity was claimed to matter, and it never did. The only thing it mattered for was to make it look like middle managers were worth anything, but the success was always in the foundational idea/concept.

Re: Memorizing session transcripts isn't useful

#83

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?

I've wondered this. We have chain-of-thought, harnesses, etc. — workarounds of a sort due to lack of core model capabilities. But I am very curious if much better next token prediction would simply obsolete that whole setup or not. Either way, the answer would be very revealing.

Re: Memorizing session transcripts isn't useful

#84
post #76

Earlier 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"

Are you perhaps missing the true message of that aphorism?

Or are you saying the industry is (because it is)

Re: Memorizing session transcripts isn't useful

#85
post #29

Earlier quoted context omitted.

Especially a layer that is largely out of band in a project (i.e. ~/.claude/…). In any project where I’ve needed memory I just add a line to AGENTS.md telling it to use MEMORY.md to save memories or STATUS.md to track progress.

I've been enjoying having a little todo file the agent updates as it goes along, because then I can keep track of progress without scrolling through aeons of "Combobulating..." Also if context runs out you can just do "cat todo.md | agent" and you're off to the races again.

Yep all my projects start with a PLAN.md at the root, and that acts as the ‘save file’ recording our progress over time. My session always ends with updating the plan file with what’s been done, and the next session always begins, as you suggest, with consuming the current state of the plan doc.

Re: Memorizing session transcripts isn't useful

#87
post #68

Earlier quoted context omitted.

I have to ask: do you still write a lot of code yourself? I and most people I know do not.

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.

Re: Memorizing session transcripts isn't useful

#88
post #37

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…

> So I want to say there's still a lot of value in context engineering though it seems to diminish with each model release

I can't see how it would diminish unless you are literally working on public domain stuff. Unless stuffing context becomes cost effective and will not affect AI reasoning (this will be much harder), I don't see why context engineering is here to stay until we have close to AGI.

Re: Memorizing session transcripts isn't useful

#89

Earlier quoted context omitted.

> That which I do code, I am still coding by hand, though I am dealing with other people's Claude output and I am really unimpressed by it. It's often rather crass. Unfortunately the point of code is rarely to impress people (certainly not other engineers) or to avoid being "crass." 99.99% of code exists to achieve business outcomes, and velocity matters a lot in many contexts. A lot more than elegance or impressiven…

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 using subpar materials and the house will fall apart after a few years, but who cares right? At least you achieved the business outcome!

This mentality is so infuriating. This is why I need to buy new shoes every year. Or why my washer/dryer motherboard craps out in 2 years instead of 10. Nobody gives a shit about quality anymore, this is why society is crumbling around us. Profit driven incentive for fast/cheap over everything else. And now I need to spend my day prompting an AI to fix AI slop code to keep the business hobbling along another day. What a fucking joke.

Re: Memorizing session transcripts isn't useful

#90
post #76

Earlier 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"

"more good" seems like a pretty decent definition of better to me. The words you are looking for are "cheaper" and "faster"
Post reply on HN