How to Master Fable 5 with Claude: Insights from a Core Engineer

Claude Code core engineer Thariq posted a concise insight: with a model as strong as Fable 5 the bottleneck is no longer the model itself but the user's ability to articulate the problem.

He explains the “map vs territory” metaphor: prompts, skills, and context are the map, while the codebase, real‑world constraints, and execution environment are the territory. The gap between them is the “unknown”. When the model encounters an unknown it must guess, and longer tasks increase the chance of error.

Thariq categorises unknowns into four groups:

Known‑known : explicitly stated in the prompt.

Known‑unknown : you know you don’t know.

Unknown‑known : obvious aspects you omit, such as aesthetic preferences.

Unknown‑unknown : things you haven’t even considered.

He proposes a closed‑loop SOP split into pre‑implementation, implementation, and post‑implementation phases.

Pre‑implementation (five steps)

Blind‑spot scan : ask Claude to identify unknown‑unknowns in a new codebase.

Brainstorm & prototype : let Claude generate multiple HTML mock‑ups before committing to backend work.

Interview : have Claude ask questions whose answers could change the architecture.

Reference : point Claude to relevant source code or libraries instead of vague descriptions.

Implementation plan : let Claude draft a plan that prioritises high‑risk changes.

During implementation

Maintain an implementation‑notes.md where Claude records deviations and chosen conservative solutions when edge cases arise.

Post‑implementation (two steps)

Package the prototype, specifications, and notes into a review‑ready document to surface hidden unknowns for stakeholders.

Generate a quiz from the changes; only after passing does the code get merged, ensuring deep understanding beyond a superficial diff.

Thariq also shares a personal example: using Claude to edit a Fable 5 release video despite having no video‑editing background, demonstrating how the workflow uncovers unknowns such as colour‑grading preferences.

The overarching message is that as models become stronger, the value shifts from “how fast you can write code” to “how precisely you can ask the right questions”. Clear articulation of unknowns determines whether the model’s output is impressive or requires rework.