Field Guide to Fable - Lessons, Quiz, Action Plan

Core thesis

The bottleneck moves from model intelligence to your ability to shape the work.

Fable represents a class of model where raw capability is no longer the whole story. The decisive question becomes whether the surrounding harness, prompt, tools, references, and feedback loop let the model reach the capability it already has.

1

Unhobble the model

Give it tools, environment access, context, and room to use judgment instead of trapping it inside narrow examples.

2

Unhobble yourself

Convert vague taste, hidden assumptions, and missing domain knowledge into explicit maps the agent can navigate.

3

Stay in the loop

Use interviews, implementation notes, and quizzes so the agent's long-horizon work remains legible.

4

Be less reasonable

Stop pre-deciding that the tradeoff is real. Try the ambitious version and let reality answer.

Watch with the guide

Use the video as the raw material, not the final lesson.

The talk moves fast. This page preserves the structure, examples, and tactics so you can turn the keynote into an operating system for real work.

The four-part field guide

Every major lesson, translated into working practice.

01

Unhobbling Claude

Capability overhang is unlocked by the harness.

The Pokemon example matters because the chat model may know the data yet still fail the question. Claude Code succeeds by fetching the source list and writing a script. That is the lesson: the model's intelligence is spiky, and tools expose spikes that a chat box hides.

Models are grown, not hand-designed, so their needs change empirically.
Long context alone was not the coding unlock; bash, search, files, and environment access were.
Newer models can be constrained by too many examples. Prefer context over rigid prohibitions.
Markdown became plans, then HTML became rich reports with embedded questions and review surfaces.

02

Finding unknowns

The map is your prompt; the territory is the real codebase and world.

Unknowns are the decision points you did not specify. Fable traverses enough territory that those missing decisions multiply. The job is to discover them before they become expensive implementation surprises.

Known knowns are the request you actually wrote.
Known unknowns are open questions you already know exist.
Unknown knowns are taste, context, and standards you recognize only when shown.
Unknown unknowns are missing ideas that would change your prompt if surfaced.

03

Dealing with the grief

The old craft does not disappear cleanly.

Thariq names the emotional cost: code that once required weeks can become hours, and that creates both delight and loss. The answer is not nostalgia or denial. The answer is to go through the change while staying in the loop.

Hand-written mastery mattered, but so did late nights, brittle tradeoffs, and repeated failure.
Agentic coding still needs taste, judgment, and ownership.
The new skill is steering the agent through reality without abandoning responsibility.

04

Being unreasonable

Do not assume the tradeoff. Make reality prove it.

The new math changes what is reasonable. Good, fast, and cheap becomes a challenge to test, not a law to obey. But the talk ends with a warning: building is easier, generating value is still hard.

Try doing all of it before cutting scope in your head.
Use agents to take more shots, faster.
Measure value, not setup sophistication.
The proof that agents work is better work, delivered faster, with more life left over.

The unknowns matrix

Use the model to surface what you cannot yet specify.

Known knowns

Your explicit prompt, requirements, constraints, and desired output.

Known unknowns

Questions you know are unresolved: data models, UX choices, rollout constraints, risk.

Unknown knowns

Taste and tacit judgment: "I will know it when I see it" design, tone, workflow, ergonomics.

Unknown unknowns

Missing context that would change the task if you knew it existed.

Generated prompt

Pick one quadrant above to generate a prompt.

Tailored to Ignacio

A practical operating system for your Codex-heavy work.

Your highest leverage is not another setup tweak. It is applying this field guide to revenue, support, product polish, and local tooling work where the real source of truth matters.

1. Start with a source-of-truth pass

For Talkie, Venns, iOS, local model work, or a CLI change, make the agent prove the territory first: code callers, production logs, real device state, actual mailbox/tool output, or the named local CLI.

2. Make a reference pack before implementation

Give the agent the closest working code, previous report, screenshot, API response, or design artifact. This is the "another map" move. It reduces hidden taste and avoids generic best practices.

3. Demand a deviation log for risky work

