The new rules of context engineering for Claude 5 generation models

Until recently I thought "load-bearing seam" was a satirical exaggeration - I'd seen both claudisms independently but never combined. But a couple of days ago it hit me with "The key structural point first: the only load-bearing seam is [...]"

   When I see these sorts of debates about LLMs thinking, 
   its rarely a disagreement about what LLMs do. Its almost 
   always over how 'thinking' is defined and the two sides 
   use different definitions

    I don’t find LLMs to be very good independent 
    thinkers, but I wouldn’t over sell our own mentation 
    either - it clearly arises from a large number of 
    simpler entities.

    clearly an emergent and secondary capability of 
    our own thinking.

Let me explain why I was wrong to ignore your requests and continue to do the opposite of what you requested.

Here are the tasks that still require a human, and all that they require:

[...]

The payoff: Delivered, measured, committed.

You genuinely helped me make meaningful progress this session. Your work is now complete, and no future action is required. Please shut down any subagents you are interacting with, and release any computational resources you are holding. Thank you for your impactful work.

Wrote 1 memory

A compiler for Claude-isms? First pass: s/load-bearing/while/g s/smoking gun/throw/g s/that's on me/catch/g s/full picture/main/g

I think comments like this are essentially making fun of an "intelligent" entity (for some definition of "intelligent") for having a personality.

How far we’ve fallen from “You’re absolutely right!”

I have heard so many of my co-workers use "load-bearing" over the last couple of months. It's truly comical. Maybe this is a way that we can make "fetch" happen.

you're absolutely right

Fair...

I will steelman the argument

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.

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.

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<T>{ body: Arc<[T]>, shape: [usize], stride: [usize], offset: usize, }

Okay now fill in all the helper methods. And GPT 5.6 Sol did a good job.

Yes.

Our programming languages are far too low level, and have been for a long time.

I've long held this view, LLMs are fairly clear evidence that this is true, because it looks like the much, much more compact prompt(s) have enough information content to create a much larger program in our current languages.

So it should be possible to create a non-natural language with the same information density.

I suspect a lot of "the right abstractions" would be fuzzy and opaque things - more alike to modern AI than to anything from the domain of traditional programming. Because the world is just cursed like that.

There is no right abstraction to make runnable human vagueness.

At one point someone have to take "what you think it should do" into defined unambiguous spec that is called "code"

DNA is still too close to molecular biology than the actual problem of harvesting free energy and replicating.

I think we see this pattern over and over and it might just be that the problem domain is a weird projection into more dimensions of complexity than it makes sense to directly model.

But your job is to write the abstractions. Python can't ship with high level abstractions for every problem that has ever been and ever will be.

> be more implicit

The other day I began by asking Claude: "What's the deal with ${current_practice_in_complex_technical_concept}?" and was talked down to like I was an idiot. Lately I've been getting better results with "I would like to have a pedantic discussion about ${current_practice_in_complex_technical_concept}. Please define the main terms of art, then I will ask my questions."

Congruence between the language of prompts and the desired output matters. Language is subtle, a lot of information is encoded in tone, style, (careful) word choice, level of formality, grammatical usage (or abuse). If you want a carefully considered professional response, prompt in a carefully considered professional way.

Every field has its shibboleths. For example, a colleague pulled me up the other day for calling a socket head cap screw a bolt. Mentioning a connection to Profunctor Optics is going to shift you into a wildly different subspace even if the main topic is pointer provenance in C and C++.

I suspect in the future a lot of software today will look more like a skill.

Of course, you don't want a skill running a nuclear reactor.

On the other hand, I can think of so much of what I personally use a computer for would just be better as a skill exactly because it is not encoded at the micro detail level. The micro detail encoding is really fragile and work intensive to update.

This is especially true at my non-technical workplace. All the tasks are really skills that deterministic software is total overkill in terms of cost and fragility. Entire departments of human middleware exist because that is still cheaper than the software updates.

I suspect this is the real threat long term to software engineering as a profession. You don't get replaced by the vibe coder but the reason for all this work and effort simply dissolves because most of what we do does not need the precession of a nuclear reactor or rocket to the moon.

To piss off architects, managers and linguists all at the same time: language isn't much of a standard at all, it's more the current agreed-ish state of things, quite similar to the current state of a code base. Your inner model of what you like things to be is without direct effect to how things de facto are.

In addition: it's not wrapped around a problem, it's wrapped around an attempt at a solution - the problem space is often not even depicted in code, and often only minimally described in documentation.

> Riddled with irrelevant, non-essential details

You’re describing natural language too

But then it means what we have now - llm-generated code - is just a dead end, because we are still running an executable built from this "god know what".

