Fable
The model discussed in the talk. Thariq frames it as a new class of model where the "map opens up": there is more to explore, more power to use, and more responsibility to guide it well.
Course map
The talk in one sentence
As models become more capable, the limiting factor becomes how well you expose the model's capabilities, discover your hidden assumptions, stay in command of the work, and aim at value instead of merely building.
Read this first
Glossary for every term the talk relies on.
Claude Code
The agentic coding environment in the talk. It matters because it gives the model tools such as file access, search, bash, and code execution. The talk contrasts this with a plain chat model.
Harness
The surrounding setup that contains or enables the model: prompts, system prompt, tools, UI, permissions, files, shell access, and feedback loops. A capable model can still underperform in a weak harness.
Capability overhang
The gap between what the model can do in principle and what your interface lets it do in practice. The talk's Pokemon example is the main demonstration.
System prompt
Background instructions given to the model before the user prompt. The talk says Claude Code recently removed 80% of its system prompt because newer models can be constrained by too many examples.
Context, not just constraints
A constraint tells the model what not to do. Context tells it what matters, why, and where the work lives. The talk argues that newer models often need less rigid restriction and more useful context.
Map
Your representation of the work: prompt, plan, spec, reference, intention, and assumptions. It is what you give the agent before it meets the real task.
Territory
The actual situation the agent must navigate: the codebase, files, real-world constraints, hidden edge cases, and everything your prompt did not fully describe.
Unknown
A decision point in the territory that your map did not specify. The agent must choose something there, so the quality of the work depends on how well you discover or handle these points.
Staying in the loop
Remaining able to understand, evaluate, and represent the agent's work. In the talk, implementation notes and quizzes are tools for staying in the loop.
Being unreasonable
Not accepting old tradeoffs automatically. The talk does not mean ignoring reality. It means trying the ambitious version and making reality show you where the tradeoff actually is.
Value
The outcome that matters beyond building. The talk ends by warning that building is easier now, but generating value is still hard.
Part 1
Unhobbling Claude
Do not judge a model only by what it does in a plain chat box.
The first lesson is that the model is partly "contained" by the way you use it. Thariq says models are grown, not designed: they are trained with data, feedback, and compute, but their exact strengths are discovered through use. That means the surrounding harness can either expose or hide capability.
The Pokemon example, fully explained
The question is: which Pokemon names end in "AW"? The talk says there are two: Croconaw and Drednaw. A plain chat model can know many Pokemon names and still fail because the task is awkward for memory and direct reasoning. Claude Code can solve it differently: fetch every Pokemon name, write a script, and filter the list for names ending in "AW".
The lesson is not "Pokemon trivia." The lesson is that code execution changes what intelligence can reach. The model does not need to remember the answer perfectly if it can build a small verification process.
What changed from chat to Claude Code?
The naive path was to make context windows enormous and paste an entire codebase into chat. The talk says the better unlock was giving the model "arms": bash, file access, search, and the ability to build its own context from the environment.
What changed with proactive work?
The captions render one example as "Claude Tag": a surface where the model can work proactively and in multiplayer. The point is that an agent that can wake itself up and do work is a different product shape from one that only acts after a direct prompt.
Older pattern
Small system prompt, few tools, many examples.
Middle pattern
Larger system prompt, more instructions, more examples, many tools.
Newer pattern from the talk
Smaller system prompt, fewer constraining examples, more context, fewer "do not do this" rules.
Practical rule
When a stronger model disappoints you, ask whether you gave it the right harness: tools, source access, context, references, and a way to ask questions. Do not assume failure in chat proves failure in an agentic environment.
Part 2
Finding your unknowns
The better the model gets, the more your hidden assumptions matter.
The talk's second lesson is that you must unhobble yourself. Fable can traverse more territory, so it will encounter more decision points you did not specify. If your map is thin, the model must guess. Better work starts by finding the unknowns before, during, and after implementation.
Known knowns
What you explicitly say you want. This is usually the visible prompt.
Use: make the model restate the task and constraints before it acts.
Known unknowns
Questions you know are open, but have not answered yet.
Use: list unresolved decisions and decide which ones block work.
Unknown knowns
Things you know tacitly, but would not naturally write down. You recognize them when shown.
Use: ask for brainstorms and prototypes so your reactions become requirements.
Unknown unknowns
Things you have not considered at all, including information that would change your prompt.
Use: ask for a blind spot pass before implementation.
Method 1: Blind spot pass
Talk example: you are adding a new auth provider in a codebase you do not know. Ask the agent to inspect the auth module and find relevant unknown unknowns. The talk also mentions telling it where context might live, such as git diff or Slack, so it can learn the gotchas.
I'm working on adding a new auth provider, but I know nothing about the auth modules in this codebase. Can you do a blind spot pass to help me figure out my relevant unknown unknowns and help me prompt you better?
Method 2: Learn a field before prompting it
Talk example: color grading during video editing. If you do not understand a field, ask the model to teach you the unknown unknowns so your next prompt is better.
I don't know what color grading is, but I need to grade this video. Teach me the unknown unknowns that matter so I can prompt better.
Method 3: Brainstorms and prototypes
Talk example: design is hard to specify because you may know what you like only when you see it. Ask for four distinct HTML directions for a dashboard, then react to them.
I want a dashboard, but I have no visual taste and don't know what's possible. Make me an HTML page with four wildly different design directions so I can react to them.
Method 4: Interviews
Once you have an idea, there are still ambiguities. Ask the agent to interview you, but give it a priority rule. The talk's rule is to prioritize questions that would change the architecture.
Interview me one question at a time about anything ambiguous. Prioritize questions where my answer would change the architecture.
Method 5: References
A reference is another map. The talk says you can point the model at code that represents what you want, even if it is in another system or language. For a React component, an HTML mock-up can be the reference map.
Read this code or HTML mock-up as the reference map. Understand what it represents, then use it to start the target implementation.
Method 6: Implementation notes
During the work, unknowns still appear. Ask the agent to log deviations when reality forces it away from the plan. This preserves why the path changed.
Keep implementation notes. If you run into an unknown and deviate from the plan, log where the deviation happened and why.
Method 7: Quiz after the work
After a long session, the agent may have done more than you can fully understand from a diff. Ask it to quiz you so you can represent the work before creating a PR or merging.
Quiz me about what happened so I can make sure I understand what I am doing and can represent the work before creating a PR or merging it.
Part 3
Dealing with the grief
The talk does not treat agentic coding as purely technical.
Thariq says using a mythos-class model gave him both a sense of gain and a sense of loss. He remembers programming before LLMs as a foreign country: hard tradeoffs, late nights debugging, projects failing, and startups going bankrupt. He also remembers loving the feeling of holding the codebase in his mind.
The gain
Work that used to take weeks can become hours. The old tradeoff surface changes.
The loss
The craft of writing code by hand can feel displaced, even if the old way was full of pain.
The response
The talk's answer is "the only way out is through": keep learning agentic coding, stay in the loop, and unhobble the model.
Practical rule
Do not confuse emotional resistance with technical judgment. Also do not surrender judgment to the model. The middle path in the talk is active steering: understand enough to evaluate the work and keep improving how you collaborate with the agent.
Part 4
Being unreasonable
Make reality prove the tradeoff before you accept it.
The final lesson is ambition. Thariq says he had been used to being reasonable: choosing priorities because code was hard and time was scarce. The talk challenges that habit. With stronger agents, some assumed tradeoffs should be tested instead of accepted.
The "good, fast, cheap" line
The familiar phrase is "good, fast, cheap: pick two." The talk's reframing is: now it can be "pick three." That does not mean every project is magically unconstrained. It means older limits may no longer be the real limits, so you should force reality to show the tradeoff.
The deck example
Thariq says he made the talk deck the night before in about four hours with Fable, and that he liked the result. This is the talk's example of faster high-quality work.
The value warning
The talk immediately narrows the ambition: building is easier, but generating value is still hard. AI engineers can obsess over process and setups, but the point is to create value.
Practical rule
Use agents to take more swings and attempt stronger work, but judge the result by value. The final instruction is not "make more artifacts." It is: explore, make it real, be less reasonable, and still care about whether the work matters.
Workbook
A reusable workflow from the talk.
Fill this in for your next agent task. The placeholders are not examples; they are slots for your real work.
1. Define the map
2. Name the territory
3. Ask for unknowns
4. Stay in the loop
Quiz