Prompt engineering is really context engineering
The gains rarely come from clever phrasing. They come from deciding what the model gets to see, and in what order.
Amit Shivpratap Singh • • 5 min read
On this page
Phrasing is the small lever
A great deal of prompt advice concerns wording — be specific, assign a role, ask the model to think step by step. These help, and they are also the smallest lever available. Rewording a prompt against a weak context window moves accuracy a few points. Fixing the context moves it far more.
The window is a budget
Treat the context window as a budget to allocate rather than a container to fill. Every token spent on a boilerplate instruction is a token not spent on the record that actually answers the question.
Long contexts also degrade unevenly. Material at the beginning and end gets attended to more reliably than material buried in the middle, so ordering is a design decision: put the task at the top, the critical evidence at the bottom, and the supporting material between them.
Make grounding checkable
Ask for citations back to the supplied context and you gain two things: users can verify claims, and you can detect fabrication automatically by checking whether a cited passage exists. A model that cannot cite a source for a claim has usually invented it.
Pair that with an explicit instruction to answer "not in the provided material" when the context falls short. Refusal is a feature; a confident wrong answer costs far more than an admission of ignorance.
Measure before you tune
Without an evaluation set, prompt work is vibes. Assemble thirty real questions with known-good answers, score changes against them, and keep what wins. It is unglamorous, and it is the difference between engineering and guessing.