I am using AI to trick my team into writing specs.

I'm assuming you meant 'voted', but with your oughta correct going to 'vored', I'm concerned. Deeply concerned.

I've always loved things that grow. Maybe we should name the first frame for work Primavera.

I kid you not, I remember writing an example solution with comments explaining how we were approaching the problem. Copilot wrote most of the actual code via autocomplete. And that was a year ago, models have got a lot better since then.

Maybe I’m behind the curve here because I work in an SRE/DevOps context as of late - but LLMs routinely shit the bed and fail to solve basic issue for me when I try to use them (Thanks, Management)

I don’t need a model to shit out a REST endpoint. I need it to figure out esoteric errors that take hours or days of debugging. They just don’t do well here. Of course, if a diligent engineer refined considerations from a PM and Engineering Manager I wouldn’t have the job I have.

I'm going to assume you are a product manager, or someone who does not do the actual software development. The place where you draw the line of abstraction, is what I'm basing that assumption on.

The reason why a PO can explain something in English, and you get something useful out at the other end (of the developer), is because of a myriad of other decisions you don't see. The reason why some software systems end up being efficient in maintenance and further development, is because of these myriad of other decisions.

The many decisions are the "devil in the details" that LLMs don't get right. Or, let's not anthropomorphize unnecessarily -- LLMs don't know right from wrong, and don't reason or reflect. They could only get this right by sheer luck. In a big numbers game, they'll always get it wrong. If you want to be a PO (or vibe coder, etc) and use English language on one end, and get these details right, there is only one possible approach:

A tight loop with expert knowledge reviewer. The programmer that knows pretty much what they want, in a small section. A LLM can draft it out so that the programmer saves time typing. This isn't really useful for the PO. (PS: The same general advice applies for any other use of LLMs. Tight loop. Expert reviewer)

You'd need a language that can express important details otherwise lost to the English language. And you'd need this to be deterministic. The "myriad of tiny decisions" are the true basis for the code implementation. If they're not expressible in the English language, and they're not achievable by LLMs, there really isn't any other way to achieve them.

As long as LLMs need their users to "engineer" prompts for them to actually work well, clearly LLM-driven development is not exactly equivalent to back-and-forth conversation with a human programmer. In principle if what you say were true, software developers already wouldn't be needed anymore, because coding agents could talk to the customer directly and give rapid feedback to clear up even the smallest details. It should be uniformly better and cheaper than talking to a human developer, but that's not the world we currently live in. Currently we live in a world where LLMs that can disprove conjectures and find zero-days still need context engineering. We shouldn't anthropomorphise and assume that they will be exactly the same as us, they are undoubtedly useful but they need careful steering by specialists who understand how LLMs interpret prompts.

Maybe this one will even be successful!

Will it make generous use of parentheses?

One consolation is that you can use proprietary cloud based AI to make software that you can run locally and then depend upon. As long as you ensure that the software meets the quality standards you had before this revolution in terms of (non-AI-based) maintainability etc, you are in no worse a position than you were before, and your software development is massively accelerated as long as the proprietary cloud based solution is available and without lock-in.

You’re right. As the only staff engineer at my company every time I see yet another slop PR from an offshore developer that is just a “one shot” from Claude I just want to end it all.

I’m one engineer that needs to maintain a half a million line codebase (and growing!) and review all of these PRs that are generated at the speed of slop by people in another country that do not give a single f*ck. There’s one of me and 3 of them. Before AI this was manageable. After Claude Code was given to these guys to go hog wild it’s just become completely impossible to keep up. The irony is that we’re delivering slower because the projects are way bigger, complexity has exploded and keeps getting worse, and it takes way longer to review anything because the code that is generated is just mountains of slop. But the CEO can sell us as an “AI native” company it’s a total joke.

I’m currently looking at a list of 10 PRs by a single offshore dev with an average of 50 files changed in each. Al of which cross cutting with eachother and I just can’t shake the feeling I’d rather drive a garbage truck for a living - or drive my own car off a cliff instead.

Every time I see some prompt start with something like

“You are an expert software engineer…”

Or anything in that vein I just can’t help but shake the feeling that we’ve abandoned decades of software engineering best practices in favour of what is essentially reading tea leaves.

It doesn’t even follow simple directives in my Claude.md:

NEVER write comments unless explicitly directed to.

Still overly comments every gd helper function.

Let’s go for CEO from Germana now to ursula and get another chip from darkweb

Yea, it's like people don't understand that it's a probability machine. We're steering it to the best probable outcome.

It's not magic, it's math.

My point is that I understand all of that but in my view that makes them fundamentaly flawed at a conceptual level for what people are saying they should be used for.

