All notes

#200 Prompting Claude Code and Fable 5 with clarity

July 29, 2026·8 min read

#200 — Prompting Claude Code and Fable 5 with clarity

When you work with an AI coding agent, there's a map and a territory. The map is your prompts and context what you hand the model. The territory is the actual codebase, the real constraints, the messy parts of the problem. The distance between those two things creates unknowns: whenever the agent hits one, it has to guess what you meant, and the more work it's doing, the more guesses it makes.

The quality of an AI agent's output tracks directly with how well you've closed that gap ahead of time. Planning ahead helps, but it doesn't catch everything you'll still find gaps mid-build, and sometimes those gaps signal that the whole approach needs to change. Working with an agent well means treating this as a loop: find the gaps before you start, catch new ones as they show up, and check for them again once the work is done.

Four ways to break down what you don't know

Every problem you hand an AI agent splits into four buckets:

  • Known knowns whatever's already in your prompt, the stuff you've told the agent directly.
  • Known unknowns gaps you're aware exist, even if you haven't filled them in yet.
  • Unknown knowns things so obvious you'd never think to write them down, but you'd spot instantly if you saw them.
  • Unknown unknowns blind spots you haven't considered at all, including not knowing what a good outcome would even look like.

Engineers who prompt with very few unknowns tend to be deeply in sync with both the codebase and how the model behaves, but even they still work with some assumptions baked in. Cutting down your unknowns is a skill, and it's one you build by practicing with the agent.

How to prompt without overcorrecting

Instructing an AI agent means walking a line between two failure modes. Get too specific and it will follow your instructions even in a moment where a pivot would clearly serve you better. Get too vague and it falls back on generic industry defaults that might not fit what you're actually building. Skip accounting for your unknowns and you lose both ways: you won't know when the road ahead has obstacles, and you won't know when it's clear enough that the agent should veer off your instructions.

An AI agent can search a codebase and the internet faster than you can, knows more about most topics than you do, and can iterate past a failed attempt faster too. Give it context on where you're starting from your thought process so far, your actual experience with the problem, your familiarity with the codebase and let it function as a thought partner instead of a request-in, code-out machine.

Before you write a line of code

Blind spot pass. Use this when you're stepping into unfamiliar territory a new part of the codebase, a skill you've never used before. You won't know what questions to ask, what "good" looks like, or what history you're missing, so ask the agent directly to find your blind spots and explain them to you, giving it context on who you are and what you already know first. Example: "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."

Brainstorm and prototype. This targets unknown knowns the criteria you can only recognize once you see them, like visual design. Small tweaks to a spec can produce completely different code, and an agent has a harder time backing out of a direction once it's built, so it's cheaper to surface these preferences early through rough prototypes than to discover them mid-build. Opening a session with a brainstorm phase often surfaces approaches you wouldn't have thought of and keeps the scope from landing too narrow or too wide. Example: "I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them."

Interviews. Once you've brainstormed, you likely still have gaps left. Ask the agent to interview you about them one at a time, and give it enough context about the problem to steer its questions. Example: "Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture."

References. Sometimes you can't put what you want into words, either because you lack the vocabulary or because it would take too long to explain. Point the agent at source code instead of a screenshot or description a library that already does the thing you want, even in a different language, gives it far more to work with than a picture ever could. Example: "This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client."

Implementation plan. Before building, ask for a plan that leads with whatever's most likely to change data models, type interfaces, UX flows so it surfaces the pieces you'd actually want to alter, rather than burying them under boilerplate. Example: "Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part."

While the build is happening

Start a fresh session once you're happy with the plan, and pass the agent the artifacts from your planning a spec file, a prototype, whatever you've built up. Even with a solid plan, an agent can hit an edge case in the code that forces it off the planned path. Ask it to keep an implementation-notes.md file logging every deviation, so you both learn from it next time. Example: "Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going."

After the code is written

Pitches and explainers. Getting buy-in matters as much as writing the code. Package the prototype, spec, and implementation notes into one doc, lead with a demo GIF, and reviewers who'd otherwise start from the same blind spots you did can catch up fast and approvals move quicker when reviewers can see you already accounted for the failure points they'd have flagged. Example: "Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF."

Quizzes. After a long session, the agent may have done more than the diff shows you, since a lot of the actual behavior depends on code paths you're not looking at. Ask the agent to quiz you on the change after giving you context, and hold off on merging until you pass it. Example: "I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass."

How this plays out on a real project

Editing a video end-to-end with an AI coding agent, with zero prior video-editing background, shows the pattern in action. Starting from what was already known that the agent could edit and transcribe video through code, but with uncertainty about transcription accuracy the next move was asking it to explain how tools like Whisper work and whether ffmpeg could reliably cut pauses and filler words. Wanting a UI timed to match spoken words but unsure if that was feasible, the fix was having the agent build a quick prototype against a transcript to test it before committing to the real build. When the video looked flat, the cause was clearly color grading, but without knowing what good color grading looked like, the better move was asking the agent to teach the basics first rather than asking it to guess at random variations.

Closing the gap between map and territory

As AI models get better, what you can build with them expands too and when a long task comes back wrong, that's usually a sign you need to spend more time defining your unknowns or building a plan flexible enough to adapt around them. Explainers, brainstorms, interviews, prototypes, and references all serve the same purpose: they surface what you didn't know before it turns into a costly fix later. The simplest way to start your next project is asking the agent to help you find your unknowns.

If any of this resonates with what you’re building, or if you’re considering working together, you can reach us here.

Frequently asked questions

What is the 'known unknowns' framework and where does it come from?

