Which Kind of "Not Knowing" Are You Actually Missing

Whenever the author brings a problem to Claude, he starts by sorting his unknowns into four boxes. The bigger the job, the easier it is to fall into the last two boxes — the things you never even noticed, or the things so obvious you'd never think to write them down.

Original figure: before starting work, the author sorts his unknowns into four types — the bigger the project, the easier it is to fall into the last two. Source: X · Thariq

The author observes that the strongest collaborators he's seen — people like Boris Cherny or Jarred Sumner — carry relatively few unknowns: watching them write prompts, they clearly know what they want and stay in sync with both the codebase and the model's behavior. But they still leave room for unknowns. In a sense, reducing your unknowns and getting ahead of them is the core skill of working with Claude — and it's a skill you can train up by working with Claude itself.

Instructing Claude: Why Both Too Much Detail and Too Little Backfire

Briefing Claude on a task is like walking a tightrope. Spell it out too precisely, and it'll follow your steps to the letter, even when it should change course partway through. Leave it too vague, and it'll guess based on generic industry best practices that may not fit your situation. When you haven't accounted for your own unknowns, you fall off on either side: you don't know which stretch of the path has a pothole and which is clear, yet you still want it to turn when a turn is called for.

The good news is Claude can help you surface unknowns faster: it can search a codebase and the web far faster than you can, it knows more than you do on most topics, and it can iterate quickly from failure. The most important step in this process is telling it your starting point: where your thinking currently stands, how deep your experience is with the problem and the codebase, so it can work alongside you like a thinking partner. The author also notes that in almost all these scenarios, a single HTML page is the best way to visualize an idea and put it right in front of you.

The techniques below are laid out across the three stages of "before, during, and after implementation." The author says he doesn't use all of them every time, but it's a toolkit worth keeping on hand.

Original figure: guiding Claude is a delicate balance — being too specific and too vague both backfire. Source: X · Thariq

First, Let Claude Find What You Don't Know You Don't Know

The single most useful thing you can do when starting out is figure out your own blind spots first. If you're building a feature in an unfamiliar part of the codebase, or doing something you're not experienced with like a design iteration, you likely have a whole pile of unknown unknowns: you don't know what to ask, don't know what "good" looks like, don't know what's already been tried, and don't know which pitfalls to avoid.

I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better.

I don't know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?

Original figure: the author's compiled collection of techniques for surfacing unknowns. Source: X · Thariq

Some Things You Can't Put Into Words, But You Know Right Away If They're Wrong

This kind of unknown is one where you can't state the criteria, but the moment something's in front of you, you know instantly whether it's right — that's an "unknown known." These are best dug up early through brainstorming and prototyping: discover them once you're already writing code, and the cost is far higher — a small tweak to the spec can force a complete rewrite of the implementation, and it's also harder to get Claude to roll back earlier changes. The author almost always starts from an exploration or brainstorming phase, using it to pin down the project's scope — wide enough, but not too wide.

Brainstorming & Prototyping

Say you just want to see what adding a button to some interface would look like, without actually wiring up a backend route or maintaining an extra piece of front-end state. Visual design is especially hard for the author to put into words, but once the options are laid out in front of him, he knows immediately which one he wants — so he'll ask for several design directions at once and react to them side by side.

I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them.

Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the real app.

Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate.

Let Claude Interview You

Brainstorming usually still leaves some fuzzy points. This is when you flip it around and let Claude question you one at a time, giving it a bit of background on your problem to guide the questioning — with priority given to questions whose answer would actually change the architecture.

Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.

When You Don't Know How to Say It, Just Show It the Code

Sometimes you simply don't have the words for what you want, or it's too complicated to explain. In these cases, the best reference is the source code itself. Diagrams, docs, and screenshots all work, but the single best reference is source code. If some library out there already implements the behavior you want, or there's a design component you really like, just point Fable at that folder and tell it what to look at — even if the code is in a different language, it still works.

Claude Design works the same way. You don't have to hand it a file (though you can) — you can point it at a module you like on some webpage, and it reads the underlying code rather than just a screenshot of it. That gives it far richer detail about the markup, structure, and how the component is actually built.

This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client.

Implementation Plan: Lead With What's Most Likely to Change

Before starting, the author has Claude produce an implementation plan for him to review first, with emphasis on the parts most likely to change: the data model, type interfaces, anything user-facing. Mechanical refactoring gets pushed to the end — that part he just trusts it with. This way, the plan puts what you actually need to adjust right in front of you first.

Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part.

Once Work Starts, Have Claude Log Its "On-the-Fly Decisions" as It Goes

No matter how thorough the plan, unexpected unknowns will always surface during implementation. Once he's satisfied with the plan, the author opens a fresh session, drops the spec file and prototype into the prompt, and lets an agent implement it. But partway through, Claude might hit some edge case in the code that forces a change of approach. He has Claude Code maintain a temporary implementation-notes.md (or .html) file, logging the decisions it makes along the way, so he can review and learn from them on the next attempt.

Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going.

Before You Merge, Let Claude Quiz You First

Once the work is done, there are two techniques for wrapping up. One is packaging the result into a document you can take for approval; the other, the most critical one, is having Claude turn around and quiz you.

Packaging a Persuasion Doc

Delivering something important always comes with the step of getting it recognized and approved. Building in a bit of "persuasion" and "explanation" into the final doc has two benefits: reviewers start out with the same unknowns you once had, so they'll understand it faster; and domain experts who want to confirm you've accounted for the pitfalls and common failure modes will sign off faster too.

Original figure: package the prototype, spec, and implementation notes into a single doc ready to take for approval. Source: X · Thariq

Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF.

Quiz: No Pass, No Merge

I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass.

How He Applied This Method to Editing the Fable Launch Video

Fable's launch video was edited entirely by Claude Code. This was a completely new domain for the author, who considers himself a total outsider to it. The whole process ended up stringing together every technique covered above: starting from what he already knew, he drew out his unknowns one by one.

The author's closing advice: the stronger the model, the more you can get done with the right method. When a long-running task comes back wrong, it's often a sign you need to spend more time defining your own unknowns, or write an implementation plan that gives Claude room to work within those unknowns on its own. Every round of explaining, brainstorming, interviewing, prototyping, and referencing is a way of surfacing what you don't know while it's still cheap, so you don't have to pay for it later when it's expensive. So the next project should start with a single line: get Claude to help you find your unknowns.

The first step isn't rushing to write requirements — it's sorting "not knowing" into four types first. Spell it out too precisely and it won't dare change course; leave it too vague and it'll guess blindly. Figure out which box you're stuck in first — the bigger the job, the easier it is to fall into the last two boxes, the blind spots you're not even aware of.

• Known known: what you spell out in the prompt (button in the top-right corner).
• Known unknown: knowing you haven't figured it out yet (not sure if the list needs pagination).
• Unknown known: never written down, but you know it's wrong the moment you see it (color scheme too jarring, rejected on sight).
• Unknown unknown: never even considered it, don't even know how good it could be (turns out code can auto-cut pauses from a video).

Finding unknowns isn't a one-time step before you start — it runs through the before, during, and after stages of the work. The author lays out 8 techniques spread across these three stages, each one about digging out blind spots while it's still cheap. Every technique in the full article comes with an original English prompt, ready to copy.

The author repeatedly stresses: every round of brainstorming, interviewing, prototyping, and referencing digs out what you don't know while it's still cheap, so you're not stuck redoing work once it gets expensive.