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.
Anyone believing software engineering is a legitimate term should also accept context engineering as a legitimate term. Wikipedia's definition of engineering includes "The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination" and context engineering as the term is used definitely qualifies if software engineering does.
I accept most of your point - that engineering has a much broader definition than what I'm alluding to. But the part I'll quibble with is the extent to which there are "scientific principles" involved here. This seems almost entirely empirical to me.
Licensed engineers accept responsibility for those structures/machines/etc when they physically harm or kill others. Like lawyers or doctors being sued for malpractice.
A typical person does not understand scientific principles and cannot validate whether a bridge is safe before using it. An engineer that approves a bridge can be held liable when that bridge fails, even if they had orders from their boss or company.
If you're not prepared to accept personal liability when your code kills someone or causes a disaster, you shouldn't try to be an engineer.
I live in a country (Canada) where software engineering is legally considered engineering and that's what officially distinguishes a "software engineer" from a "software developer". In practice, I rarely see the rule followed.
Yeah, and wikipedia also states that engineering is a decision making process (often iterative) in which the engineering sciences, basic sciences and mathematics are applied to convert resources optimally to meet a stated objective.
So which scientific principles do context engineering apply?
There is none. So yeah. It's not engineering at all.
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.
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.
Vibecoding is an excellent term, its communicates that the output and process is not entirely serious. I think without this term we would have even more PM types announcing that programming is dead and you just need a business person with some prompts copied off linkedin.
I think this gives room for non technical people to vibecode prototypes, knowing that the output will eventually go off the rails without technical understanding.
writing an essay on this if you'd be interested in reading a rough draft. i believe this very strongly and i think it's the UX that got us here and it's UX that'll take us out.
Honestly, I don’t think it’s about AI even. The world has become so cynical, that’s just how people make business now. If it wasn’t context engineering, it’d be professional Watermelonism.
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!)
Anyone believing software engineering is a legitimate term should also accept context engineering as a legitimate term. Wikipedia's definition of engineering includes "The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination" and context engineering as the term is used definitely qualifies if software engineering does.
I accept most of your point - that engineering has a much broader definition than what I'm alluding to. But the part I'll quibble with is the extent to which there are "scientific principles" involved here. This seems almost entirely empirical to me.
I don't believe it was empirically checked either tbh, just anecdata
Licensed engineers accept responsibility for those structures/machines/etc when they physically harm or kill others. Like lawyers or doctors being sued for malpractice.
A typical person does not understand scientific principles and cannot validate whether a bridge is safe before using it. An engineer that approves a bridge can be held liable when that bridge fails, even if they had orders from their boss or company.
If you're not prepared to accept personal liability when your code kills someone or causes a disaster, you shouldn't try to be an engineer.
I live in a country (Canada) where software engineering is legally considered engineering and that's what officially distinguishes a "software engineer" from a "software developer". In practice, I rarely see the rule followed.
Legal responsibility and the matter of engineering are two different and unrelated things. You can do engineering without a license.
Yeah, and wikipedia also states that engineering is a decision making process (often iterative) in which the engineering sciences, basic sciences and mathematics are applied to convert resources optimally to meet a stated objective.
So which scientific principles do context engineering apply?
There is none. So yeah. It's not engineering at all.
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.
Sounds like a lot of superstition if there aren't the examples to show that such a complicated approach beats a less complicated ones.
Reads like an alchemist trying to write about how to create gold.
The shift from prompt engineering to context engineering is a massive tailwind for the "GenAI certification industry™"
One thing I've noticed is llms are much better at outputting tabular data than json objects, especially for lists
This is exhausting.
this is too convoluted and has no proof why it should be done this way
"Include relevant files directly, instead of letting the agent immediately grep your codebase, to save ninety seconds."
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.
Vibecoding is an excellent term, its communicates that the output and process is not entirely serious. I think without this term we would have even more PM types announcing that programming is dead and you just need a business person with some prompts copied off linkedin.
I think this gives room for non technical people to vibecode prototypes, knowing that the output will eventually go off the rails without technical understanding.
writing an essay on this if you'd be interested in reading a rough draft. i believe this very strongly and i think it's the UX that got us here and it's UX that'll take us out.
Honestly, I don’t think it’s about AI even. The world has become so cynical, that’s just how people make business now. If it wasn’t context engineering, it’d be professional Watermelonism.