Notes from Thariq's X Article A Field Guide to Fable: Finding Your Unknowns.
The useful frame is not that stronger models remove ambiguity. The useful frame is that stronger models make ambiguity more visible.
When a coding agent can handle longer-horizon work, the bottleneck moves from "can it write the code?" to "did I help it understand the real territory well enough to make good decisions when the prompt runs out?"
Thariq calls the gap between the prompt and the real work unknowns. Agentic coding gets better when you deliberately discover those unknowns before, during, and after implementation.
The article uses a classic four-part frame:
1. Known knowns — what you explicitly tell the agent. This is the prompt.
2. Known unknowns — things you know are unresolved: tradeoffs, missing decisions, unclear requirements.
3. Unknown knowns — tacit expectations you would recognize if you saw them, but would not naturally write down.
4. Unknown unknowns — blind spots: what you have not considered and may not know how to ask about.
The most dangerous category is not always the unknown unknown. Unknown knowns can be just as expensive because the human thinks the expectation is obvious while the model cannot see it.
That is why "be more detailed" is only a partial answer. Sometimes you do not yet have the language for what matters. Sometimes you need the model to help you discover the language.
A weak way to use a coding agent is to treat it as a downstream executor: write the prompt, wait, review the diff.
Thariq's stronger pattern is to use Claude as a thought partner that helps expose the shape of the problem. It can search a codebase, inspect patterns, compare approaches, prototype options, and recover quickly from failed attempts.
The important move is to tell the model where you are starting from:
That context lets the model spend effort on the right unknowns instead of filling gaps with generic best practices.
The first technique is a blind-spot pass.
Before asking the agent to build, ask it to inspect the situation and tell you what you might be missing. This is especially useful when you are working in an unfamiliar area of a codebase or in a domain where you do not yet know what good looks like.
Example shape:
> I am adding a new auth provider, but I do not understand the auth modules in this codebase. Do a blind-spot pass. Find my relevant unknown unknowns and help me prompt you better.
This is a good pattern because it changes the first task from implementation to orientation. The agent can teach you enough of the terrain that your next prompt becomes sharper.
Some requirements are hard to verbalize until you see a concrete option.
That is especially true in design and product work. You may not know how to describe the toolbar, dashboard, color grade, or onboarding intervention you want. But if the agent shows you four different directions, you can react.
This is where HTML artifacts are useful: quick, inspectable, disposable surfaces for making vague taste visible.
The point is not to make a perfect mockup. The point is to convert unknown knowns into known knowns before production implementation makes them expensive.
A good prompt shape:
> I want a dashboard for this data but do not know what is possible. Make a single HTML page with four very different design directions so I can react to them.
The same applies outside design. Brainstorming ten possible interventions before touching the code can reveal a much better problem framing than the one you started with.
After brainstorming, the agent should interview you.
The important instruction is to prioritize questions where the answer changes the architecture, data model, UX flow, or irreversible implementation path.
Example shape:
> Interview me one question at a time about anything ambiguous. Prioritize questions where my answer would change the architecture.
This is much better than dumping twenty questions at once. One-question-at-a-time keeps the human engaged and lets each answer update the next question.
The goal is not to remove all ambiguity. The goal is to remove the ambiguity that would cause expensive wrong turns.
When you cannot describe what you want, point to a reference.
The best reference is often source code: a library, module, component, workflow, or implementation in another language that has the semantics you want.
This matters because code carries details that prose forgets:
Instead of explaining a rate limiter from scratch, point the agent at a Rust crate and ask it to reimplement the same semantics in TypeScript.
References reduce unknowns because they let the model read the territory rather than rely only on your map.
A plan is most useful when it leads with the decisions the human is likely to tweak.
Mechanical refactors can go lower in the document. The top should focus on data model changes, type interfaces, user-facing behavior, and any decision that creates future coupling.
This is a subtle but important planning principle: do not make the reviewer spend attention where they have little leverage.
A good implementation plan is not just a checklist. It is a decision surface.
Even a good plan will hit unknowns during implementation.
Thariq's pattern is to ask the agent to maintain an implementation-notes.md file. When the agent finds an edge case or has to deviate from the plan, it should choose the conservative path, keep going, and log the decision under a deviations section.
This gives you a record of what the model discovered while inside the territory.
It also makes the next attempt better. If the implementation goes sideways, the notes preserve the real constraints instead of leaving you with only a messy diff.
After a long agentic coding session, the diff may not be enough to understand what happened.
The article suggests packaging the result into an explainer: context, intuition, what changed, why it changed, and what reviewers should pay attention to.
The sharper version is a quiz. Ask the agent to teach you the change and then test whether you actually understand it. Merge only after you can answer perfectly.
That may sound theatrical, but it points at a real problem: AI can create more change than the human has cognitively absorbed. A quiz is a guardrail against approving code you do not understand.
The central lesson is simple:
> Long-horizon agent work fails when the model has to make too many hidden guesses.
Better prompting is not only about adding more instructions. It is about building a workflow that discovers hidden guesses:
The stronger the model gets, the more this matters. If the model can do more work in one run, then one missing assumption can propagate farther.
Agentic coding becomes less like handing off a ticket and more like repeatedly aligning the map with the territory.