Prompting and context windows: words in, answers out
You typed one sentence into a chatbot and got a rambling answer to a slightly different question. You typed it again with two extra lines of detail and got exactly what you wanted. That second try is this whole page. The prompt is the full text the model reads for one request - your words plus whatever the app pastes around them - and nothing else in the system changes an answer for less effort. Three habits carry most of the value, in the order most people learn them late. Say what good looks like: one short line naming the format and the audience outperforms a paragraph of pleasantries. Show, do not only tell: worked examples pasted into the prompt - the pattern called few-shot, two or three copies of an input with the answer you wish you got - teach shape better than adjectives, because a model copies a demonstrated pattern far more reliably than it follows a stated rule. Constrain the container: when another program has to read the answer, ask for structured output, meaning the answer arrives in a fixed set of labeled fields a script can parse, instead of prose a human has to unpack. And beneath all three sits the ceiling: the context window, the total text the model can hold for one request - instructions, examples, pasted documents, and the conversation so far all share it, and what does not fit is not deprioritized, it is out of existence. When a long-document feature forgets the middle of the file, that is usually not the model being flaky; the middle never made it into the request. Every one of these habits is also fragile, which is why the page ends on the unglamorous half: a fixed set of realistic questions with hand-written grades, rerun before and after every prompt change, is what turns "the demo looks better" into a number someone else can argue with.
Most people have this backwards
Most of the improvement in a grown prompt comes from cutting and moving what is already in it, not from adding instructions.
The catch
It holds once a prompt has outgrown a screenful, because the model re-reads the whole window on every request and every line competes for the same attention - pruning dead rules, moving the current task next to the question, and shrinking examples that duplicate each other is measurable, and it is the version of prompt work most teams skip. It weakens on a young prompt, where the first added example or the first stated format is usually a genuine cheap win. The interview follow-up that separates them: what did you remove, and which graded questions moved after you removed it?
Baseline first - your honest read.
A colleague rewrites the system prompt over an afternoon and the feature feels better on the three queries they were watching. What turns that into a shippable claim?
Make each call, then see the verdict
Predict first
A team keeps bolting instructions, examples, and a full FAQ onto one support prompt. The task still fits the window. Does per-question correctness on the graded set rise, fall, or stay flat?
Four prompts that underperform. Pick the lever each one wants.
The answers are right and four paragraphs long, when the team that consumes them wanted one or two sentences. Nothing in the prompt mentions length.
Ticket classification works on the common cases and keeps mislabeling the sarcastic ones and the multi-topic ones. The instruction is one clear line, and rewording it changes nothing.
Every answer feeds a script that extracts action items, and the script keeps breaking whenever the model writes its list as prose inside a sentence.
Twelve turns into a long session, the model stops following a rule it held from turn one - never request payment details in chat. The rule still sits first in the prompt, untouched.
How it works
The anatomy of one request is a stack packed into a single window. Front: standing instructions, written by the app, identical on every request. Behind them any attached material - pasted documents, fetched records, the outputs of tool calls. Behind those the conversation so far, because models hold no memory between requests and each turn re-sends everything that came before. The user's newest line rides last, nearest the door. Everything on the stack shares the one budget, and whatever is dropped is dropped silently, usually from the middle rather than the edges. Reading that stack teaches three placements. Position does quiet work: material placed just above the newest message is used far more reliably than the same material standing far back, which is why the fix for a long session drifting off its own early rules is a close copy, not a sharper original. Examples carry weight: two worked samples cost a few lines and beat a whole paragraph of instruction on anything shape-shaped, at the price of the window space they occupy. And the window turns every addition into a budget decision - a feature that sends a full document, a full history, and elaborate instructions is spending its window in three directions at once, and one of them is going to lose. The graded set closes the loop the way a scale closes a diet: prompts are the cheapest lever to pull and the easiest to regress, so the change is judged by rerunning the same frozen questions and reading which answers moved in which direction, because a prompt edit almost never moves them all one way.
The cleared desk
I picture the model working at a desk that is cleared after every question. The context window is the desk surface. On it: an instruction card, a stack of examples, the documents that came attached, the running transcript of the conversation, and the newest question on top. The person at the desk reads everything on it, every time, and keeps nothing - there is no drawer, no notebook, no memory that survives the clear. Two consequences follow that most people learn from a bug report. Whatever was not stacked on the desk when the question arrived cannot inform the answer, and the answer will not say so; truncation is silent. And because every item competes for the same surface, placement is not decoration: the card nearest the question is the one that gets read most closely, and the same example reads as a nudge at the top and as wallpaper forty items back.
Where it breaks
The analogy breaks at where forgetting actually happens. A human at a desk loses the middle card to clutter and skims, while the model reads the whole window end to end on every request and does not skim the way a person does - what really truncates the long document is the system stacking the desk, an app-side limit or a template that drops attachments before the model ever sees them. That is the gap the picture hides: the failure users report as the model forgetting is, more often than anyone expects, the model never receiving it, which is why the first debug step is reading the assembled prompt, not changing its wording.
Why interviewers lean on it
Prompting shows up in interviews as the cheap round it is easiest to fail, because everyone has typed into a chatbot and few people have measured one. The questions that separate them: what exactly is inside the prompt when a real request runs, why did the example you added help - which behavior moved, on which graded questions - and what did the same change quietly make worse somewhere else. A candidate who has run a fixed graded set answers with before-and-after numbers on named question groups; one who has only played answers with adjectives about clear instructions. The context window carries its own weight in the room: where the documents go inside the window, what happens when a conversation outgrows it, and what gets dropped first are all answerable out loud, and the answers are the difference between operating a prompt and decorating one. The product stakes are the same story with a budget line: prompt changes are the fastest way to make a feature better and the fastest way to quietly make it worse, and the cost of that speed is not zero - it is the discipline of the rerun.
The follow-up chain
Interviewers do not stop at the surface answer. Answer the way you would out loud, or skip - skipping reveals the strong answer and ends the chain.
The interviewer's next question
You doubled our prompt with worked examples and quality is better on the cases you showed. Why do I not believe that yet?
Now answer one you have not seen
You inherit a support prompt grown to three screens - a paragraph of rules, six examples, pasted policy text, and the user's question - and quality is mediocre in ways nobody can attribute. You get one afternoon. What do you do, and what do you bring to the next review?
Expires fast - as of 2026-10-06
As of 2026-10, structured output modes are a standard API feature across the major hosted model providers, which moves format enforcement from prompt-pleading to a platform check; this concept teaches the request and the code-side validation because both survive every provider.
Few-shot examples remain the working fix for shape problems in 2026, and teams commonly trim example counts once structured output carries the format; graded-set regression is the usual gate for prompt changes among teams that publish their practice.
Position sensitivity - older instructions decaying over long sessions and reviving when restated close to the newest message - appears across provider guidance and practitioner writeups; no provider promises exact attention parity across window positions.