I don’t really think this reflects the current era of challenges?
The “enforcement layer” is the hardest and most important part, and is barely addressed.
- is the answer structurally / syntactically valid?
- is it appropriately grounded and evidenced?
- is it accurate? In what ways does it fall short?
Each of these should be triggering an agent to rework and resubmit etc. or failing that a disclosure to the user about how the answer falls short and should be reviewed / remediated.
This feels like it’s from the era of trying to oneshot a good enough answer.
enforcement is the hard part. most context engineering stuff describes what should happen, not what actually stops it from happening. curious how your enforcement layer handles runtime checks vs just descriptive ones
> the information an AI system needs to produce accurate ... outputs
I would have stuck a qualifier in there
I feel like AI is going to be doing all the fun stuff and I will just left organizing the data and docs it needs to generate code.
Welcome to becoming a project manager.
Putting engineering after a term doesnt make it engineering.
Software engineering is certainly not engineering. Even at the highest levels. Real engineering have infinitely more complex interactions in the physical world than symbolic institutions for machines.
Thats right, no need to understand anything other than symbols on a machine. No people involved. No reality to model. No economics to think about. Nothing like real engineering. Thats for the big boys and girls
Probably just using the convention started by the term "prompt engineering", which is forgivable.
not sure i forgive "prompt engineering"