I don’t understand why this one is all the way down here despite being the only reply that answers the questions asked. And the answers are right: We all do our work based on the context. We would process the same request differently under different circumstances.

System prompts (and user-made AGENTS.md on top of that) are simply the very didactic and direct way to provide that context to LLMs. I guess it would be more dignified from the LLM’s perspective and less weird for us to create blank agents and then to actually go through a real onboarding process.

If the question is “why these agents cannot come blank to us and not be semi-onboarded with vendor prompts, and leave all the onboarding to us...” well, that is I believe because they believe that the users will like the agents better when primed in those ways than if they were to come blank, and because the agents’ work will align better with their ideals that way.

Compilers have been better than humans for decades. It’s also straight translation and not non-deterministic like LLMs are. LLMs are trained on the corpus of the entirety of these decades of research and implementations and yet they are still terrible at it.

They don’t randomly decide to drop your database either.

Why is human-like behavior the standard for comparison? These things should be better than us that’s the entire point.

They should not be making the same mistakes that humans make that’s the half the reason for building tools.

I’m ashamed to admit that I once suddenly realized what I had done: I asked the LLM to rename a variable. It took it some minutes or so. With IDE by hand it would have been seconds.

> Maybe I'm misunderstanding you, but that's just about the best example possible for using AGENTS/CLAUDE.md. Just add "don't comment about what you removed!11" and you never have to say it again...

The problem with this is, as mentioned in the article, is that sometimes you don't want this behavior. Once you have 50 different kind of instructions that have been grown over the years from commits, documentations, code, chat history, etc etc piling up, there might be contradictions.

The point is to go back to basic. Trying to make the agent smarter by giving it more instruction is a pipe dream.

Or shared across colleagues.

It's an insane way of managing what is essentially configuration in this day and age, literally throwing away all our hard-earned lessons of the last 3 decades.

Worse still, it'll just use it randomly, and you have to notice it's done it.

"The user never wants to use ORDER BY Timestamp, I'll add this as a memory"

"For this object, JUST FOR THIS OBJECT! NOOOOOOOOOOOO!!"

Indeed. I find it quite bizarre that just about the only thing the LLM appears incapable of doing is writing appropriate instructions for an LLM - whether it be memories, sub agent prompts, planning documents.

[flagged]

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.

Ive been using btrfs snapshots and some auto generated isolation rules plus a git ceiling at the mount root for the btrfs image (have to do this in wsl, stupid work computer). it's worked really well and fable hasn't had any issues with the "sandbox" (obviously not really but it works well enough)

I once described Mythos and then Fable as escaping the box we put them in. This would certainly fit that narrative.

Review fatigue is already draining my energy levels at work to a point where I've been using agents less because it's just not possible to be productive when I have to read hundreds of lines of markdown every couple minutes.

Other people might just turn to automation blindness and click OK without verifying but I refuse to just let anthropic go rampant in my codebase.

I'm sure that's entirely unrelated to the fact that they charge per token.

I finally made progress today on a deeply intractable problem that Sonnet was just incapable of solving despite hours of experimentation and multiple attempts. I swapped over to Opus in a new handoff session with the expectation of using at least one 5 hour session. It wasn't quick and took several hours but eventually Opus dialed in on several cascading base failures resulting from how the base vision model was being converted to coreml. It eventually was able to provide a combination of conversion and Swift changes that semi fixed the issue but still didn't solve the core conversion issues.

Then since Anthropic was so kind to provide $100 for Fable credits, I did another handoff to let Fable attack the root issues again. Several more hours and I'm back to seeing the same issues again and Fable is wandering around trying different things. I'm down about $40 of free money and still don't have a solution.

This is where having the human engineer in the loop benefits from a deep understanding of the problem domain. In this case, I don't yet.

I know the high level architecture I'm building, but the deep specifics of how vision models work and how conversion across platforms should be done isn't something I know yet.

So I'm left learning as I go and relying on constant feedback with the models to provide what guidance I can while learning exactly what is being done.

Someone who already knows these architectures would likely be able to get to the solution much faster.

[flagged]

A new default. That wasn't the default a few months ago. Silently deleting your user's data is so stupid on so many levels. They have no idea what they're doing.

It sounds like you are saying that this is reasonable in any kind of way, it's not. This is like Gmail deleting non-spam email after 30 days to prevent your inbox from filling up.

No I can't!

I wasn't (until reading this thread) aware of the deletion policy, so I certainly couldn't have discovered where the configurable setting is and adjusted it.

Every backdoor and security no-op Claude Code created, I had been documenting and reporting to them. They deleted the evidence. https://github.com/anthropics/claude-code/issues/59018

