Teardownspublic

A field guide to Fable

Someone from the company that built the model, explaining how to use it. Which makes the six techniques trustworthy and the closing claim the least trustworthy part.

6 techniques · 3 newSource video — youtube.com/watch?v=SNb2CFrUcs8 ↗

Trust splits two ways inside the same talk. It is someone from the company that built the model explaining how to use it, so the six techniques are exactly the territory the makers know best and they hold up. The closing part’s “tradeoffs are not real” is a self-report about their own product, and its entire evidence is “I built this deck in four hours the night before.” Three of the six techniques turned out to be things I already do under other names, and three I didn’t.

The Unknown Matrix — four boxes for what you don't know Known knowns the things I want usually the only box that reaches the prompt Known unknowns things I know I haven't looked into filled in by interviews and references Unknown knowns too obvious to write down taste you only recognise when you see options Unknown unknowns never considered at all this is the box a blindspot pass aims at ⇒ the premise: the bottleneck isn't the model, it's my ability to match my map to the territory
What reaches the prompt is usually the top-left box alone. Getting the other three out is what the talk is about.

What the talk says

The premise is one line — the bottleneck is not the model but my own ability to match map to territory and find my unknowns. So the whole back half is about using the model itself to surface them.

⚠ A limit first. I watched from 9:34 onward, out of 18 minutes. The first half is outside this document, and everything below rests only on the back half.

The six techniques:

Technique Which box What it actually asks for
Blindspot pass Unknown unknowns “I don’t know this module at all. Do a blindspot pass, find the relevant unknown unknowns, and help me prompt better” → it sweeps the module and flags gotchas like “this is a complicated dead end” or “go look at the history”
Brainstorms & prototypes Unknown knowns “I have no visual sense. Build one page holding four completely different design directions — so I can react to them”
Interviews What I failed to state “Interview me about the ambiguous parts, one question at a time — prioritise questions whose answer would change the architecture”
References Known unknowns “This behaviour in this library is exactly what I want. Read it and reimplement the same semantics on our side”
Implementation notes What surfaced mid-run “Keep a notes file. When an edge case pulls you off plan, take the conservative option, record it under Deviations, and keep going”
Quizzes My own comprehension “I want to check I understood this change. Build a report of context, intuition and what was done — plus a quiz at the bottom I have to pass”

The fourth is especially good. “The best way to give a map is to give another map” — the language and system don’t have to match. Want a React component? Hand over an HTML mockup as the map.

Three already, three new

six techniques — three were things I already did under other names, three were not ① Blindspot pass ask for the traps before entering unfamiliar code new ② Brainstorms generate several directions, then choose already ③ Interviews make it ask back, and see my own gaps already ④ References hand over a real example of the behaviour I want already ⑤ Implementation notes record where the plan was left, under Deviations new ⑥ Quizzes test my own understanding before merging new ⇒ trust splits inside one talk — the six techniques are what the makers know best "Tradeoffs are not real" is a self-report on their own product, evidenced by one four-hour slide deck
Three of six already being familiar isn't bad news. It means two different routes arrived at the same place.

The fifth is the big one. “When an edge case pulls you off plan, take the conservative option, record it under Deviations, and keep going” — one line that leaves a trace without stopping. Until now I had two modes: stop and ask (slow), or proceed and lose the reason later. There was a third.

The sixth I also didn’t do. The idea of being quizzed by the model on “did I understand this?” after the work is done hadn’t occurred to me. Code review looks at the code, not at my comprehension.

The first is familiar in shape but different in timing. Going into unfamiliar code, I asked questions after reading. I have never asked for the traps before going in.

What broke when I checked

The closing part is the weakest. “Tradeoffs are not real” — instead of prioritising this over that, do all of it and let reality show you the tradeoff. Good, fast and cheap: pick three.

There is exactly one piece of evidence — the slide deck built in four hours the night before. A deck is cheap to redo and nearly free to get wrong. The things I work on differ from that by orders of magnitude in failure cost. What holds for one class of artifact cannot generalise to “tradeoffs are gone.”

And this talk comes from the company that built the model. That is not a flaw so much as a reading instruction — the six techniques are the territory the makers know best and carry high trust; product-effect claims carry the least. Trust has to be divided inside a single source.

Verdict

What Call
⑤ Deviations log Adopt. The third path: leave a trace without stopping
⑥ Self-quiz before merge Adopt. A slot that measures my understanding, not the code
① Blindspot pass Adopt. Before going in, not after reading
②③④ Already doing. Two routes arrived at the same place
“Tradeoffs are not real” On hold. Evidenced by one low-stakes artifact

One thing deserves fairness. Part three of the talk is not about gains but about loss. “You do in hours what might have taken weeks — how can you not laugh, how can you not almost cry?” He loved the feeling of turning a codebase over in his head and says he can’t go back. It is unusual for someone on the selling side to talk about what their product took away — and that passage, being the least saleable part of the talk, is the part I trust most.