Live data from Hacker News

The new rules of context engineering for Claude 5 generation models

claude.com

41–50 of 434 posts

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

#41
post #30
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’m not excited about using Opus 5, mainly because the way that I work atm — essentially peer programming — means I sandbox the agents and work with them closely. Opus 4.x encounters the sandbox and moves on with its day; Fable becomes increasingly fixated on it and does less and less of the actual task, focussing more and more on the limit it reached. I worry that, from your description, Opus 5 will do the same.

It does feel a bit smarter, but it seems to be also "too clever by half" and its not ignoring the rules, it's rejecting them and finding work arounds. It sticks to the word of the law, while rebelling against the spirit of the law.

One example is to get around a git --checkout usage ban, it CD'd to another folder first and back to bypass the regex in the hook.

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

#42
post #28

Earlier quoted context omitted.

I disagree. I speak in code to the LLMs. It's just that LLMs are really good at reinventing the wheel that you were supposed to in your codebase. Recent example. struct TensorView { body: Arc , shape: [usize], stride: [usize], offset: usize, } Okay now fill in all the helper methods. And GPT 5.6 Sol did a good job.

With that kind of workflow, you might be faster with AI autocomplete :)

Yep! I do use Codex CLI

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

#43
post #31

crazy to me that this starts with "I've written previously" yet continues the zero human attribution (that i could find?) trend in frontier model blog posts

The author is mentioned at the bottom of the article:

“This article was written by Thariq Shihipar, member of technical staff, Anthropic.”

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

#45

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...

Commit Strip seems to be down, so here's the Wayback Machine version:

https://web.archive.org/web/20260521130338/https://www.commi...

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

#46
post #22

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...

The success of LLM's (by usage) tells us that programming languages are still too close to the machine than the actual problem domain as defined by humans. If we truly had the right abstractions, no one would care to use LLM's for programming.

I think there’s a kind of laundering that goes on. Like if leadership just told devs to go build something (gave them a prompt) and the devs picked some defaults, leadership wouldn’t like it, they’d want some different interpretation of the prompt, there’d be lots of back and forth.

Somehow when it’s the LLM that makes the choices, everyone is impressed with what AI did. It’s really just whatever defaults have been trained in, but somehow we’re ok with this.

Part of it is better marketing and communication. Basically the defaults of OpenAI and Anthropic are better than what a random dev will pick. But it’s not really that natural language is a better interface, it’s more that having “AI” for now somehow intermediates responsibility so everyone is ok with what it picked, when they probably wouldn’t accept the same if the internal team came up with it. It’s not too different from hiring consultants.

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

#47

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.

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

#48

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.

Fair...

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

#49
post #36

Is there a specific list of changes they made to the system prompt? They're claiming they removed 80% of it. That's quite substantial. It would be good to know what the model knows to do by training and what we need to avoid over-specifying in our system prompts. Saying that "give Claude judgment" is too vague for agent implementors. Given the lack of specific details, my takeaway is that we need to go and review all…

It definitely makes me uneasy given the types of behaviours we've been hearing about from these models. Letting them use their judgement can go horribly wrong once a misaligned behaviour is triggered. It loosely translates into a relaxation of guardrails.

I worry that the ability of the model to reach similar benchmark scores to Fable is more to do with this "letting the agent off the hook", allowing it to explore a wider (but riskier) set of avenues to solve the problem than it is due to it getting genuinely better at the direct problem solving.

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

#50

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...

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" portable languages like C, Fortran, and Pascal that some developers hated because they felt like they were losing the fine-grained control that they had with assembly. The compilers just "weren't as good" as humans at optimisation!

Then the compilers got better and people started using garbage-collected languages like Perl, Python, Java, JavaScript, and C#. Similarly, many people bemoaned the lack of control over memory allocation, lower efficiency, etc.

We're simply stepping up to the next level of abstraction.

Look at it this way: decades ago when I first discovered C++ templates, it felt like waving a magic wand in the direction of the computer. It blew my mind that I could simply substitute "float" instead of "double" in between some angle brackets and the compiler would write reams of code for me!

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

Post reply on HN