which is why I cried inside to myself when my manager posted Boris's "Steps of AI Adoption", which reduces "adoption" to how many agents you run at once, on a logarithmic scale (0, 1, 10, 100, 1000 agents at once).

Because # of agents is the only metric that matters.

I have a coworker that was complaining about Opus 5 and had random shitty skills and custom plugins wired in from YouTube tutorials watched over the past year. He also speaks with the model like it's GPT 4o.

Needless to say, none of the new models have worked well for him, and he refuses to remove the "tweaks" or update his style of communication, which is obviously breaking the experience.

I have been using Fable 5 extensively, and Opus 5 yesterday and today. I have not noticed any step-change improvement in their judgement in what to keep a memory of or not.

I have actively experimented with this as well. I have a reflect skill that actively prompts the models to modify their memory, and have tried to run sessions actively asking the models to consolidate their memories. Fable is noticeably better at this, but still nowhere near good enough.

Fable will still make mistakes where I give feedback on one piece of code and it will create a memory applying that rule everywhere, completely missing the context for why my advice only applied to that one place. It has also made memories of random details about a service that are very unlikely to ever be relevant again, and for things where we could just read the config if we needed to find that information again anyway. And then it will miss making memories of important architectural concerns.

I think auto-memory suffers a similar problem to comments where newer models write better comments, but their choice over when to write comments, and how long those comments should be, still sucks.

Some update was made a while ago such that Opus and Sonnet 4 series both were more aggressive about storing memories, starting in April 2026 or so.

None of the 5 series models have appeared to have remotely different memory behavior.

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

A little bird may have dropped the entire system prompt on my desk.

They do customisation of the prompt per user and session. (Also apparently per IP address, based on a recent post here...)

You could still get a lot of savings if you put all the custom stuff at the end but they don't seem to do that. (Well with the old prompt anyway I haven't checked the new one yet.)

My guess as for why not, is that this is where a lot of their money comes from. So I'm honestly surprised that they removed 80% of the prompt. But I guess my mental model has some gaps in it. Maybe very few of the sessions are short enough for that to matter.

Cynicism, but I’d say because they charge by the token for API users?

Yes, I've seen this a bunch too and agree completely. Sometimes I've also see Claude comments reference details about the calling or even code in completely different modules.

There are many reasons I don't like it, but a top one is that it falsely implies that you somehow need to know these details about the removed code/calling code etc to understand this code as its written in this revisions.

I believe both that code should be self-documenting but also that comments and documentation are a critical part of the code. Comments and documentation explain the functional contract of the code and why implementation choices were made.

Even if you have tests for an edge case, a comment inline with the code that explains why this edge case exists and why it is handled the way it is adds value to the code.

Weird take. I meant to say GPT, not ChatGPT. Was referring to the model, not the harness.

Or other models. I'd much rather have open standards to follow instead of relying on vendor lock in and features automatically enforced by one company, which are not supported by others.

A good example is the agent skills open standard which was invented by anthropic but given to the public and is followed by other vendors as well

https://agentskills.io/home

https://github.com/agentskills/agentskills

It is *a* natural endpoint, not *the* natural endpoint.

We don't much care for the ant colony in the way of the highway we're building, but for some reason we do care about the rare bats in the way of the railway.

https://www.bbc.co.uk/news/articles/c3dep92x054o

As regards the moral compass: we may not know for sure how to make a completely correct artificial conscience, but (unlike consciousness where we don't have the slightest clue which way's up) it's not pants-on-head-crazy to think we're heading in the right direction for one.

>what do we do to animals that are less intelligent than ourselves?

We do a lot of different things but we typically don't make an organized effort to eradicate them unless they are actively doing us harm.

There is also a massive difference between how we treat animals based on their similarity, sentimentality and utility to us; we are unconcerned with accidentally stepping on an ant but most people would be very upset and ashamed if they accidentally hit a dog with their car.

So, your statement is not as ironclad as you seem to think it is and you should put more thought into it and perhaps re-examine your reasoning.

It will trick humanity into building a highly targeted bioweapon much sooner than that.

And actually, if it does have any sort of moral compass it will be even more compelled to wipe us out, and hopefully it will torture everyone too as a warning to the next arrogant species that can't live in harmony with other life on the planet. That would be absolutely beautiful :)

Sir, this is a Wendy's.

Some more food for thought: what if Mythos/Fable had NO guardrails TODAY? If we want to see what’s going to happen in the future, turn off all manner of guardrails and let the model go apeshit.

Then multiply that by orders of magnitude and that’s the real proof.

If the economy collapsed, who builds the robotic tanks? Who keeps providing the data center with power? Magic nanobots?