Live data from Hacker News

Context Engineering for Agents

rlancemartin.github.io

21–30 of 36 posts

Re: Context Engineering for Agents

#21

Nah ! I am not convinced that context engineering is better (in the long trem) than prompt engineering. Context engineering is still complex and needs maintainance. Its much lower level than human level language. Given that domain expertise of the problem statment, we can apply the same tactics in context engineering on higher level in prompt engineering.

Going to disagree here.

Early in the game when context windows were very small (8k, 16k, and then 32k), the team I was working with achieved fantastic results with very low incidence of hallucinations through deep "context engineering" (we didn't call it that but rather "indexing and retrieval").

We did a project for Alibaba and generated tens of thousands of pieces of output . They actually had human analysts reviews and grade each one for the first thousand. The errors they found? Always in the source material.

Re: Context Engineering for Agents

#22

Earlier quoted context omitted.

> On top of that -- rebranding "prompt engineering" as "context engineering" and pretending it's anything different is ignorant at best and destructively dumb at worst. It is different. There are usually two main parts to the prompt: 1. The context. 2. The instructions. The context part has to be optimized to be as small as possible, while still including all the necessary information. It can also be compressed via,…

I'm getting on in years so I'm becoming progressively more ignorant on technical matters. But with respect to something like software development, what you've described sounds a lot like creating a detailed design or even pseudocode. Now I've never found typing to be the bottle neck in software development, even before modern IDEs, so I'm struggling to see where all the lift is meant to be with this tech.

> But with respect to something like software development, what you've described sounds a lot like creating a detailed design or even pseudocode.

What I described not only applies to using AI for coding, but to most of the other use cases as well.

> Now I've never found typing to be the bottle neck in software development, even before modern IDEs, so I'm struggling to see where all the lift is meant to be with this tech.

There are many ways to use AI for coding. You could use something like Claude Code for more granular updates, or just copy and paste your entire code base into, e.g., Gemini, and have it oneshot a new feature (though I like to prompt it to make a checklist, and generate step by step).

And that is also not only about just typing, that is also about debugging, refactoring, figuring out how a certain thing works, etc. Nowadays I not only barely write any code by hand, but also most of the debugging, and other miscellaneous tasks I offload to LLMs. They are simply much faster and convenient at connecting all the dots, making sure nothing is missed, etc.

Re: Context Engineering for Agents

#23
post #2

Another article handwaving or underselling the effects of hallucination. I can't help but draw parallels to layer 2 attempts from crypto.

Apple released a paper showing the diminishing returns of "deep learning" specifically when it comes to math. For example, it has a hard time solving the Tower of Hanoi problem past 6-7 discs, and that's not even giving it the restriction of optimal solutions. The agents they tested would hallucinate steps and couldn't follow simple instructions. On top of that -- rebranding "prompt engineering" as "context engineeri…

The paper in question is atrocious.

If you assume any kind of error rate of consequence, and you will get that, especially if temperature isn't zero, and at larger disk sizes you'd start to hit context limits too.

Ask a human to repeatedly execute the Tower of Hanoi algorithm for similar number of steps and see how many will do so flawlessly.

They didn't measure "the diminishing returns of 'deep learning'"- they measured limitations of asking a model to act as a dumb interpreter repeatedly with a parameter set that'd ensure errors over time.

For a paper that poor to get released at all was shocking.

Re: Context Engineering for Agents

#24
post #2

Another article handwaving or underselling the effects of hallucination. I can't help but draw parallels to layer 2 attempts from crypto.

Apple released a paper showing the diminishing returns of "deep learning" specifically when it comes to math. For example, it has a hard time solving the Tower of Hanoi problem past 6-7 discs, and that's not even giving it the restriction of optimal solutions. The agents they tested would hallucinate steps and couldn't follow simple instructions. On top of that -- rebranding "prompt engineering" as "context engineeri…

We used to call both of these "being good with the Google". Equating it to engineering is both hilarious and insulting.

Re: Context Engineering for Agents

#25
I read these things and I think : this can never work. This is passing a huge set of parameters to a probabilistic map function.. one token changes and you get a completely useless result.

Re: Context Engineering for Agents

#26
post #25

I read these things and I think : this can never work. This is passing a huge set of parameters to a probabilistic map function.. one token changes and you get a completely useless result.

I mean, you could apply logic here, but I don't think the people with the money care about logic, just more money, and they've been told that there will be more money from replacing human employees, so really even if you're correct, you're still wrong.

Re: Context Engineering for Agents

#27
post #14
post #10

Earlier quoted context omitted.

Let's just call all aspects of LLM usage 'x-engineering' to professionalise it, even while we're barely starting to figure it out.

It’s fitting, since the industry is largely driven by hype engineering.

It’s not good for engineering with the dilution of the term. We don’t really have many backup terms to switch to.

Maybe we should look to science and start using the term pseudo-engineering to dismiss the frivolous terms. I don’t really like that though since pseudoscience has an invalidating connotation whereas eg prompt engineering is not a lesser or invalid form of engineering - it’s simply not engineering at all, and no more or less ”valid”. It’s like calling yourself a ”canine engineer” when teaching your dog to do tricks.

Re: Context Engineering for Agents

#28

Good retrieval/search is the foundation of context. It's definitely garbage in - garbage out here otherwise. Search is far from a solved problem.

Context is a much bigger problem. For an agent to have appropriate context to offer advice it has to know many things about the specific environment and state of the person querying the agent. For example, to answer the question "what's the weather going to be like later today" the agent has to know where the person is. If they are indoors you may not be able to get that from their cellphone GPS. If they are using a proxy server you may not be able to get location from their IP address. They may have Bluetooth and WiFi turned off. They may not have a default location set or could be somewhere else. The agent also needs to know where the person is going to be "later today". They might be on a plane flying to a new location or driving or on a train. They may have just changed their plans because of a phone call they received and plan to head to a new location. The weather may be complex with a hurricane forming nearby or a storm with tornado potential may be moving through the area.

Context is very difficult for computers to acquire and understand. In some cases it requires knowing what a person is thinking or their entire life history. The sensors currently available are very limited in their ability to gather context; for example sensing mood, human relationships, intentions, tastes, fashion, local air temperature, knowledge about building layout, customs, norms, and a lot more. Context is a huge ontology problem and it's not going to be solved any time soon. So agents are going to be limited in what they can do for a long time. At a minimum an agent probably needs to know your entire life history, and the life history of everyone you know, and the past history of the area you are in. More limited ideas of context may be useful, but context as humans understand it is immensely complex. Even if you define context as just what a person supplies to a chatbot as context, the person may not be able to supply everything relevant to the question at hand because context is difficult for people too. And everything relevant to a question is most certainly not always available on the web or in a database.

Re: Context Engineering for Agents

#29
Is this an argument to upload more specific, detailed info (“context”) to tech companies? Which have lousy track records for protecting privacy? And an insatiable appetite for proprietary data? Why should any person or company trust OpenAI, Meta, Goo, etc? How does this make any sense? Or am I missing some reason to trust this “context” vision?

Re: Context Engineering for Agents

#30
post #25

I read these things and I think : this can never work. This is passing a huge set of parameters to a probabilistic map function.. one token changes and you get a completely useless result.

Maybe, but also, some of the most popular ai-assisted coding / vibecoding platforms are using system prompts that are 1.5k+ lines long[0]

0: https://github.com/x1xhlol/system-prompts-and-models-of-ai-t...

Post reply on HN