Prompting

The model is not withholding context, it does not have it

Most prompting frustration comes from an assumption that the model knows more than it does. It does not automatically know which file you mean, what your environment variables are set to, what the previous session changed, or that the API you are calling has a version-specific quirk. When a request omits something it needs, the model does not stop and ask. It infers, and a plausible inference that happens to be wrong is far more expensive than a question would have been.

This reframes the whole task. Prompting well is not persuasion and it is not phrasing. It is supplying the specific information required to remove the need for a guess, which is why the techniques that survive contact with real projects are unglamorous ones: name the file, paste the actual error, state the constraint, describe the current behaviour and the wanted behaviour separately.

Where, what, and what must not change

A request that names all three is materially harder to misread than one that names the first two. Where scopes the work. What defines success. The third part, what must not change, is the one people skip, and it is the one that prevents an agent from rewriting adjacent code it considers untidy, swapping a library it prefers, or restructuring a component while it is in there anyway.

None of the three requires technical vocabulary. "The contact form on the homepage, not the whole site" scopes a request precisely without naming a single file. Precision and jargon are different things, and only one of them is required.

Describing a failure the model can act on

"It's broken" and "it doesn't work" transfer almost no information. A model given only that will re-read the code, form a theory, and change something. If the theory is wrong you now have two problems. The useful alternative is mechanical: what you did, what you expected, what actually happened, and the exact error text if there is one, copied rather than paraphrased. Error strings are precise identifiers, and paraphrasing one destroys the part that makes it searchable and diagnosable. This site's own guide to describing a bug so your AI agent can actually fix it covers this discipline in full.

Where a failure appears matters as much as what it says. The same message from a browser console, a build log and a server log points at three different layers of the same stack, and naming which one you are reading eliminates most of the wrong branches immediately. Errors and troubleshooting covers that diagnostic split in more depth.

Why prompts decay as a project grows

A prompt that worked in week one can fail in week four without a word changing, because a prompt is only half the input. The other half is the state of the project and the conversation around it, and both drift. More files means more places a vague reference can land. A longer conversation means more superseded instructions and abandoned approaches still sitting in context, competing with the current one.

The practical consequence is that context management is a prompting skill, not an adjacent one. Knowing when a session has accumulated more contradiction than useful history, and starting a clean one carrying a summary of the current state, is often the highest-value move available. It usually beats re-prompting into a conversation that already contains three failed attempts at the same thing. This site's own guide to when to start a new chat instead of continuing covers the actual signals worth watching for, across every platform this site documents.

The failure patterns worth recognising by name

Certain AI failures repeat often enough to be worth naming, because recognising one immediately tells you what to do. Changing working code that was not part of the request, usually invited by a scope broader than intended. Solving the wrong layer, fixing a symptom in the frontend when the cause is a backend response. Introducing a new fault while correcting another, which is what makes small, reviewable changes worth more than large ones. Assuming a configuration rather than asking, which is why environment and service details belong in the prompt rather than in your head.

None of these mean the model is unreliable in general. They are predictable consequences of working from incomplete context, which is why the fix is nearly always upstream in what was supplied rather than downstream in how the answer was worded.

What this hub covers next

This hub's eight guides now cover the prompt structure itself, giving a model the project context it needs before that structure even matters, describing a bug so it can actually be fixed, iterating without breaking working code, when to start fresh instead of continuing, the two failure modes that most often bring people here, and telling a real slash command apart from an invented one. This silo's original scoped backlog is complete; new guides get added here as real gaps surface, the same as every other hub on this site.