Craft
Context Is the Thing AI Can't Retrieve for You
Why AI writes fluent, generic specs. Context is four things with very different retrievability — and retrieval cannot find what was never written down.
Ask any capable model for a PRD and you get something competent: correct structure, plausible sections, reasonable acceptance criteria. Read it closely and the same quality appears every time — it could be about almost any product.
That is not a model-quality problem, and it does not get solved by a better prompt. It is that the things which would make the document specific are, for most teams, not written anywhere a model can reach.
Context is four things, not one
They get lumped together, and they have wildly different retrievability. That gradient is the whole story.
1 · Stated facts. What the product does, how a flow works, what an endpoint returns. Lives in docs, specs and code. Retrieval handles this well, and this is what most "connect your AI to your workspace" tooling actually delivers.
2 · Decisions and their reasoning. Why the limit is 20, why the invite flow has no approval step. Retrievable if recorded. For most teams it is not — it is in a thread from March, a meeting nobody minuted, or one person's head.
3 · Which constraints are real. Almost nothing in a codebase or a doc distinguishes "this is a hard obligation" from "we have always done it this way." Both appear as the status quo. Nobody writes "this one is negotiable," so a model — like a new hire — cannot tell them apart.
4 · Taste and standards. What your team considers good enough. How much edge-case coverage is expected before review. Whether a metric without a baseline gets sent back. Effectively never written anywhere.
Categories 1 and 2 are a retrieval problem. Categories 3 and 4 are a writing problem, and no tool fixes them by indexing harder.
The limit nobody mentions
Retrieval finds what exists. It cannot find what was never recorded.
This is obvious stated plainly and routinely ignored in practice, because the pitch for connecting AI to a workspace implies the workspace contains the answers. It contains the artifacts. The reasoning behind the artifacts is usually absent — and the reasoning is what you wanted.
So a model with full access to every document you own can still confidently propose the approach you rejected two years ago, for reasons that are still valid, because nothing it read mentioned that you considered it. It is not hallucinating. It is working from the same information a new hire would have, and reaching the same conclusion a new hire reaches.
What a context-free spec looks like
The tell is not errors. It is the absence of specificity:
- It never names a constraint that is actually yours.
- It never references a prior decision, because it knows of none.
- Its edge cases are the generic ones — empty state, network error — rather than the ones your domain produces.
- Its acceptance criteria use invented entities rather than the nouns your team uses.
- Nothing in it could be wrong, because nothing in it is specific enough to be wrong.
That last point is the dangerous one. A generic spec is hard to reject in review — there is nothing to disagree with — so it passes, and the specificity gets supplied later by whoever implements it. This is the same failure as a fluent, empty PRD, arriving faster and in greater volume.
What changes with context
Not a demo — a description of the difference, which is narrower and more useful than the marketing suggests:
It stops proposing rejected approaches. The single biggest improvement, and it comes entirely from having decisions recorded with their reasons.
Its criteria reference your entities. Workspace, cohort, facing, whatever your domain actually calls things — rather than plausible substitutes that then need translating.
It flags conflicts. "This contradicts the June decision on seat limits" is only possible if the June decision is reachable. This is the highest-value behaviour available and it is entirely downstream of your records, not of the model.
Its edge cases become domain-specific. Generic edge cases are the ones you already think of. The valuable ones come from knowing what your product does.
What to write down first
If you are going to record anything, the order matters. Ranked by how much a model — or a person — gains per line written:
- Decisions with their rejected options. Nothing else encodes this. Code shows what you built, never what you chose against.
- Which constraints are hard. One word per constraint: obligation or habit.
- Domain vocabulary. What your nouns mean, precisely, including the ones you use differently from the rest of the industry.
- What "done" means here. Your review bar, written once.
You will notice this is the same list as a decision record. That is not a coincidence — the context a model needs and the context a new colleague needs are the same context, and writing it once serves both. Which is the argument for doing it at all, because "so the AI works better" is a thin reason to change how a team writes, and "so anyone joining can understand why" is not.
What context does not fix
Worth being clear about the boundary, because the honest version is more useful than the optimistic one.
Context makes a spec specific. It does not make it right.
Whether you are solving a problem worth solving, whether the users you are imagining behave the way you think, whether this is the correct bet for the quarter — none of that is retrievable, because it is not a fact about your past. It is a judgment about the future, and it stays yours.
A model with perfect context will write a beautifully specific PRD for the wrong feature, and it will be harder to spot than the generic version, because everything in it sounds like it came from someone who knows your product.
That is the trade worth understanding before you get excited about context. It removes one class of error — vagueness — and leaves the more expensive one exactly where it was.
FAQ
Why is AI-written PRD output generic? The things that would make it specific — rejected approaches, real constraints, your standards — are mostly not written anywhere a model can reach.
Does connecting it to our docs fix it? Partly. Retrieval handles stated facts. It cannot surface reasoning that was never recorded.
What should I write first? Decisions with rejected options, then which constraints are hard, then domain vocabulary, then your definition of done.
Can context make it correct? It makes it specific. Whether you are solving the right problem is still yours.