The known knowns / known unknowns / unknown unknowns framework originated with U.S. Secretary of Defense Donald Rumsfeld in a 2002 press briefing, and has since been adapted into project management and now AI-assisted coding as a way to categorize what you do and don't know before starting a task. For AI coding agents, a fourth category, unknown knowns, matters too: the things you know but wouldn't think to say out loud, like design taste.

How do I write a better prompt for Claude Code or similar AI coding agents?

The highest-leverage move is disclosing your unknowns upfront rather than just stating what you want. Tell the agent your experience level with the codebase, your thought process so far, and where you're uncertain, so it knows when to follow instructions literally versus when to flag a better approach.

What should an AI agent implementation plan include before coding starts?

A good implementation plan front-loads the decisions most likely to change, such as data models, type interfaces, and user-facing flows, and pushes mechanical refactoring to the bottom. Reviewing the plan before code gets written catches expensive rework later, since altering a data model after implementation is far costlier than adjusting it on paper.

How do I stop an AI coding agent from ignoring context and following instructions too literally?

Over-specifying a prompt causes an agent to execute your instructions even when the codebase reveals a better path, while under-specifying causes it to default to generic best practices that may not fit your product. The fix is giving explicit permission to deviate combined with context on your goals, so the agent can judge when a pivot serves you better than compliance.

What is an implementation-notes.md file and why should I use one?

An implementation-notes.md file is a running log an AI agent keeps during a build, recording any point where it deviated from the original plan due to an edge case, along with which option it chose. This creates a paper trail for founders reviewing a PR, so you're not stuck reverse-engineering diffs to figure out where the actual build diverged from the spec.

How do I review AI-generated code I didn't write myself?

Reading a diff only shows you what changed, not the full behavioral impact, since much of what happens depends on existing code paths the diff doesn't display. Asking the agent to generate a report plus a quiz on the change, and passing that quiz before merging, is a faster way to confirm you actually understand what shipped than manually tracing every file.

How do founders use AI to prototype product ideas before committing engineering time?

Requesting several rough, wildly different prototypes, for example four distinct HTML mockups of a dashboard or landing page, surfaces design and UX preferences that are hard to state in words but obvious once you see them. This front-loads unknown knowns during a cheap brainstorming phase rather than discovering them mid-build, when reversing a design decision costs far more engineering time.

Can AI coding agents help me learn a skill I have no background in, like video editing or color grading?

Yes: a documented example involved editing a product launch video end-to-end using an AI coding agent with zero prior video-editing experience, by asking the agent to first explain unfamiliar concepts like Whisper transcription and color grading before attempting the actual edits. Asking the agent to teach the underlying concept before generating output avoids the trap of approving work you have no basis to judge as good or bad.

What's the difference between a 'blind spot pass' and a normal prompt in AI coding workflows?

A normal prompt states what you want built, while a blind spot pass explicitly asks the agent to identify what you don't know you don't know, such as unfamiliar conventions in a new part of a codebase or historical context you're missing. This matters most when working in unfamiliar territory, where you can't ask good questions because you don't yet know which questions exist.

What is context engineering and how is it different from prompt engineering?

Prompt engineering focuses on wording a single instruction well, while context engineering is about curating everything an AI agent has access to across a session, including prior decisions, reference files, and constraints. For founders running multi-step builds, context engineering matters more than prompt wording once a task spans more than one file or more than a few minutes of agent work.

How do I choose the right Claude model for my startup's use case?

Model choice depends on the tradeoff between reasoning depth and cost per task: lighter models like Haiku suit high-volume, low-complexity work, while Opus-tier models suit tasks with many unknowns or ambiguous specs. A useful test is running the same task on two model tiers and comparing how many clarifying questions each one needs, since more unknowns generally justify a higher-reasoning model.

How do I build a verification loop for AI-generated code before it ships?

A verification loop pairs an implementation-notes log during the build with a post-build quiz or report, so deviations from plan get caught before merge rather than in production. Skipping this step is a common source of silent scope drift, where an agent solves an adjacent problem correctly but not the one you actually asked about.

What security risks should founders watch for when using AI coding agents?

The main risks are agents committing secrets, following prompt-injected instructions from scraped web content, or modifying code outside the intended scope during long autonomous runs. Founders running unattended or overnight agent sessions should sandbox the environment and review diffs before merge, rather than granting full production access by default.

Can non-technical founders use AI coding agents to build without writing code themselves?

Yes, though the same unknowns framework still applies: a founder with no video-editing background successfully edited a full product launch video by asking the agent to explain unfamiliar concepts like transcription and color grading before generating output. The pattern that makes this work is asking the agent to teach the concept first, then apply it, rather than approving output you have no basis to evaluate.

How much oversight does an AI coding agent need during a long autonomous session?

Longer, more autonomous sessions increase the number of unknowns an agent has to guess through, so oversight needs scale with task length and ambiguity rather than staying constant. Checking in at natural checkpoints, like after planning and before implementation, catches drift earlier than waiting until the full task is marked complete.

What's the fastest way to onboard an AI coding agent to an unfamiliar codebase?

Running a blind spot pass, where you explicitly ask the agent to surface what a new contributor wouldn't know, tends to work faster than manually writing a full onboarding doc. Pairing that with a small number of reference files or examples of past patterns gets an agent productive in a new codebase without a founder having to document every convention manually.

Are AI-generated implementation plans reliable enough to skip manual code review?

No: implementation plans reduce the number of unknowns going into a build but don't eliminate edge cases discovered mid-implementation, which is why deviation logs and post-build quizzes exist as separate checks. Treat the plan as a way to catch big architectural mistakes early, not as a substitute for reviewing the actual diff before merging.

more than just words|

If youre considering working together, you can reach us here.

send us a note

If any of these notes or ideas resonate with your team, we're always open to a conversation.