Context Engineering Guide

It seems endemic to software to me that people constantly want to brand things as "engineering" that aren't. They always want to call it engineering because it sounds better but they don't want to do nearly anything associated with engineering - rigorous process control, systematic documentation, specification of tolerances, resource usage etc etc.

What's described here is mostly a list of barely disguised tips, tricks and heuristics. It's all fine until someone wants to put it in production and suddenly a "real" engineer has to take over and do the actual engineering.

(and yes, I'm old - and grumpy!)

Reads like an alchemist trying to write about how to create gold.

Prompt engineering and now ”context engineering” are really the poor man’s engineering work when you’re subject to model iterations and cannot control any of the stochasticity of the models… what we need is better science to understand how to control large model’s output, not more LinkedIn AI influencers

The interesting part of context engineering (the actual engineering part) is figuring out how to gather the information the LLM needs to do a task correctly from your system. For example, the secret sauce of GitHub Copilot is how it decides what parts of your codebase to show the LLM. This is surprisingly hard when you need something other than simple RAG. In many cases the data source you need doesn’t exist and you have to build it.

The prompt engineering side of the problem (how you structure your prompt) is trivial by comparison and will become less and less relevant as frontier models improve.

One thing I've noticed is llms are much better at outputting tabular data than json objects, especially for lists

This is exhausting.

"Include relevant files directly, instead of letting the agent immediately grep your codebase, to save ninety seconds."

this is too convoluted and has no proof why it should be done this way

Great, yet another hyped up word to keep the AI hype going...

I respect Karpathy, but I can’t shake the feeling that recently has been doing more damage than good to the AI community. First he came up with “vibecoding“ and now this one. What we need is better engineering approaches to build AI systems, not buzzy marketing words that only benefit AI companies.