For billing, provider callbacks, support operations, release tasks, or device installs, require implementation notes that record every place the territory forced a plan change.

4. Use unreasonable ambition with kill criteria

Try the bigger product or automation swing, but define the evidence that proves value: support time saved, conversion lift, fewer incidents, faster deploy, or revenue impact.

One-week application

Run this before your next meaningful agent task.

I named the real source of truth the agent must inspect first. I asked for a blind spot pass before edits. I provided a reference artifact or asked the agent to find one. I required implementation notes for deviations. I asked for a quiz before merge, deploy, or decision. I defined the value metric, not just the build task.

Preservation ledger

The talk's wisdom, compressed without dropping the spine.

Models get smarter in uneven, tool-dependent ways.

Do not evaluate a model only in a blank chat box. Evaluate the harness: tools, files, shell, search, memory, browser, and the permission model.

The system prompt is not timeless.

What helped older models can constrain newer ones. The prompt should evolve from restrictions and examples toward context and intent when the model can generalize.

Questions are a capability surface.

A weak model may barely ask one useful question. A stronger one can interview you, prioritize architecture-changing ambiguities, and embed questions in an HTML review artifact.

HTML is not decoration.

HTML lets agents build reviewable maps: plans, alternatives, diagrams, quizzes, dashboards, and decision surfaces that plain text cannot hold as cleanly.

Unknowns are where agent work fails.

Every unsaid decision becomes a model choice. Long-horizon work creates more of these decision points, so finding them becomes the core craft.

Blind spot passes teach you what to ask.

Use them when entering unfamiliar code, domains, visual disciplines, provider APIs, or production surfaces. The goal is to prompt better after discovery.

Prototypes reveal tacit taste.

If you only know the answer when you see it, ask for several artifacts. Reacting to concrete options is cheaper than undoing a full implementation.

References beat long verbal specs.

Point at code, screenshots, docs, workflows, or another implementation. The model can read the structure and transfer the pattern.

Implementation notes preserve the learning loop.

When the territory forces a deviation, log it. The next attempt starts with better knowledge instead of repeating the same surprise.

Quizzes keep you in command.

If the agent did more than you can explain, do not merge or ship blind. Make it teach you the change until you can answer correctly.

There is grief in the transition.

Agentic coding can make old hard-won skills feel displaced. The talk treats that honestly without using it as a reason to go back.

Being unreasonable means testing assumptions, not ignoring reality.

Attempt the larger version, then measure where reality actually pushes back. The danger is assuming the limit before the test.

Value remains the hard part.

The builder's trap is worshiping process and setup. The market still only cares whether the work creates value.

Prompt kit

Copyable prompts that map directly to the talk.

Blind spot pass

I am working on [task] in [repo/product]. I know my goal, but I may not know the hidden risks. Inspect the real source of truth first, then do a blind spot pass: list my relevant unknown unknowns, why they matter, and how I should prompt you before implementation.

Architecture interview

Interview me one question at a time. Prioritize questions where my answer would change the architecture, data model, rollout risk, cost, or user-facing behavior. Stop after the smallest set of high-leverage questions.

Prototype for taste

Before touching the production app, build a single HTML prototype with four distinct directions using fake data. Optimize for helping me react to layout, density, tone, and workflow. Then ask what I want to keep or reject.

Reference transfer

Read [reference path/link]. Treat it as the map for behavior, structure, and edge cases. Then explain what transfers directly, what does not, and how you will adapt it to [target repo/module].

Implementation notes

Keep implementation-notes.md while you work. If reality forces a deviation from the plan, choose the conservative option, log the decision under Deviations with evidence, and keep going unless the deviation changes the product goal.

Quiz before merge

Create an HTML report that teaches me what changed, why it works, what could break, and how it was validated. Add a quiz at the bottom. I should not merge or deploy until I can pass it perfectly.

Comprehension gate

Pass the quiz before using the advice.

The goal is not trivia. The goal is to prove you can apply the field guide to real agent work.