From Blind Spot Scanning to Test-Gated Merges: I Rewrote My AI Coding Workflow

For the same requirement, I rewrote the prompt three times.

First time: the AI modified old logic it shouldn’t have touched. Second time: I listed everything it should not touch — and it stuck to the list, but the result felt completely wrong. Third time: I spelled out every detail, and it followed orders rigidly, ignoring a perfectly good existing solution in the codebase.

I used to think the problem was that my prompts weren’t detailed enough.

Then I read Anthropic engineer Thariq’s A Field Guide to Fable: Finding Your Unknowns, and realized this loop is a dead end.

Too detailed, and the AI won’t adapt when it should; too vague, and the AI guesses what you want based on “industry best practices.” You bounce between “too detailed” and “too vague,” never finding the sweet spot. Because there’s a whole set of information you never said — or didn’t even know you knew — and the AI guesses every time. No amount of prompt tweaking can cover those gaps.

After reading that article, I tore down my entire AI coding workflow and rebuilt it. This isn’t a translation or summary — I’ll walk you through how I understood the method step by step, including the parts I got wrong. The pitfalls I fell into are probably the same ones you will.

1. When AI Goes Off Course, It’s Guessing

Start with a scenario you’ve definitely seen.

You tell the AI: “Add WeChat login to the authentication system.”

Half an hour later it delivers. You look at it: the UI style clashes with the existing login page, it created a bunch of new fields in the user table, and it even helpfully “optimized” the original phone-number login logic.

Your first reaction might be: this model is no good.

Thariq offers another explanation. He borrows an old saying: The map is not the territory.

• The map is what you give the AI: prompts, rules, plans, acceptance criteria.
• The territory is where the AI actually works: the real codebase, historical baggage, your taste, the silent rules like “we never do it that way in our project.”

The gap between the map and the territory is unknowns.

When the AI encounters an unknown, it doesn’t freeze — it keeps guessing, guided by “industry best practices” and “what a normal person would probably want.” The more complex the task, the more unknowns, the more guesses, and the deviations accumulate. What you end up with is that “it works, but it’s not at all what I wanted” result.

Thariq said something that made me pause for a long time: something like “Fable is the first tool that made me feel like the quality of the output was limited by my ability to clarify unknowns, not by the model itself.”

The stronger the model, the truer that statement becomes.

2. Four Types of Unknowns: Where I Stepped on My First Pitfall

Thariq breaks unknowns into four categories. This classification directly determines which method to use for each — worth going through one by one.

In plain English:

• Known knowns — information you already wrote into the prompt. “Add WeChat login, don’t modify phone login, reuse existing UI components.”
• Known unknowns — questions you’re aware of but haven’t answered yet. “Should new users be forced to bind a phone number? I haven’t decided.”
• Unknown knowns — you have a standard in your head, but you assume “surely that goes without saying.” For example, you hate flashy UIs; or your project never uses modal dialogs.
• Unknown unknowns — you didn’t even know it was a problem. Say you’ve never implemented WeChat login and have no idea that the unionid requires binding to the Open Platform first.

Category 3 is the most insidious. The AI can’t read your mind — you didn’t say it, so it follows general practice — and when the result comes back, you say “that’s not the feeling I wanted.” It followed every step correctly, but that unspoken standard of yours was never communicated.

Category 4 is the most dangerous. With category 3, you can catch it when you see the output. With category 4, you don’t even know to ask about it — it just lurks there, waiting to explode after you go live.

The first time I read this, I got it wrong. I thought: “Blind spot scanning is for finding category 3 — surfacing the standards I know but haven’t said.”

Wrong. Blind spot scanning is for category 4.

I realized later: standards you know but haven’t said can’t be scanned — they’re in your head, not in the task context where the AI can find them. The only way to uncover those is to show you something and get your reaction — prototypes, reference examples, the AI interviewing you back. Blind spot scanning is for the pitfalls you don’t even know exist: webhooks that replay, potential duplicate payments, test environments that can’t configure callback URLs… You can’t proactively ask about these; you need the AI to scout them for you.

Different unknowns need different weapons. Use the wrong weapon, and you’ll think “this method doesn’t work” — but you’re just aiming at the wrong target.

3. Before You Start: Find the Pitfalls, Then Implement

Once you understand the four types of unknowns, the whole “pre-implementation” flow makes sense. Here’s what I do now, case by case.

1. Blind Spot Scanning — for “Unknown unknowns”

When entering an unfamiliar domain, change your first sentence from “Help me implement” to:

Don’t implement yet. First, do a blind spot scan for this task: what pitfalls, edge cases, and decisions that need to be made in advance am I probably not even aware of? Rank them by “could cause rework / affect architecture / affect data security.”

That last ranking instruction is critical, otherwise the AI will give you a list of 30 items and bury the most deadly ones in the middle.

2. Multiple Prototypes — for “Unknown knowns”

I can’t articulate standards like aesthetics, but I know when I see them. So:

