Stop micromanaging Fable/Claude 5

I'll pull the source article so the paragraphs stick to what's actually written there, without inventing figures or dates.Matt Shumer published How I Prompt Fable at shumer.dev, arguing that people fail to match his Fable demos because they prompt a next-generation model like older ones. The post was submitted to Hacker News under the title Stop micromanaging Fable/Claude 5 (item 49174806) with 2 points and 0 comments. Shumer says the demos look complex but usually come from simpler prompts and a different control style: goal over steps, hard done criteria, and long autonomous loops instead of micromanaged instructions.

On mechanics, Shumer’s workflow has a few fixed pieces. Hand Fable a large underspecified goal, then fence it with house rules (for agent work: prefer system-prompt behavior over hard-coded special cases like regex filters). Enforce a checkable bar for done, not vague quality adjectives; example: a stranger cannot tell a render from a real photo. Separate build from grade: a fresh-context sub-agent scores real pixels or a running app and tries to prove failure. Use /loop so the model build-checks-closes-the-gap for hours or days and does not self-declare finished. For multi-agent engineering, several Fable sessions pull tasks, triple-check with sub-agents, open PRs with evidence, and one integrator merges and user-tests; coordination runs through workbench.md (Markdown with images, video, HTML, a Trello-style board, and Slack-like chat). Ultracode is a heavier, costlier mode he almost never uses except when laying a foundation that will last months.

For builders, the shift is from step scripts to trust-plus-verification. Older models needed how instructions or they wandered; Shumer claims dictating steps overrides Fable’s better judgment. Safety comes from standing rules, independent grading, and a bar the build agent cannot talk past. Progress visibility is operational: agents update a workbench.md doc with screenshots and notes so he can review from a phone and redirect with comments without stopping the run. Credentials and spend are cleared up front with a budget so the agent only escalates when truly blocked; planning is the exception, and only for huge consequential builds, settled before code runs.

Market context is agent-harness competition, not a new model release. Shumer’s examples span engineering teams (Linear or board-driven parallel PRs) and creative work (photorealistic 3D forest first, then Hogwarts by pointing at forest code, quality bar, and Claude Code session traces). A failed component-library clone failed because it sat on ShadCN conventions and had no done measure; they dropped ShadCN, asked Fable to invent measurement (screen recording to a heat map of motion), and looped until the clone matched. That pattern competes with hand-written multi-step agent scaffolds that still over-specify tools and acceptance criteria.

Practical takeaway: stop spoon-feeding steps; set house rules, a hard external bar, separate graders, and a loop that only ends when you say so or no gap remains. Reuse prior high-quality artifacts and session traces as fuel so the next build does not relearn the same approach. Watch whether independent grading plus shared workbench-style coordination becomes the default agent ops pattern, and when ultracode-class spend is worth it only for foundations you will build on for months. If the method is hard to hold in head, Shumer’s close is literal: hand the article to Fable and have it help write prompts from that point on.