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

The new rules of context engineering for Claude 5 generation models

claude.com

Post reply on HN
Print view View original

351–360 of 434 posts

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

#351

Post by chaboud »

jghn wrote: post #166
chaboud wrote: post #163

Earlier quoted context omitted.

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.

Why is that funny. I've had that as part of my professional lexicon for over 20 years

I've renovated houses (and I have a bad habit of buying 100 year old hacked up chaos-boxes - my current house was moved from one hill in San Francisco to another 80 years ago, so it's a puzzle box), so yes, I've been using "load-bearing" as a shorthand for decades, reduced to be less jargon-y by adopting "structurally essential" for increasingly international team composition, where English is a second or third language.

However, I've been hearing "load-bearing" at least two orders of magnitude more often over the last few months, particularly after uncorking Claude Code for the team.

I don't think it's a dead give-away of AI usage, and I don't think AI usage is a problem. I just think we can introduce phrases into common use by having them be used by common tools. So let's train the models on obscure/archaic terms and see what happens. Heck, we can just prompt it...

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

#352

Post by Eddy_Viscosity2 »

jeremyjh wrote: post #312
Eddy_Viscosity2 wrote: post #270

Earlier quoted context omitted.

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 but don't actually communicate to each other what those definitions are because they assume the other side is using the same one. The loosest definition of thinking is along the lines of anything that can process information i…

It has nothing to do with thinking or consciousness. There is a common misconception that LLM are simply a "statistical process" that doesn't feature any abstract conception of the tokens it is predicting. There are studies that show that such features do exist - that there is discernible structure built into the weights - and that the process of inference is a very rich one. The statistical process exists but it is…

I don't dispute what you're saying about how LLMs work, but this is exactly what I mean. LLMs can be shown to demonstrate reasoning, so if define thinking as being able to reason, then LLMs can indeed think. If instead you define thinking as being more than just reasoning, then LLMs cannot think. Neither of these two options change what LLMs do, its just an argument about the best word to describe it.

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

#353

Post by ThoAppelsin »

paulddraper wrote: post #322
throwatdem12311 wrote: post #303

This kind of stuff just makes me think nobody has any clue how these things work. Why do I need a system prompt at all? Why do I need another black box AIs to review the code of the black box AI why can’t these things get code right the first time. Why is the best “coding model” in the world still making up APIs that don’t exist and do seemingly random unreleased changes that it wasn’t prompted for. Why do these mode…

> Why do I need a system prompt at all? That's like asking why you need employee onboarding. You could have Stephen Freaking Hawking and he still wouldn't know what you specifically want. > Why do I need another black box AIs to review the code of the black box AI why can’t these things get code right the first time. That's like asking why you need code reviews. Thinking about it from an antagonistic perspective is u…

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.

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

#354

Post by JohnMakin »

ciex wrote: post #235
JohnMakin wrote: post #192

Earlier quoted context omitted.

30 days is just a default, so your session data doesn’t fill your hard drive. It’s a configurable setting. You can make the retention as long as you want.

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.

It’s nothing like that. 99% of users have no idea these logs exist or have any use for them. Even the original complaint went months without realizing it - of all the things to complain about this tool, this is so low down there.

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

#355

Post by seff »

Tadpole9181 wrote: post #345
throwatdem12311 wrote: post #303

This kind of stuff just makes me think nobody has any clue how these things work. Why do I need a system prompt at all? Why do I need another black box AIs to review the code of the black box AI why can’t these things get code right the first time. Why is the best “coding model” in the world still making up APIs that don’t exist and do seemingly random unreleased changes that it wasn’t prompted for. Why do these mode…

I disagree, this is all because it's understood. You need a system promot because an LLM is fundamentally a token predictor. It needs to be primed for the work it's going to do, otherwise it's next token prediction has too little to go off in the beginning and goes nuts. You use a separate AI to review the code, because it's a token predictor trained mostly on accomplishing tasks in a cost effective way - we haven't…

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.

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

#356

Post by cindyllm »

seff wrote: post #355
Tadpole9181 wrote: post #345

Earlier quoted context omitted.

