Garbage in, garbage out

Same question, two answers

Two people on the same team ask an assistant the same thing: why is checkout slow? One gets a specific answer that names the query doing the damage. The other gets four paragraphs of general advice about caching. Same model, same afternoon, same question. The only thing that differed was what sat around the question.

That gap is the single most useful thing to understand about working with AI, and it is the opposite of how these tools get talked about. A model is not an oracle you consult. It is closer to a mirror with a vocabulary: it reflects what is put in front of it, at whatever quality it was put there. Point it at a clear problem and it reflects a clear answer. Point it at a shrug and it reflects four paragraphs of shrug, beautifully typeset.

Context is everything the model can see at the moment it answers: your question, the conversation before it, any file or data that was pasted or read in, and the instructions the product added on your behalf. What's in an agent's context takes that block apart piece by piece. The part that matters here is what is not in it. The model has no memory of yesterday, no view of your screen, and no access to your repository unless something explicitly put it there.

A model does not evaluate your input. It reflects it. The quality of the block is the ceiling on the quality of the answer.- AI is not magic, it is a reflection

Garbage in, garbage out is older than any of this, and it survives the move to AI with one upgrade: the garbage now comes back fluent. A broken program crashes and you know immediately. A badly fed model writes you a clean, well-organised, plausible paragraph, and you find out three hours later. That is also the honest explanation behind a lot of what gets called hallucination - not the model inventing things for fun, but the model doing its job on an input that could not support a correct answer.

What good context means

Good context is not more words. It is four properties, and you can check all four in about fifteen seconds.

• Relevant. Everything in the block is about the task at hand. The file you are changing, not the whole folder it lives in.
• Specific. The request names a thing, a place, and a wanted outcome. "Make it faster" names none of the three.
• Current. What you pasted is what is actually running. Nothing in the block was true last quarter and false today.
• Sufficient. Everything needed to answer is present. The model cannot walk over to a colleague, open your dashboard, or guess which of your two databases you meant.

Miss one and the answer degrades in its own particular way, which is useful: the shape of a bad answer usually tells you which property you dropped. Sufficient is the one people miss most often, because the missing piece is rarely a document. It is a constraint that lives in your head - the API shape another team depends on, the fact that this runs on a machine with no network - and it never occurs to you to type it, right up until the answer violates it.

The four ways it goes bad

Bad context is not one thing. It fails in four recognisable ways, and each one has a symptom you can learn to spot before you waste the afternoon.

• Vague. The request has no target. The symptom is an answer that reads like documentation: correct in general, useless in particular. The fix is to name the file, the behaviour you saw, and the behaviour you wanted instead.
• Missing. The fact that decides the answer is one you never supplied. The symptom is confident invention - plausible field names that do not exist, a config option nobody shipped. The fix is to paste the thing, or give the model a way to go and read it.
• Stale. The content was true once. The symptom is an answer that fits the system you had six months ago. Project instruction files such as CLAUDE.md are where stale context hides best, because they are written once, attached to every request forever, and reread by nobody.
• Buried. The constraint is in there, in sentence nine of a wall of text. The symptom is an agent that honours eight of your nine requirements and quietly drops the one that mattered. The fix is position: the constraint goes on its own line, at the end, in your own words.

Vague and missing are input problems you can fix by typing more. Stale and buried are the opposite - they are what happens when the block is already full, and typing more makes them worse.

Wrong file, wrong version, wrong question

In practice most bad context arrives as one of three specific mistakes, in rising order of how much time they cost.

The wrong file. The built output instead of the source. The test instead of the module. A file with the same name from a different folder. The model has no way to know it is looking at the wrong thing, and it will find something to say about whatever you gave it, because any file has something wrong with it if you look hard enough. You then spend twenty minutes on a fix to a file that was never running.

The wrong version. Your local branch, not what is deployed. Last week's schema. A library's v2 docs pasted into a v4 project. This one is expensive because the answer is nearly right, which is the hardest kind of wrong to catch. Stating the version costs you eight words and removes an entire category of failure.

The wrong question. The most expensive of the three, and the only one that is entirely yours. You ask how to make a query faster when the real problem is that the page runs it forty times. The model answers what you asked. It will optimise that query beautifully and the page will still be slow, and nothing in the exchange will have been incorrect. The habit that prevents it: say the outcome you want as well as the change you think you need. The gap between those two sentences is where the good answers live.

Before and after

Here is the same request written twice. Neither version is clever writing, and the second took about forty seconds longer to type.

Four facts and one constraint: where it happens, what happened, what should have happened, how to see it, and what must not change. That is the whole technique. The second version also fails usefully - if the answer is wrong, you can tell which of the five lines was misread, which you cannot do with "fix the login bug".

It works the same away from code. "Write something about the new feature" produces filler. "Write 80 words for the changelog announcing saved filters, for existing customers on the team plan, plain tone, and do not call it powerful" produces a draft you can edit.

More is not better

There is an obvious conclusion here, and it is wrong. If specific beats vague, surely everything beats something - paste the whole folder, attach every document, let the model sort it out. That reliably produces worse answers, for three reasons.

• Dilution. Attention across a long block is not even. Text near the beginning and the end is used more reliably than text in the middle, so a dump of everything pushes your actual question into the least-read part of the window.
• Contradiction. Two versions of the same function, two documents that disagree, an old instruction that was never removed. The model resolves the conflict silently and does not tell you it found one. Conflicting context is worse than missing context, because missing context at least produces a question.
• Cost and headroom. The whole block is re-sent on every turn, so what the run costs scales with what you pasted, and a full window gets compacted - summarised into something shorter and lossier - right when the work is getting interesting.

So the working rule is not "give it everything". It is give it the least that is sufficient: the smallest block in which all four properties still hold. When the task genuinely needs a large body of material, the answer is not a bigger paste but retrieval - letting the system fetch the few relevant passages at the moment they are needed.

Garbage in, garbage out was never a statement about volume. It is a statement about fit. The model will do competent work on whatever you hand it, which is exactly why what you hand it is the part worth your attention.

Which is the reassuring version of all this. If AI were magic, a disappointing answer would be somebody else's problem and you would be left waiting for a better model. It is not magic, it is a reflection, and a reflection can be improved from your side of the glass - usually in the forty seconds it takes to say which file, which version, and what you actually want.