Prompt Engineering Is Dead. Context Engineering Is the Job Now
The magic-words era is over. Getting great output is now an engineering problem about what the model sees, remembers, and is allowed to do.
There was a brief, golden period when knowing the magic words mattered: ask the model to think step by step and watch quality jump. That era is over, and pretending otherwise is how teams end up with prompt libraries full of incantations that stopped working two model versions ago.
The models got robust enough that phrasing matters far less than substance, which relocated the skill. The people getting exceptional output today are not writing cleverer prompts; they are engineering context: what documents the model sees, what facts are guaranteed, what examples set the register, what tools it may touch, what memory persists between sessions. The prompt is the last five percent of a system, not the whole craft.
You can see the shift in where the tooling went. Projects, custom instructions, retrieval hooks, rules files, memory: every major product spent its year building context infrastructure, and the users who win with them are the ones who treat setup as the work. My best-performing assistant has a style guide, a facts file, and a corrections log. Its prompts are one sentence.
There is a hiring implication worth naming. The skill of decomposing a task into context, constraints, and verification is closer to systems thinking than to writing, and the best context engineers I know come from ops and library science, not from prompt forums. Recruiters still filtering for prompt engineering keywords are fishing in last year's pond.
So retire the term with respect: prompt engineering was the training wheels that taught us models respond to their inputs. Context engineering is the grown-up version, and it looks less like magic and more like the oldest job in computing, deciding what information reaches the machine that does the work.