I disagree, this is all because it's understood. You need a system promot because an LLM is fundamentally a token predictor. It needs to be primed for the work it's going to do, otherwise it's next token prediction has too little to go off in the beginning and goes nuts. You use a separate AI to review the code, because it's a token predictor trained mostly on accomplishing tasks in a cost effective way - we haven't…

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.

[dead]

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

#357

Post by [deleted] »

throwatdem12311 wrote: post #303

This kind of stuff just makes me think nobody has any clue how these things work. Why do I need a system prompt at all? Why do I need another black box AIs to review the code of the black box AI why can’t these things get code right the first time. Why is the best “coding model” in the world still making up APIs that don’t exist and do seemingly random unreleased changes that it wasn’t prompted for. Why do these mode…

[deleted]

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

#358

Post by diob »

sothatsit wrote: post #150

Similarly, I recently disabled auto-memory in Claude Code, and performance improved. Managing the context that agents have available to them is far too important to leave to the agents themselves. Agents tend to write far too much into their memory, they are terrible at trimming it down, and their choice of what to include is very poor. I have had much more predictable results by disabling auto-memory and actively sh…

Yep, I disabled it and moved to Claude.local.md anything that seemed worth keeping. Automemory kept so much random cruft and had grown bigger than my Claude.md.

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

#359

Post by elliotec »

radio879 wrote: post #152
chrisweekly wrote: post #138

Earlier quoted context omitted.

"There is a depth of thought untouched by words, and deeper still a depth of formless feeling untouched by thought." - Rilke Your assertion that we don't think in language is questionable. It runs counter to the lived experience of developing thoughts through writing ("writing isn't capturing thinking -- it is thinking"). I believe there is more to thought than language alone, but I also feel quite sure that language…

There are people who do not have any words in their heads at all when they think, and there doesn't seem to be any reason to disbelieve them. It may have been proven or at least observed in fMRI. Some people think in visuals. I think some of this was discovered somewhat recently

This is highly contested, most likely not true, and probably not measurable anyway.

https://journals.sagepub.com/doi/10.1177/09567976251335583

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

#360

Post by dxdm »

drooby wrote: post #308
dxdm wrote: post #210

Earlier quoted context omitted.

It's a clunky metaphor, and it's used clumsily: not for the sake of its clunkiness, but by mixing two decent individual parts in an attempt to have them reinforce each other, but ending up with something weaker. It communicates an absence of thought and awareness, blind groping at building blocks without understanding. It's borderline vapid, and quite annoying.

I don't follow, the words make perfect sense together in most software engineering contexts. "Seam" is an industry standard term coined by Michael Feathers in Working Effectively with Legacy Code. To call a seam load bearing means it's performing critical work for the dependent class, perhaps a database query. A seam that is not load-bearing would be something that is just injected for testability - maybe a date prov…

Well, first, we don't have enough context to judge what the "load-bearing seam" was used for in this case ("The key structural point first: the only load-bearing seam is [...]"), so we don't know if it was meant in the well-defined legacy-code sense. But that doesn't really matter.

I'm taking issue with the combination "load-bearing seam". It's a bad metaphor, because seams are usually structural weak points in the physical world, and not load-bearing in the sense that this modifier is usually used. (Seams need to bear loads and stresses to do their job, but so do walls; yet, we do not call all walls load-bearing. We mean something extra when we say that, something that seams don't do.) Even if we were talking about seams in the well-defined software sense, as opposed to the metaphorical one, you still get a mixed metaphor as a result that I find extremely awkward and grating. It doesn't have to be. There are so many ways to highlight the importance of something without calling it "load-bearing".

I understand that you don't see it that way or don't care, but to me, the result is thoughtless, careless and vapid. Bad metaphors put little holes into a text, they leave eddies of confusion where meaning should be, they look load-bearing while actually being weakening, they're like a fart in the elevator that should lift the reader's understanding.

Note that I'm not calling into question that seams may be well-defined in some software contexts, or that "seam" and "load-bearing" can be valid metaphors on their own, as you describe. I think you might have misunderstood me that way. I'm only calling out, and fed up with, the bad style that permeates LLM-generated prose like the whiff of something not quite digested.

It's not this particular case that irks me, but what it exemplifies. I wouldn't mind so much if similar things to this weren't there everywhere, every single day.

If it doesn't bother you, I'm happy for you.

Post reply on HN