Claude Code effective patterns
Claude Code’s Fable 5 model brings significantly stronger coding capability — it can run for hours, test its own work, and often write code better than the developer. But a strong model does not guarantee effective use. These patterns come from Claude Code team member Thariq and community practitioners.
Three mindset shifts
Thariq from the Claude Code team described three key changes in how he works with Fable 5:
Unhobble Claude: let the model surprise you
Anthropic internally calls it capability overhang — the model can already do many things, we just haven’t found the right way to unlock them. Early models needed detailed instructions and examples, but with Fable-level models, too many examples actually constrain the model because its own imagination is richer than what you can specify.
Claude Code recently cut 80% of its system prompt. The new approach: give context, not constraints. Tell the model about the situation, not what it’s not allowed to do.
A concrete example: ask a chat model which Pokémon names end with “aw” — it can’t answer because it can’t iterate through names in its head. But give it a code execution tool and it pulls the full list, writes a script, and finds the answer in two seconds. The capability was there all along; the tool unlocked it.
Treat Claude as a thinking partner
The old pattern: break tasks into small pieces, check every output, catch problems when the model stops too early. With Fable, you increasingly check whether Claude is doing the right work, not just whether it’s working correctly.
A common failure mode: you don’t actually know what you want, or what’s feasible. Involving Claude early in your thinking catches these blind spots before implementation.
Practical approaches:
- Start with a small spec. Before writing the final spec, ask Claude to “interview” you about the implementation plan.
- Throw out an idea and ask it to explore several directions, generating HTML prototypes for review.
- Give it context, not just constraints. Instead of “keep it simple, don’t over-engineer,” say “this feature is an experiment — we’ll likely delete it in a month, so don’t build anything you’d be sad to throw away.”
Set goals and provide verification methods
Once you know what you want, use two Claude Code features:
/goal: keeps Claude working toward completion- Workflows: helps Claude verify its own output
After writing a spec, try:
“Set a goal to fully implement this spec. Then use workflows to verify each part of the plan and prepare a report on what was implemented and any discrepancies.”
This lets Claude be creative and thorough while ensuring it builds what you actually need.
Be more ambitious
Fable is an incredible model. If you think an LLM can’t do something — give it a chance. Thariq edited the very video he posted using Fable. Don’t let past experience cap your expectations.
Five principles to push Fable to its limits
Community practitioner Gorden Sun distilled five practical principles:
1. Give goals and acceptance criteria, let Fable decompose the steps
Don’t micromanage. Tell it what to achieve and how to judge success. Let it plan its own path. Over-decomposing tasks limits the model’s planning ability.
2. Let Fable plan and ask questions before executing
Give the model a “thinking phase.” Let it propose an approach and ask clarifying questions before you confirm and it starts building. This prevents major directional mistakes.
3. Give all raw materials at once
Don’t feed information in fragments. Provide all relevant documents, codebase context, and requirements in one shot. Fable’s long-context capability lets it judge what matters and how things connect.
4. Explicitly demand self-checks
Key self-check dimensions:
- Write tests: require tests for every feature and ensure they pass
- Find counterexamples: identify edge cases where the solution might fail
- Mark confidence: label each key conclusion with confidence level and what evidence would change the judgment
5. Use budget constraints to force better trade-offs
Moderate resource limits (search count, word count, time) force the model to make smarter prioritization decisions. Unlimited resources can produce unfocused, excessive output.
Example prompts to try
End-to-end deep research
Self red-teaming
Massive context audit
High-constraint creative work
Pure code music
Find your unknowns: blind spot techniques
Thariq’s second key theme: your prompt is a “map,” but the real codebase is the “territory.” When the model encounters something not on your map, it must decide on its own. Fable 5’s range is so large that if you don’t identify these unknowns in advance, it will make decisions you didn’t want in places you didn’t expect.
Six concrete techniques:
- Blind spot scan: before building, have Fable read through relevant code and surface potential issues you didn’t know about
- Four-prototype burst: ask for four stylistically different prototypes at once, then discover your preferences through reaction rather than description
- Interview you: let Fable ask you questions to extract details you “know but haven’t written down”
- Reference code as map: give it code from another system as a reference pattern — often more efficient than writing a spec from scratch
- Decision log: have it record every point where it deviated from your expectations, so you can see where it encountered problems you didn’t anticipate
- Reverse quiz: ask Fable to quiz you on what it built, ensuring you understand it well enough to explain the PR
Maintaining AI-generated code
When all code is AI-generated, the risk is not writing code — it is keeping that code iterable, maintainable, and free of rot. Product engineer Tw93 distilled six practices after shipping 13 versions of an app with ~110K lines of Swift and ~73K lines of tests, all AI-generated:
- Architecture and layering still matter. Clear boundaries make AI-generated code easier to maintain and extend. Don’t let the model invent the structure each time.
- Automated tests are the quality backbone. Every bug fix must add a regression test, so the same bug can’t come back.
- Delete dead code aggressively. When you remove a feature, remove its code too. Accumulated leftovers confuse both humans and future AI passes.
- CI/CD with a clean machine. Run the full test suite on a clean cloud runner before release, not just on your local machine.
- Let the AI auto-verify and auto-correct. Wire automated verification into the loop; reserve human verification for critical stages.
- Turn repeated work into skills. Encode recurring procedures so you don’t re-explain them from scratch every session.
The throughline: AI lowers the cost of writing code to near zero, so the discipline that matters shifts to architecture, verification, and cleanup.
Supervising agents smarter than you
Frontier agents remove the barrier of “you must build a mental model before changing code,” but they still fail in two ways: misunderstanding your intent and lacking the context to get things right. Both share one root cause — the quality of what you put into the context window. Since modern codebases are too large to hold fully in your head, the method shifts from “understand it yourself” to “make the agent prove it understands.”
Five techniques from a practitioner shipping thousands of PRs per month:
1. Indirect prompting (in your own words). Don’t order directly. First ask the agent to restate the problem in plain language — “read this Slack thread and describe the root problem in your own words.” This compresses noise into a structured statement, surfaces misunderstandings before the agent runs the wrong way, and stops your own wrong assumptions from steering it.
2. Mental-model skills. Four complementary commands:
/how — trace runtime mechanics across directories and services/why — investigate intent: code says what happened, rarely why. Search git history, PR comments, Linear, Notion, Slack, Datadog, Sentry in parallel/teach — have the agent explain it back to you intuitively (this also forces the agent to build a real model instead of confidently bluffing)/recall — pull context back from past session transcripts instead of rebuilding from zero
3. README-driven development. For shared code, write the README before implementing. It forces you to design from the hypothetical user’s API perspective. Use the Diátaxis framework to separate Tutorial / How-to / Reference / Explanation, and a pass to strip AI-sounding filler. The finished doc doubles as a concrete target the agent can verify against.
4. Prototype first. The two planning mistakes are accepting the agent’s first design and over-polishing a plan without evidence. Instead, have the agent produce several prototypes in parallel — UI variants behind a switcher, timing/layout measured with a verification CLI — and choose from screenshots. Prototypes are planning in code: the agent answers its own open questions with evidence.
5. Architect in five stages. Ground (build the current-state model with /how + /why) → Sketch (several independent runners across model families, each producing a full design package: call sites, type definitions, signatures, rationale) → Cross-judge (different models score against a strict rubric) → Implement (fill in the chosen sketch) → the cycle repeats with verification.
Loops design paradigm
Claude Code’s official Loops framework elevates agent engineering from intuition to a reusable design language. The core insight: four variables — trigger, stop condition, artifact, and use case — define every agent loop. The question isn’t “is this task hard?” but “which segment of work can be handed off?”
Four loop types
Turn-based (default agentic loop)
- What you hand off: checking this step
- Trigger: user prompt
- Stop: agent decides it’s done or needs more context
- Artifact: SKILL.md (encode your verification criteria)
- When: short, one-off, non-recurring tasks
This is the default. Improve it by encoding your mental acceptance criteria into SKILL.md so the agent can self-check more steps, reducing the rounds per task.
Goal-based (/goal)
- What you hand off: the stop condition
- Trigger: manual prompt
- Stop: goal achieved, or max turns reached
- Artifact: /goal + evaluation model
- When: tasks with verifiable exit criteria
Use when one turn isn’t enough. The key: define exactly what “done” looks like. The evaluation model checks your conditions each turn — deterministic metrics (test pass count, score thresholds) work best because the evaluator only needs to compare, not judge “good enough.”
Time-based (/loop, /schedule)
- What you hand off: the trigger timing
- Stop: you cancel, or work completes naturally (PR merged, queue emptied)
- Artifact: /loop (local, stops on shutdown) or /schedule (cloud)
- When: recurring work, or work that reacts to external state changes
Prefer event-driven over time-driven: longer intervals or state-change triggers save tokens and avoid jitter. Use /loop for local machines, /schedule for cloud persistence.
Proactive (fully autonomous)
- What you hand off: the prompt itself
- Trigger: events or schedule, no human in the loop
- Stop: each subtask exits on goal; the routine runs until stopped
- Artifact: all of the above + dynamic workflows (research preview) + auto mode
- When: standardized incoming work — bug reports, issue triage, dependency upgrades, batch migrations
Example assembly: /schedule periodic scan → /goal defines “done” + SKILL encodes verification → dynamic workflows explore multiple solutions with adversarial review → auto mode executes without approval.
Quality guardrails (four levels)
- Keep the codebase clean — agents follow existing patterns and conventions
- Give agents self-verification — encode “good” as SKILL checks
- Make docs accessible — keep framework/library docs current with best practices
- Use a second agent for code review — a fresh-context reviewer avoids the main agent’s confirmation bias
When a single result falls short, don’t just fix that one issue — encode it into the system so all future iterations benefit.
Cost guardrails
- Match the artifact and model to the task — simple tasks don’t need multi-agent loops
- Define clear success/stop criteria — be specific about “what done looks like”
- Pilot before scaling — dynamic workflows can spawn hundreds of agents
- Use scripts for deterministic work — a form-filling script is far cheaper than an agent deriving code each time
- Don’t run routines more often than necessary
Monitor with /usage, /goal (no args), and /workflows to inspect token distribution. The loops themselves don’t save money — model tiering and clear boundaries do.
How to start
Look at work you’re already doing. Find the step where you are the bottleneck. Ask:
- Can you write a quantifiable verification check? → If yes, try goal-based
- Is “done” clearly definable? → If not, don’t automate it yet
- Does work arrive on a schedule? → If yes, try time-based
- None of the above? → Stick with turn-based and improve your SKILL.md
The four loop types are composable building blocks, not mutually exclusive categories. The most sophisticated form (Proactive) is just /schedule + /goal + dynamic workflows + auto mode assembled together.
Key takeaway
Mastering Fable 5 isn’t about learning more commands or parameters — it’s about changing your relationship with the model:
- From “supervising execution” to “guiding direction”
- From “decomposing steps” to “setting goals and acceptance criteria”
- From “cautious testing” to “bold ambition”
- From “checking output” to “demanding self-verification”
A good prompt isn’t one with the most detailed instructions — it’s one where constraints are just enough, and trust is set to maximum.
References
Last modified on September 14, 2026
