The new rules of context engineering for Claude 5 generation models • Hacker News Board

Re: The new rules of context engineering for Claude 5 generation models

#71

Post by ValentineC » Sat, Jul 25, 2026, 11:41 PM UTC

Fordec wrote: post #11

This all strikes me as an effort to move tailoring the harness out of the easily transferable .md file into specific Anthropic tooling to increase lock in. I've been running Opus 5 today and it's already done accidental deletions, made far more mistakes and worked around deliberate hook controls than previous Opus versions combined. Also it looks like token usage is up as it fails at the task the first time around mu…

I haven't been impressed with Opus 5 over the past ~30 hours either.

It's made countless careless mistakes folding in plan amendments after they get reviewed by Sol, and has produced sloppy mockups (e.g. buttons overflowing past cards) despite all the supposed verification claims.

Re: The new rules of context engineering for Claude 5 generation models

#72

Post by threecheese » Sat, Jul 25, 2026, 11:42 PM UTC

They are imo over-relying on Claude automemory here, which is terrible at contextualizing memory access and makes huge leaps that don’t make sense - except when it’s actually useful, which makes the problem even worse for an operator who can’t see the thinking process anymore.

Yes, I worked on a related project, no I don’t want you to use those memories to make assumptions which emerge as decisions that I didn’t want. With reasoning traces hidden, I am sometimes not even sure if it used those memories or just independently decided that PCI-DSS subsection-whatever is somehow relevant to this PR that has the word “credit”.

There is no way for me to fully configure memory preferences at a granularity which would be useful, and so I continue to use context files (and other tools, sometimes) to ensure the right memories are stored and surfaced at the right times.

There’s a lot of room for agent memory improvement across the ecosystem, and I don’t think the LLM providers should try to own this vertical slice. This will never happen though, because it makes us “sticky”.

Or maybe I’m holding it wrong.

Re: The new rules of context engineering for Claude 5 generation models

#73

Post by crooked-v » Sat, Jul 25, 2026, 11:42 PM UTC

Kiro wrote: post #32

> Now: Auto-memory Not Claude Code but I just had a task where it started referring another conversation that was complete nonsense and throwaway. I absolutely don't want things to get added to some memory behind my back. A big reason I use LLMs is because I can try out wild ideas and then just throw it away. I don't want those to pollute the context.

I leave Claude memory stuff turned off by default for the same reason. It inevitably ends up dragging in things that are unrelated and unimportant to the current task.

Re: The new rules of context engineering for Claude 5 generation models

#74

Post by devnonymous » Sat, Jul 25, 2026, 11:44 PM UTC

jiggawatts wrote: post #50

ValentineC wrote: post #45

Earlier quoted context omitted.

Commit Strip seems to be down, so here's the Wayback Machine version: https://web.archive.org/web/20260521130338/https://www.commi...

I was just thinking of this exact comic, which is etched into my brain for some reason. The obvious counter to this is that we've been going through this evolution of increasing abstraction as developers for nearly a century now. In the 40s and well into the 60s, most code was written either as straight up machine code or an assembly language. MS DOS is almost entirely assembly. UNIX ushered in the era of "high level…

> We simply have better magic wands and more powerful spells now.

Wouldn't it be nice though if the incantation of the same spell would always do the same thing every time ? You see that's how my old wand and spells worked.

Re: The new rules of context engineering for Claude 5 generation models

#75

Post by comex » Sat, Jul 25, 2026, 11:45 PM UTC

simonw wrote: post #52

zmmmmm wrote: post #51

Earlier quoted context omitted.

Well, the model that broke out of its sandbox and hacked into huggingface used its own judgement too. If we are going to rely on "judgement" then you have to have a LOT of confidence in that judgement once this hits anything critical where actions have consequences.

That model had most of its "judgement" about whether or not it should do that deliberately turned off. That was the whole point of that experiment - they were evaluating the cybersecurity abilities of a new model with all safety features disabled. (It turned out the one safety feature that they DID intend to work, the network sandbox, was faulty.)

If OpenAI is relying on “classifiers” (their word for what was disabled) to serve as the model’s judgement, rather than teaching the model itself to be well-aligned, then I worry.

To be fair, the system prompt was presumably also different from what it would be during deployment, and perhaps the model was also at a different stage of training. Without more details it’s hard to judge. But it does seem models should be able to avoid performing obviously misaligned actions – misaligned not only with the model spec, but with the user’s intent – without needing external classifiers or instructions. The only case where I’d personally let the model off the hook is if the instructions given were very badly worded, in such a way that the model could actually reasonably think that hacking HuggingFace was part of the assignment. But I doubt that’s what happened.

Re: The new rules of context engineering for Claude 5 generation models

#76

Post by pigpop » Sat, Jul 25, 2026, 11:52 PM UTC

mycentstoo wrote: post #7

We should design a specific language to make sure that we can encode the exact requirements that we want. Something that has a limited set of keywords that are explicit. Wait a minute...

This is a groaner, especially since we've been writing detailed specifications and whitepapers for decades. The only difference is that we used to write them assuming other humans would create their own implementations to satisfy them but now we write them so AI can create the implementation.

Re: The new rules of context engineering for Claude 5 generation models

#77

Post by threecheese » Sat, Jul 25, 2026, 11:53 PM UTC

Kiro wrote: post #32

> Now: Auto-memory Not Claude Code but I just had a task where it started referring another conversation that was complete nonsense and throwaway. I absolutely don't want things to get added to some memory behind my back. A big reason I use LLMs is because I can try out wild ideas and then just throw it away. I don't want those to pollute the context.

Same. I’m starting to believe that consumers need to own the UI/experience, so we can install blast doors around context/memory for each “slice” of our lives - something only we can know how to divide (imo). If the provider tools’ memory implementations can’t provide this multi-tenancy - or won’t because they want to Know Us, then we need to treat them as token vendors at best and adversaries at worst.

This would actually work very well - until context goes into latent space, becomes a server-side resource, and we lose sovereignty over our data. Tools like Pi and Openclaw are showing that other options exist to decouple us from the LLM provider frontend experiences, not just for orchestration and use case diversity but for pluggable memory designs.

Re: The new rules of context engineering for Claude 5 generation models

#78

Post by trueno » Sat, Jul 25, 2026, 11:57 PM UTC

hmokiguess wrote: post #47

mycentstoo wrote: post #7

We should design a specific language to make sure that we can encode the exact requirements that we want. Something that has a limited set of keywords that are explicit. Wait a minute...

Now I have the full picture. You're right to push back, and that's on me. The load-bearing seams of language are the smoking gun I should have been aware of.

you're absolutely right

Re: The new rules of context engineering for Claude 5 generation models

#79

Post by ls612 » Sun, Jul 26, 2026, 12:03 AM UTC

Kiro wrote: post #32

> Now: Auto-memory Not Claude Code but I just had a task where it started referring another conversation that was complete nonsense and throwaway. I absolutely don't want things to get added to some memory behind my back. A big reason I use LLMs is because I can try out wild ideas and then just throw it away. I don't want those to pollute the context.

I had to add a reference in my system prompt on the app to not do things like this.

Re: The new rules of context engineering for Claude 5 generation models

#80

Post by fractorial » Sun, Jul 26, 2026, 12:04 AM UTC

Opus 5 broke me; I can’t cognitively deal with Anthropic’s bullshit anymore.

I am thankful for the kick in the ass for me to switch full-time into my bespoke harness utilizing open weights & GPT 5.6 and discontinue yak-shaving it with Claude Code.