When the model is no longer the bottleneck: Thariq's Fable 5 lessons, in Chinese

On 4 July 2026, Thariq — a core engineer on the Claude Code team — posted a thread that hit ~500K views in a weekend. The single sentence that landed: with a model this capable, what’s holding you back isn’t the model — it’s the things you don’t know you don’t know.

This is a Chinese-adapted translation of that thread. The structure (four types of unknowns + a three-phase SOP) is universal. Where the original uses Western examples (Boris, Jarred), this version uses ones that make sense for developers shipping in the Chinese AI ecosystem.

Original (English): Thariq on X · surfaced by 新智元 on 2026-07-04.

The map is not the territory

Your prompt, your skills, your context — that’s the map. The thing actually doing the work — the codebase, the real world, the constraints you can’t wave away — that’s the territory. The gap between them is what Thariq calls the unknown.

Every time the model hits an unknown, it has to guess — it picks what it thinks you meant. The longer the task and the more moving parts, the more guesses, the more places guess-work can drift from what you actually wanted.

With weaker models, the bottleneck was the model. You brute-forced clarity into the prompt and prayed. Fable 5 is the first model Thariq has worked with where the bottleneck has shifted: it’s now your ability to clarify the unknown.

And clarifying is a tightrope. Too specific, and the model follows your instructions literally even when the situation calls for a turn. Too vague, and it falls back on “industry best practice” — which may not match your situation. Skip the unknown-work, and you crash on both ends: potholes you didn’t know were there, clear roads you didn’t trust.

The four types of unknowns

Thariq breaks “the unknown” into four buckets. In plain Chinese: what you know you know, what you know you don’t, what you don’t know you know, and what you don’t know you don’t.

• 已知已知 (known knowns) — written into the prompt. You know exactly what you want.
• 已知未知 (known unknowns) — you haven’t figured it out, but you know you haven’t figured it out.
• 未知已知 (unknown knowns) — obvious enough you didn’t bother writing it down, but obvious enough that you’d nod “yes, that’s it” the moment you saw it. Aesthetic judgements live here.
• 未知未知 (unknown unknowns) — you haven’t even thought to ask. You don’t know what good looks like. You don’t know what previous attempts have failed at.

The last one is where everything breaks. The top agentic coders — Anthropic’s Boris and Jarred are Thariq’s examples — don’t have zero unknowns. They just have far fewer. When you read their prompts, the “what I want” is unmistakable, and they know both the codebase and the model well enough to write prompts that fit both.

But even they plan for unknowns. In some sense, reducing unknowns and planning for them is the craft itself. The good news: it’s learnable. And the best practice partner is Claude itself — it scans your codebase and the whole internet faster than you do, and it picks itself up after a failure faster than you do.

Three-phase SOP

Here’s the SOP Thariq uses — Chinese-adapted, lightly edited. Each step is cheap if you do it before the code is written, expensive if you don’t.

实施前 · Pre-implementation (5 moves)

1. 盲区扫描 (Blindspot pass) — entering an unfamiliar codebase or a non-trivial task, just say: “Do a blindspot pass. Find my unknown unknowns and walk me through them.” The model surfaces what you didn’t know to ask, and in the process teaches you how to write a better prompt next time.
2. 头脑风暴 + 原型 (Brainstorm + prototype) — for visual design and other “you’ll know it when you see it” work, don’t connect the backend yet. Have Claude spin up one HTML page with four wildly different directions; you pick. Catching unknown-knowns at the prototype stage is essentially free. Catching them after specs are signed off means a tiny wording change can require rewriting half the codebase.
3. 采访 (Interview) — let the model ask you questions one at a time. Prioritise the ones whose answers would change the architecture.
4. 给参考 (Give references) — when you can’t articulate it, don’t. The best reference is source code. Point Claude at the folder or module — even in a different language, it reads the underlying code rather than a screenshot, so it picks up ten times more detail than you could describe.
5. 实施计划 (Implementation plan) — before any code, have Claude write a plan for your review. Put the things most likely to change at the top: data model, type interfaces, user-visible flows. Mechanical refactors go at the bottom — the model is reliable there.

实施中 · During implementation (1 move)

Have Claude maintain an implementation-notes.md. The plan will inevitably meet an edge case that pulls it off course. When that happens, take the conservative path and log it under ## Deviations. Next time you (or a teammate) revisit the code, those notes are the fastest way back into the original reasoning.

实施后 · Post-implementation (2 moves)

1. 打包推介 (Packaged pitch) — bundle the prototype, the spec, and the notes into one document that can be sent to whoever needs to approve it. They have the same unknowns you did. This doc clears them in one pass.
2. 做测验 (Quiz yourself) — have Claude generate a quiz about the change. Pass the quiz before merging. Reading the diff only shows you what changed; most of the behaviour is hidden in code paths you didn’t touch. The quiz is the only way to know whether you actually understand the new system.

Thariq’s own example: editing the Fable launch video

The most convincing example is Thariq’s own. The Fable launch video — three minutes of polished output — was edited end-to-end with Claude Code. Thariq is not a video editor.

He started with what he knew: Claude can edit video with code, can transcribe, but he wasn’t sure about transcription accuracy or whether ffmpeg could precisely cut “um”s and long pauses. So he had Claude explain how Whisper-class transcription works and whether ffmpeg could do the cuts he wanted.

For subtitles that lock to every spoken word, he wasn’t sure that was feasible, so he had Claude build a quick prototype with Remotion + the transcript.

When the first cut looked flat, he knew it was the colour grade. His first instinct was to have Claude generate a few variants for him to pick. Picking is when he realised he didn’t actually know what “good colour grading” looked like. So he pivoted — first have Claude teach him what colour grading is, then go back to picking.

Figure out your unknown, then go back to choosing.

What this means for the rest of us

Models keep getting stronger. The distance between “what the model can do” and “what you can ship” is increasingly determined by how well you can ask. The Claude Code team themselves have started saying their day job has shifted from “verify Claude did it right” to “verify it did the right thing.”

Every explanation, brainstorm, interview, prototype, and reference is a cheap way to surface something you didn’t know — before the cost of discovering it goes up. A long task returning a wrong answer is almost never the model’s fault. It’s that the unknown never got cleared.