Love this. Context engineering will become similar to industrial and process engineering, in the sense that those latter disciplines emerged as there was a requisite and desire to optimise and get the most out of the machines that had taken over mechanical labour. Now, context engineering is emerging similarly because we want to optimise and get the most out of the machines that are taking over coding — the mechanical labour part of software engineering.
Thanks Christian! :) That's a good analogy! You've captured something really important about why this feels like a genuine discipline emerging rather than just rebranded prompt writing. Industrial engineering didn't just happen because machines existed - it emerged when systems became complex enough that intuition and trial-and-error weren't sufficient anymore.
You needed systematic measurement, process optimization, and rigorous methodology to get reliable outcomes from complex mechanical systems.
We're hitting that same inflection point with AI systems. Early on, clever prompting was enough for demos and simple use cases. But now we're building production systems where an AI agent might retrieve from multiple knowledge bases, coordinate with several tools, maintain conversation state, and handle edge cases - all while staying within token budgets and cost constraints.
I think we will start to see frameworks/best practices/companies that specialize in helping generate and format your business data into context for models (it's already happening). This Cognition article wasn't about context engineering per se but it discusses different strategies for generating context (like a small model generating an md file of suggested changes) that might be interesting: https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
Long a ago i had a job as a logic design hardware engineer on a series of IBM mini computers. My full time job for that project was to design and develop about 600 logic gates. We were modifying about 40% of and existing machine and and using about 30% and doing new dewign on about 30%. This is the equivalent of a serious update to a piece of significant software in terms of effort.
A few years later i was working in ad tech and several programming efforts were underway to autmoate the logic desinger role. The first attempts were like prompt engineering, they objective was to automate the whole process. The result was what I called "push the button clean up the mess". Eventually, the front end was designeed to provide engineering guidance that required significant human effort. Today logic designer work wiht hundreds of thousands of gates but the front end involves considerable effort similar to context engineering.
This is why I believe the Context Engineering is an important step For code generation the goal should be refine COntext Engineering into a self documenated process which allows engineering to mop up any remaining messes. The the goal should be continue throught eh compile process to generateAlso the code genrated should be good machine code, that is thoroughly documented. Thus we would have Corss Indexed Context --> Psuedo Code --> Assembler/Machine code, resulting from a structured human guided engineering process.
Such a scheme would bring software engineers closer to Runtime Dynamcis.
Greatly written article Addy. It took a while to read it. I'll most certainly have to re-read it again to retain it all. Having only heard the words "Context engineering" yesterday, I still see prompt engineering being written and talked about more. But working around contexts instead of prompts feels like the missing piece I've needed to wrap my head around when it comes to working with AI tools.
Great article! I’m wondering how you approach context rot in multi-step tasks. Do you favor structured resets (like summaries + fresh instance), or try to manage continuity within a single thread?
I just have a problem with the word engineering. Some of us, including me, spent years studying to become a software engineer or a civil engineer or whatever. And now, fitting just the right amount of text in a box is "engineering?"
Love this. Context engineering will become similar to industrial and process engineering, in the sense that those latter disciplines emerged as there was a requisite and desire to optimise and get the most out of the machines that had taken over mechanical labour. Now, context engineering is emerging similarly because we want to optimise and get the most out of the machines that are taking over coding — the mechanical labour part of software engineering.
Thanks Christian! :) That's a good analogy! You've captured something really important about why this feels like a genuine discipline emerging rather than just rebranded prompt writing. Industrial engineering didn't just happen because machines existed - it emerged when systems became complex enough that intuition and trial-and-error weren't sufficient anymore.
You needed systematic measurement, process optimization, and rigorous methodology to get reliable outcomes from complex mechanical systems.
We're hitting that same inflection point with AI systems. Early on, clever prompting was enough for demos and simple use cases. But now we're building production systems where an AI agent might retrieve from multiple knowledge bases, coordinate with several tools, maintain conversation state, and handle edge cases - all while staying within token budgets and cost constraints.
I think we will start to see frameworks/best practices/companies that specialize in helping generate and format your business data into context for models (it's already happening). This Cognition article wasn't about context engineering per se but it discusses different strategies for generating context (like a small model generating an md file of suggested changes) that might be interesting: https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering
Long a ago i had a job as a logic design hardware engineer on a series of IBM mini computers. My full time job for that project was to design and develop about 600 logic gates. We were modifying about 40% of and existing machine and and using about 30% and doing new dewign on about 30%. This is the equivalent of a serious update to a piece of significant software in terms of effort.
A few years later i was working in ad tech and several programming efforts were underway to autmoate the logic desinger role. The first attempts were like prompt engineering, they objective was to automate the whole process. The result was what I called "push the button clean up the mess". Eventually, the front end was designeed to provide engineering guidance that required significant human effort. Today logic designer work wiht hundreds of thousands of gates but the front end involves considerable effort similar to context engineering.
This is why I believe the Context Engineering is an important step For code generation the goal should be refine COntext Engineering into a self documenated process which allows engineering to mop up any remaining messes. The the goal should be continue throught eh compile process to generateAlso the code genrated should be good machine code, that is thoroughly documented. Thus we would have Corss Indexed Context --> Psuedo Code --> Assembler/Machine code, resulting from a structured human guided engineering process.
Such a scheme would bring software engineers closer to Runtime Dynamcis.
Greatly written article Addy. It took a while to read it. I'll most certainly have to re-read it again to retain it all. Having only heard the words "Context engineering" yesterday, I still see prompt engineering being written and talked about more. But working around contexts instead of prompts feels like the missing piece I've needed to wrap my head around when it comes to working with AI tools.
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Job board!
https://context-engineering-rho.vercel.app/
Great article! I’m wondering how you approach context rot in multi-step tasks. Do you favor structured resets (like summaries + fresh instance), or try to manage continuity within a single thread?
I just have a problem with the word engineering. Some of us, including me, spent years studying to become a software engineer or a civil engineer or whatever. And now, fitting just the right amount of text in a box is "engineering?"
I'm getting old.
Have you read the article? It addresses this point exactly. It’s not about putting text in a box.