[deleted]
The new rules of context engineering for Claude 5 generation models
21–30 of 434 posts
Re: The new rules of context engineering for Claude 5 generation models
#22We 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.
Re: The new rules of context engineering for Claude 5 generation models
#23We 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...
An LLM Inspired Specification Processing language. Or LISP language for short. Truly this "LISP" language is the language for AI and is the first of its kind in history!
Re: The new rules of context engineering for Claude 5 generation models
#24We 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 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.
Re: The new rules of context engineering for Claude 5 generation models
#25We 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.
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.
Re: The new rules of context engineering for Claude 5 generation models
#26We 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 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.
Re: The new rules of context engineering for Claude 5 generation models
#27We 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...
An LLM Inspired Specification Processing language. Or LISP language for short. Truly this "LISP" language is the language for AI and is the first of its kind in history!
Maybe this one will even be successful!
Re: The new rules of context engineering for Claude 5 generation models
#28Earlier quoted context omitted.
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 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 :)
Re: The new rules of context engineering for Claude 5 generation models
#29The point about not using examples is important, I recently noticed with the new "eagerness" of models it constraints them too much, so I use counter-examples. Recently I've switched to "think about the existing biases and assumptions in the design and try to exploit them, for example why do we X not Y".
Re: The new rules of context engineering for Claude 5 generation models
#30This 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.