Don’t hook up real logic yet. Build 4 prototypes with completely different directions using fake data. I’ll look at them and tell you which one I like and which one I hate.

Make prototypes cheap: fake data, single file, no real business logic. Their only job is to surface the “goes without saying” standards in your head while it’s still cheap to change things.

3. Let the AI Interview You — for “Known unknowns”

Interview me, one question at a time. Prioritize questions whose answers would change the architecture, data model, or user flow.

One question at a time — this detail matters. If the AI fires 20 questions at once, you’ll get numb and answer only the easy ones.

4. Implementation Plan — the last gate before starting

Ask for a plan first, and explicitly require: put the parts most likely to change first — data model, APIs, user flow. Leave mechanical refactoring for last; I trust it there.

4. During Implementation: Where I Stepped on My Second Pitfall

Even with thorough planning, unknowns pop up during implementation. Thariq emphasizes this in the article. The AI only hits real constraints when it dives into the codebase — a component has a different name than in the plan, a test assumes only two login methods.

Here I stepped on my second pitfall.

Imagine: the AI is implementing and finds that the plan says use LoginButton, but the codebase uniformly uses AuthButton with the same functionality. What should it do?

My original instinct: stop and ask me.

Wrong again. The reasonable thing is: reuse the existing AuthButton, log the deviation, and keep going.

My logic then was “if there’s uncertainty, it should ask me.” But think: if the AI stops for every naming difference, you’ve essentially hired an intern who knocks on your door every five minutes — where’s the automation?

The dividing line is risk, not whether the plan was deviated from:

• Small codebase adaptations (component names, test file locations, code style): choose the conservative option, log it, move on.
• High-risk decisions (modifying user data, merging accounts, deleting fields, changing permissions, irreversible operations): must stop and ask — no guessing.

And where to “log it”? Thariq has the AI maintain a temporary implementation-notes.md file that records four types of information: what assumptions it made, why it chose this approach, where it deviated from the plan, what edge cases it discovered.

This file’s job is to turn the guesses the AI would have made silently into a record you can review and correct. When the AI does complex work, you can catch a wrong line of code; but if it makes a whole set of judgments you never knew about, you have no entry point to check.

5. After Completion: Don’t Merge Until All Tests Pass

I never had this step before, and it’s the biggest change this article made to my workflow.

Previously, after the AI finished, tests passed, I glanced at the diff, and merged. Felt very efficient.

But Thariq pointed out a problem: a diff only tells you “files changed,” not “behavior changed.” You’re in a dangerous state:

The code was written by the AI, it runs, but you don’t know why it wrote it that way or what might break.

He calls this losing “ownership of understanding” of the system. The fix has two steps.

First, ask for an explanation report. A “✅ done” summary is useless. You need: what problem was solved, what were the key decisions, what changed from the original plan, what edge cases exist, what risks remain.

Second, have the AI quiz you back.

Create a quiz for me about this change, covering motivation, business logic, and edge cases. When I answer wrong, don’t give the answer — ask me what I think first.

Thariq’s rule: Don’t merge until you pass the quiz.

The first time I saw this, I thought it was performance art. Then I tried it once and was convinced. The AI asked me, “If WeChat doesn’t return a unionid, what path does the current flow take?” I froze — that moment I admitted my understanding of the change was only “it probably added a login method.”

The question you can’t answer is your next unknown.

6. What the Reshaped Workflow Looks Like

After learning this whole framework, I rewrote my AI coding workflow. Compare:

Before: Think of requirements → write the most detailed prompt possible → AI implements → see the result is wrong → add more requirements and repeat → keep looping until it works.

Now:

• Before starting: For unfamiliar domains, do a blind spot scan. For unarticulated standards, use multiple prototypes to surface them. For unclear decisions, let the AI interview me. Finally, produce an implementation plan, focusing on the parts that might change.
• During implementation: The AI maintains implementation notes. Small adaptations are logged and continued; touching data, accounts, or architecture must stop and ask me.
• After completion: Explanation report + quiz. Only merge after passing.

Before, I was optimizing prompts. Now, I’m managing unknowns.

What was slow about the old loop? Every time the result was “wrong,” some unknown remained hidden until after implementation — code was written, direction was locked, and rework required overturning everything. Every action in the new flow — blind spot scan, prototypes, interview, quiz — does the same thing: dig out unknowns while it’s still cheap to change them.

Models will only get stronger. The gap between you and an expert won’t be in who writes a longer prompt — it’ll be that after both give the AI a day’s work, one person gets merge-ready code, and the other gets something that looks like it works but nobody knows where it will break.

The difference is: who knows what they don’t know.

Finally, I packaged this whole workflow into a CLAUDE.md file — the pre-implementation blind spot scan, prototypes, interview, implementation plan; the during-implementation notes and stop-and-ask rules; the post-completion explanation report and quiz — all written as conventions that Claude Code can directly follow.

Project URL: https://github.com/bozhouDev/finding-unknowns-skills

Just drop it into your project root and go.