Anthropic's Claude Code team recently published a field guide to Claude Fable with a claim that lands hard for anyone shipping software with an agent: the model is no longer the thing holding your output back. You are. More precisely, the limit is how well you can name what you do not yet know before you brief the agent.
That reframes the whole job. When the model was the weak link, better prompting meant coaxing more capability out of it. With Fable, the capability is already there. What separates a great result from a mediocre one is the distance between the map you hand Claude (your prompt, your skills, the context you load) and the territory it has to work in (the actual codebase and its real constraints). Close that gap and the output is sharp. Leave it wide and Claude fills the space with reasonable guesses that may not fit your situation.
The map is not the territory
Every brief you write is a map. It describes the work as you understand it. The territory is the messy reality: the legacy module nobody wants to touch, the client who changes scope on Fridays, the compliance rule that only your senior engineer remembers. Claude Fable can reason brilliantly about the map you give it, but it cannot see the parts of the territory you left off. Your job shifts from writing instructions to surfacing reality.
Four kinds of unknowns
The field guide borrows a familiar frame and makes it useful for daily work. Before you start a task, it helps to sort what you are dealing with into four buckets:
Known knowns: the facts already in your prompt. The requirements you have stated, the files you have named, the constraints you have written down.
Known unknowns: the things you know you have not worked out yet. The API you have not read, the edge case you are unsure about, the decision you have parked.
Unknown knowns: things so obvious to you that you never bothered to write them down, but would spot instantly if Claude got them wrong. Team conventions, unwritten rules, the way your codebase actually handles auth.
Unknown unknowns: what you have not considered at all. The failure mode you did not imagine, the dependency you did not know existed.
The first bucket is easy. The last three are where quality leaks away. Most poor agent output traces back to an unknown that never made it into the brief, not to a weakness in the model.
Where the unknowns get closed
The guide maps concrete habits onto the phases of a task, and they are worth adopting as a checklist rather than treating as clever tricks.
Before you build: ask Claude for a blind-spot pass on your plan, run a quick brainstorm or a throwaway prototype, and let Claude interview you about the problem rather than only taking orders. Point it at reference material and ask for an implementation plan you can argue with.
While you build: keep implementation notes so the reason behind a decision travels with the code, not just in your head.
After you build: ask Claude for a plain pitch or explainer of what changed, and let it quiz you on the change. If you cannot answer its questions, you have found an unknown that was hiding in plain sight.
None of this is exotic. It is the discipline of turning a monologue into a conversation, so the unknowns get named while they are still cheap to fix.
Too specific, too vague, and the fix
There is a tension worth naming. Brief Claude too tightly and it will follow your instructions even when a pivot would have served you better, because you told it exactly what to do. Brief it too loosely and it falls back on generic best practice that may be wrong for your context. Neither extreme gets you a good result.
The fix is not more words. It is disclosing your starting point: where you are in your own thinking, how much experience you have with this problem and this codebase, and what you are unsure about. When Claude knows you are three hours into a hard problem versus starting fresh, it can act as a thought partner instead of a very fast typist. Reducing unknowns, not writing longer prompts, is the core skill of agentic coding, and the encouraging part is that it is learnable.
What this means for Australian teams
This is the exact gap we see across Australian teams adopting Fable on Claude Code. In Sydney and beyond, the tooling goes in fast. A team can have Claude Code set up, connected and running against a real repository inside a day. The discipline of naming unknowns is what then separates the teams getting compounding value from the ones getting output they quietly rewrite.
The economics make the point. A developer seat on a premium Claude plan runs on the order of a few hundred Australian dollars a month, say roughly A$300 per seat (check current AUD pricing before you budget, since plans change). That is small next to the work it touches. A senior engineer on around $220,000 a year costs about $120 an hour once you load on overheads; a week of rework caused by an agent building the wrong thing can quietly burn $45,000 across a small team over a year. The seat is not the expense. The unnamed unknowns are.
So the return on Fable is not really about the model. It comes from the habit of surfacing reality before you brief the agent, and from treating every task as a short conversation rather than a set of orders. That habit is cheap to build and it compounds.
If your team is set up on Claude Code but the output still needs heavy rewriting, the missing piece is usually this skill, not a better model. We run Australian teams through it on their own codebase. If that sounds useful, book a short session with us and we will walk your team through the unknowns discipline.
