I have started handing a chunk of day-to-day freelance work and this site's upkeep over to Claude Fable — everything from adding a blog nav link to tweaking the mobile language-switch label. A lot of small changes now start as a plain-language request and end as a diff. After a while of this, here are a few honest notes — not a pitch, just a work log.
Reading the context
This repo has accumulated a fair number of unwritten rules — Vercel deploys need framework: null, the tilt effect has to bind to a container that never tilts itself to avoid jitter. Once those rules were written into CLAUDE.md, Claude Fable reads them before touching anything and follows the existing conventions instead of bolting on its own style. What it saves is not typing time — it's the time spent explaining why something can't be done the obvious way.
What small changes feel like
For requests like "put blog to the left of labs" or "shorten English to EN on mobile," a single sentence is enough for it to locate the right files, read the current structure, and make the smallest change that satisfies the ask — it does not go rewrite the whole nav header while it is in there. That restraint matters to me; after years of freelancing, an overeager tool that "helps" its way into code you no longer recognize is a real risk.
Where the Labs examples came from
The little games and toys in Labs came out of a batch of over a hundred examples I built with Claude Fable in one long stretch — the billiards game and the small-town story are both picks from that batch. The method was low-tech: throw out an idea in one sentence, let it produce a working first pass, then actually play with it to decide if it was fun or complete enough to keep. Most of the hundred-plus were half-finished experiments for testing an idea or a technique; only a handful felt polished and interesting enough to make it into Labs. Volume came fast — the judgment about what to keep was still mine.


Where you still have to watch closely
Anything that requires guessing what the user will actually see — like a CSS selector for a mobile-only label — still needs a careful back-and-forth. If the direction is not spelled out precisely, it is easy for both language variants to get changed instead of just one. AI-assisted work cuts down repetitive engineering time, but the judgment call of 'is this actually correct' still sits with you, especially anywhere bilingual or multi-device logic can ripple sideways from one small edit.
Takeaway
In practice it feels less like a replacement for planning and judgment, and more like a fast assistant with a very good memory. The clearer the documentation and the more specific the ask, the more the output actually fits the shape of the project it already has — that seems to be the real dividing line for whether these tools feel smooth to use or not.
Max Chu