Last week I gave Anthropic's new Claude Fable 5 model a deliberately messy, real-world task: refactor my personal portfolio site. Not a toy demo a living Next.js project with accumulated design debt, an outdated dependency tree, and content that had drifted out of sync with my actual resume.
This is what happened, what impressed me, where it stumbled, and the practices I'd recommend to any developer working with this class of model.
What is Fable 5?
Fable 5 is the first model in Anthropic's Claude 5 family, part of a new "Mythos-class" tier that sits above Claude Opus in capability. It shares its underlying model with Claude Mythos 5 (an approved-organizations-only variant); Fable is the generally available version with additional safety measures. The canonical public reference is Anthropic's announcement [ref], the docs are still thin because the model is new, so most of what follows is field experience, not marketing.
I used it through Claude Code, Anthropic's agentic CLI/IDE tool (doc), which gives the model file access, a shell, and a real browser for verification.
The refactor, in concrete terms
1. A major framework upgrade, handled like a checklist. Next.js 15.5 to16.2, React 19.2, Tailwind v4. The model knew the breaking changes before hitting them: next lint was removed in Next 16, so it rewrote my lint scripts against ESLint's flat config; Turbopack became the default bundler, so it checked whether my custom webpack config was actually used, discovered my SVGR rule was dead code (zero SVG component imports in the project), and deleted it rather than migrating it. It also removed a deprecated Google AI SDK that was installed alongside the one my code actually imports.
2. A design system derived, not decorated. My old globals.css was a graveyard: half the tokens were raw HSL fragments that Tailwind v4 never consumed, meaning several "design tokens" had silently never worked. The model extracted my brand color programmatically from my favicon (fun fact it surfaced: my pink was exactly Tailwind's pink-500, #EC4899) and rebuilt the entire token set in OKLCH, with neutrals carrying a barely-there brand undertone so surfaces and accents read as one family.
Then I changed my mind mid-session and asked for blue (#1868db) instead. Because the palette was formula-driven — one hue, consistent lightness/chroma ramps, the model re-derived light theme, dark theme, neutrals, and accents in one pass. It even wrote the sRGB→OKLab→OKLCH conversion math from scratch in a Node script to get exact values, then recolored my logo PNG pixel-by-pixel and regenerated my favicon.ico as a proper multi-size ICO container, byte-by-byte.
3. Content extraction that refused to give up. My resume in PDF turned out to have no text layer, the text was vector outlines. Two parsers (pdf-parse, pdfjs-dist) returned empty strings. Instead of asking me to paste my resume, the model rendered the PDF pages to PNG using pdfjs-dist plus a canvas library, then read the images visually and rewrote my site's experience section from them, eight positions, dates, locations, bullet points.
4. The fixes I never asked for. A deprecated motion()call (now motion.create()), missing sizes props on next/image fill images, a broken empty-state check comparing against a property that didn't exist (so my blog's "no articles" state could never render), and a leftover Farsi string in an English UI. It also added graceful degradation: my blog pulls articles from dev.to, and when that API is unreachable the site now shows a branded placeholder with a fallback link instead of an infinite skeleton.
Tips for working with Fable-class models
1. Make your codebase delegable before you delegate. The single biggest reason the mid-session rebrand took minutes instead of hours: design decisions lived in tokens, not scattered hex values. A model can hue-shift an entire design system in one edit when it's tokenized. If your colors are sprayed across 40 components, no model saves you.
2. Hand it artifacts, not descriptions. I didn't describe my brand color, I let it read the favicon. I didn't summarize my resume, I gave it the PDF. Real artifacts are ground truth; descriptions are a game of telephone. The model extracting #EC4899 itself is strictly better than me typing "it's like a hot pink."
3. Sequence upgrades and redesigns separately. We upgraded dependencies first, built, verified, then touched design. When something breaks, you must know which change broke it. This is the same discipline you'd demand from a human engineer; demand it from the model.
4. Demand verification, not vibes. Fable's standout behavior: after each change it drove a real browser, read the console, and queried computed styles to prove changes had landed. When you prompt, ask for evidence: "verify in the browser and show me the console" , not just "done."
5. Keep git as the undo button, and actually review. It wasn't flawless. At one point a PowerShell path quirk caused an npm install to land in the wrong project's directory, the model caught it, verified nothing was polluted, and cleaned up, but I was watching. Treat the model like a very fast mid-level engineer with occasional bold moves: everything on a branch, diffs reviewed, side effects audited.
6. Interrupt freely; course-correct early. I redirected mid-flight several times (new brand color, new content source, placeholder requirements). The model carried context across interruptions without losing the thread. Don't wait for a "finished" result to give feedback, steering early is cheaper.
7. Let it be resourceful on the weird stuff. The no-text-layer PDF is my favorite example. The fallback chain, parser → different parser → render to images and read visually, is exactly what a resourceful senior would do, and exactly what previous-generation models wouldn't attempt. Leave room for that resourcefulness instead of over-specifying the "how."
Why this matters
The step change isn't that Fable writes better code, though it does. It's that the loop changed. Previous models completed text; this one plans, acts, verifies its own work against reality, recovers from failures, and adapts when requirements move underneath it. That's not autocomplete. That's delegation.
The developers who benefit most won't be the ones writing the cleverest prompts. They'll be the ones with codebases structured for delegation, tokenized, testable, verifiable, and the judgment to review what comes back.
That's always been the job of a senior engineer. The tools just got a lot faster.
I'm Kazem Mirzaei, a full-stack developer. The refactored site and everything described here is real; happy to answer questions in the comments.
Top comments (0)