00 The verdict first
TL;DR
It's about 20% hype, 60% prompt/workflow, 20% platform. The amazing builds in videos are not one-shot prompts. They're a loop: plan → design references → build one screen at a time → screenshot what was built → feed it back → fix → repeat. Every model produces "AI slop" from a vague one-shot prompt — including Fable 5.1. And Fable 5.1 specifically has known quirks (documented by Anthropic) that make naive prompts stall or over-deliver.
Meanwhile, for pure front-end look-and-feel, Kimi K3 currently beats Claude Fable 5/5.1 in blind human votes (Frontend Code Arena #1, Elo 1679). You may already own the best model for the exact thing you're frustrated about.
01 Why one-shot prompts fail
"Make me a [X] web app" is underspecified by design. The model has thousands of statistically reasonable ways to satisfy it — so it averages all of them: safe blue, generic cards, placeholder content, no point of view. As one design-engineering review put it: the output isn't the tool failing — it's the tool correctly rendering an underspecified request.
The demo videos you see are the output of a workflow, not a prompt. The common pattern across every credible writeup:
- Plan before code. "Models jump to coding on the first prompt — this does not produce the best result." Describe → plan → review the plan → then build.
- Give real design references. A real site you admire + what specifically to borrow from it (hero composition, type scale, card hierarchy, scroll behavior). References beat adjectives like "premium" or "clean and modern."
- One screen at a time. Get the most important screen right, lock its theme, then extend. Never "build the whole app" in one prompt.
- Close the visual loop. Have the agent screenshot what it actually built and critique it against the brief. This is the step everyone skips — and it's the difference between "valid code" and "looks right."
- Iterate ~3 rounds: layout/content → colors/spacing/type → polish (icons, micro-copy, states).
The one-sentence root cause
AI is a junior designer with incredible speed and zero mind-reading. Every decision you don't specify, it makes blandly on your behalf.
02 The 15 prompt mistakes (ranked by damage)
From a review of hundreds of AI-generated screens — the same mistakes keep producing the same generic output. The two at the top poison everything downstream.
| # | Mistake | Fix |
|---|---|---|
| 1 | "Clean and modern" as the style — carries zero information; AI reads it as "defaults, safe blue, nothing interesting" | Name a real style: glassmorphism, neobrutalism, bento grid, dark premium, iOS native, Material 3 |
| 2 | Platform not specified — "mobile" produces a hybrid native to nothing | "iOS settings screen, Apple grouped inset list, SF Pro" / "web dashboard, sidebar nav" |
| 3 | Whole app in one prompt — nothing gets proper attention | One screen per prompt; "keep the same theme" in follow-ups |
| 4 | No user context — "a dashboard" = a dashboard for no one | "For a freelance designer who checks active projects, deadlines, invoices every morning" |
| 5 | Only the happy path | Explicitly ask for empty, loading (skeleton), and error states |
| 6 | Placeholder data — Lorem ipsum, "Item 1, Item 2" | Realistic content: "Whole Foods $67.23 (today), Netflix $15.99 (yesterday)…" — content shapes layout |
| 7 | No color spec — "nice colors" = default blue | Hex codes, or "Spotify palette — dark bg, green accents", or mood terms with named colors |
| 8 | No typography hierarchy | Font + hierarchy: "balance as large bold number (36pt+), section headers 16pt medium, labels 12pt light gray" |
| 9 | 8+ feature sections on one screen — airplane cockpit | One primary action per screen; push secondary stuff to tabs/menus |
| 10 | No spacing system | "8-point grid", "24px between sections, 16px margins" |
| 11 | No visual references | "Layout like Linear's issue cards", "like Stripe's typography" — the single most effective trick |
| 12 | Accepting the first output — round 3 is typically ~5× better than round 1 | Iterate: structure → styling → polish |
| 13 | Separate prompts per screen → 3 themes, 3 different apps | Restate design tokens in every prompt: "same theme: #0a0a0a bg, mint #4ade80 accents, Inter, 8pt grid" |
| 14 | No accessibility | "WCAG AA, 4.5:1 contrast, 44pt touch targets, labeled controls" |
| 15 | Not naming component libraries | "Use shadcn/ui components, zinc scheme" — the model knows exactly what they look like |
03 The master prompt anatomy
For Fable 5.1 as an agent (Claude Code, or any tool-calling setup), the consensus structure — from Anthropic's own docs and independent guides — is Context → Goal → Constraints → Completion criteria, then get out of the way. Over-prescribing every step makes agentic models worse.
## Goal
[The final outcome, not the steps. "Migrate session auth to JWT, preserve UX,
update all affected code and tests, suite passes." Not "fix auth system."]
## Context
[Why this matters, who uses it, the stack. "Preparing API for enterprise
customers; reduce N+1 queries without breaking behavior."]
## Requirements
- [Concrete, verifiable requirement 1]
- [Requirement 2]
## Constraints
- Do NOT modify unrelated functionality or refactor adjacent code
- Do NOT add new dependencies
- Preserve existing behavior unless the task requires changing it
- Prefer targeted edits over rewriting whole files
## Workflow
Inspect relevant files first → investigate → implement → run tests →
fix failures caused by your changes. Do not stop after describing changes.
## Completion criteria
Done only when: [feature works] AND [tests pass] AND [regression check X].
## Final response
Summarize: what you found / what you changed / what you verified / what's unresolved.Bad vs good — the difference in one example
Bad: "Fix the payment bug."
Good: "Investigate the payment failure when a subscription is upgraded. Find the root cause, implement the smallest necessary fix, update relevant tests, run the affected suite, and verify the downgrade flow still works. Do not modify unrelated payment logic."
That's: problem + investigation + smallest fix + testing + scope fence + regression check. Six signals instead of a shrug.
04 Fable 5.1–specific quirks (from Anthropic's official guide)
Anthropic published a dedicated prompting doc for this model. If your prompts were written for older Claudes, several behaviors changed under you:
| Behavior | What happens | The fix (paste-ready) |
|---|---|---|
| Stalls to ask permission ("Shall I apply this?") on long tasks | It ends the turn describing next steps instead of doing them | System prompt: "You are operating autonomously. The user is not watching in real time… For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes." |
| Over-delivers — fixes unrequested bugs, refactors neighbors, commits extra test files | Huge surprise diffs | "If you find a pre-existing bug or behavior the task doesn't mention, don't fix or extend it in this change; report it as a follow-up in your summary." |
| Rewrites whole files for small changes (more than Fable 5 did) | Token burn, painful review | "Make the smallest change necessary. Prefer targeted edits over rewriting entire files." |
| Goes quiet for minutes during long tool chains | Looks hung while working | "Before you start, say in a line what you're about to do; give brief updates at milestones; close with a recap that stands on its own." |
Effort levels matter — default is high; names don't map 1:1 from Fable 5 | Max effort = long thinking + token burn; low = answers from memory instead of searching | Start at high; drop to medium where quality holds; reserve xhigh/max for measured wins. At low effort, tell it to search rather than recall |
| Old anti-formatting rules backfire — 5.1 already under-formats | Sparse, under-structured replies | Strip "don't use bullets/bold" rules from your prompts/system prompt |
| History must be append-only (thinking blocks bind to the conversation) | Editing earlier turns → 400 errors or dropped thinking | Don't rewrite old turns; use mid-conversation system messages for new instructions |
| Vision is strong but needs tools | Dense screenshots/charts get misread | In agentic setups give it a crop/zoom image tool — "an image-cropping tool alone delivers most of the uplift" |
Hands-on user consensus matches the docs: it's excellent at big messy context ("where does the money actually get calculated" — walks the real call chain instead of guessing from filenames), at pushing back when your change breaks something, and at long documents. It is still not psychic: vague instructions in, confident wrong thing out.
05 The 7-step workflow behind the "amazing" video builds
Distilled from the Fable 5.1 website-design workflows making the rounds. The model is the engine; this process is the heavy lifting:
| Step | What you do | Why it works |
|---|---|---|
| 1 · Brand rules | Colors, fonts, spacing, tone — fixed before any code | Kills per-prompt theme drift (mistake #13) |
| 2 · Pain / Person / Promise | What problem, for whom, what's promised | Decides what belongs above the fold, which CTA matters |
| 3 · References | 2–3 real sites you admire + what to borrow from each | "Use this reference for the layered hero, these cards for hierarchy, this type scale" — precision beats "premium" |
| 4 · Components | Name the reusable building blocks (shadcn/ui, your existing kit) | Consistency without re-describing every section |
| 5 · Scroll & motion | Define how the page responds — subtle planes, stacking cards | Motion should reassure, not perform |
| 6 · Mobile, separately | Treat mobile as its own design pass, not a shrink of desktop | "Luxurious on 27″, cramped on a phone" is the default failure |
| 7 · Screenshot verification | Agent screenshots its own build, critiques vs. brief, fixes, repeats | Closes the gap between "code is valid" and "it actually looks right" |
The line to remember
References beat vague adjectives. Reusable components beat reinventing every section. Mobile testing beats assuming. Screenshot verification beats trusting the source code.
06 Copy-paste prompt templates
A · New web app from scratch
Build a [web app] for [who uses it] to [core job-to-be-done].
Look & feel: [named style — e.g. dark premium / neobrutalism / bento grid].
Palette: [exact hex: bg #0a0a0a, accent #4ade80, text #e6edf3].
Type: [Inter; hero numbers 36pt+ bold, section headers 16pt, labels 12pt].
Spacing: 8-pt grid, 24px between sections.
Components: shadcn/ui patterns. Reference: [real app] for [specific thing].
Build ONE screen first: [most important screen].
Include empty, loading (skeleton), and error states.
Use realistic data throughout — no lorem ipsum, no "Item 1".
One primary action per screen.
When it's right, I'll say "next screen" — keep the identical theme.
Verify your work: render it, screenshot it, compare against this brief,
list what's off, and fix it before showing me.B · Analyze an existing web app (audit passes)
Key insight from code-review research: separate passes catch more than one combined "review everything" ask. Scope each pass to one dimension, demand line numbers and severity.
Pass 1 — Map it:
"Walk this codebase and produce a map: entry points, main modules,
data flow, where [money/auth/state] is actually calculated and why.
Flag anything that looks accidental vs. intentional. Ask me nothing
yet — report first."
Pass 2 — Bug hunt:
"Acting as a pre-release auditor, review specifically for [bugs that
could break in production / security: auth, injection, rate limiting /
performance under load]. For each finding: file, line number, severity,
concrete failure scenario, and the exact fix. No vague advice."
Pass 3 — UX/visual audit:
"Screenshot every screen at mobile (390px) and desktop (1440px).
Audit against: contrast (WCAG AA), touch targets ≥44px, spacing
consistency, loading/empty/error states, iOS input font-size ≥16px.
Report each issue with the screenshot reference."
(One pass per message. Combine findings yourself, then send pass 4.)C · Redesign or bug-fix an existing app
Bug fix:
"[Paste exact error/stack trace + the function that throws.]
Expected: [behavior]. Actual: [behavior].
Find the root cause — do not treat symptoms. Implement the smallest
fix that removes the cause. Do NOT refactor unrelated code, change
schemas, or add dependencies. Run [tests] and verify [adjacent flow]
still works. Report root cause in one line at the end."
Redesign (keep behavior, change skin):
"Redesign the UI of [page] with ZERO functional changes.
Visual direction: [named style] like [reference app]'s [specific aspect].
Keep: all existing routes, state logic, API calls, data shapes.
Change: layout, spacing (8pt grid), color ([hex palette]), type
([font + hierarchy]), components ([library]).
Every interactive element keeps its label and behavior.
After building: screenshot mobile + desktop, verify against this brief,
fix what's off, show me before/after."Screenshot feedback loop — the underrated move
In Claude Code, Ctrl+V pastes images directly. Screenshot what's wrong, mark it up, describe what you want instead. Feeding the model its own rendered output (or your inspiration screenshots) beats describing problems in words — for both Fable 5.1 and any vision-capable model.
07 The classics still apply: coding practices, translated for AI
Prompting tactics (sections 03–06) control how the AI works. But the tried-and-true practices from the software canon decide what "good" even means — and here's the twist: they matter more in the AI era, not less. Industry data since AI adoption shows copy-pasted code has exceeded refactored code for the first time ever (~4× duplication growth) — because AI treats every prompt as a blank slate and regenerates instead of reusing. The books are your defense.
The structural move: encode the books ONCE
Don't repeat standards in every prompt. Put them in your project's CLAUDE.md / AGENTS.md (the file Claude Code reads before every session) — this is exactly what the community is doing: rule files distilled from Clean Code, Refactoring, DDD and Clean Architecture now exist as ready-made agent rulebooks. Every prompt in that project inherits your standards for free.
| Principle (source) | Why it matters MORE with AI | Prompt-ready line |
|---|---|---|
| Make it work → make it right → make it fast (Pragmatic Programmer) | Asking for optimal + complete + polished in one shot gets you mediocre versions of all three, in that order | "First make it work. I'll review, then ask for a cleanup pass." |
| DRY — don't repeat yourself (Hunt & Thomas) | AI's #1 structural sin: duplicating functionality that already exists elsewhere in your repo | "Before creating any new function or component, search the codebase for one that already does this. Reuse or extend before adding." |
| YAGNI + KISS | AI over-engineers by default: speculative abstractions, config for single-value things, error handling for impossible cases | "Build the simplest thing that satisfies the requirements. No speculative abstractions. No features beyond the list. No config options for things that have exactly one value." |
| Small functions, single responsibility (Clean Code) | AI happily writes 200-line functions with nested conditionals | "Functions do one thing and stay under ~40 lines. If a function needs a comment to explain a section, extract that section." |
| Meaningful names (Clean Code) | AI generates data2, handleStuff, processHelper when rushed | "Name things after their domain meaning. No temp, data, utils, helper, or numbered duplicates." |
| Refactoring = small behavior-preserving steps (Fowler) | AI "refactors" by rewriting the whole module and silently changing behavior — the exact opposite of the book | "Refactor in small steps. Run the tests after each step. Behavior must be identical — if a test breaks, you changed behavior, so stop and report." |
| Red-green-refactor (TDD) | The single best bug-fix guard: the failing test proves the bug existed and keeps it dead | "Write a failing test that reproduces this bug first. Show me it fail. Then fix it. Keep the test forever." |
| Separation of concerns | AI blends UI, logic, and data access into one file when solving a single-screen problem | "Keep presentation, business logic, and data access in separate modules." |
| Fail loudly at boundaries | AI loves silent catches that turn bugs into mystery behavior three screens later | "Validate inputs at the boundary. Return typed errors. No empty catch blocks — an ignored error is a future 2am bug." |
| Comments say why, not what | AI narrates the obvious: // increment counter | "Only comment non-obvious decisions and constraints — the 'why', never the 'what'." |
| Test behavior, not implementation (test pyramid) | AI writes brittle tests that assert internal call order and break on any refactor | "Tests assert what the user/system observes, not internal implementation. Few integration-critical paths tested deeply > everything asserted shallowly." |
| Boy-Scout Rule, fenced (Pragmatic Programmer) | Tension with Fable 5.1's over-delivery: you want cleanup, but not unprompted rewrites of untouched files | "Clean up only within files you're already touching. Anything else you notice: report as a follow-up suggestion, don't change it." |
The self-review pass — make the books the rubric
The classics aren't just for prompting — they're your verification checklist, since you can't trust AI to self-police. After any feature build:
"Audit the code you just wrote against these rules, and fix violations:
1. No duplicated logic — every concept defined once
2. No function over ~40 lines doing multiple jobs
3. Names reveal intent; no temp/utils/data/help
4. No silent error swallowing; errors typed and handled
5. Tests cover the new behavior, not the implementation
Report each violation found + fixed as a list."08 The design canon: UI structure principles, translated for AI
Same story on the design side. Refactoring UI (Wathan & Schoger), Don't Make Me Think (Krug), and The Design of Everyday Things (Norman) are decades of distilled practice — and they're precisely the vocabulary that turns "this looks off but I can't say why" into a fixable instruction. A vague eye produces vague prompts; a named principle produces a named fix.
| Principle (source) | What it means | Prompt-ready line |
|---|---|---|
| Visual hierarchy (Refactoring UI) | Every element has a rank; emphasize what matters via size, weight, and color — de-emphasize everything else | "Rank every element: primary / secondary / tertiary. Primary = biggest and boldest. Secondary steps down. Tertiary is quiet gray. One primary action per screen." |
| Proximity & grouping (Gestalt) | Spatial distance communicates relationships: related things sit close, sections separate with whitespace — not divider lines | "Group related controls tight. Separate groups with at least 2× the internal spacing. Never use lines where whitespace can do the job." |
| Design in grayscale first (Refactoring UI) | If the layout only works with color, the layout is broken; color is seasoning, not structure — and it kills AI's "color saves bad layout" reflex | "First pass: grayscale only — no color, verify hierarchy and spacing work in black/white/gray. Add color second." |
| Constrained scales (Refactoring UI) | AI invents 17 shades of gray and 9 font sizes. Pros pick from tiny scales: 8pt spacing, 5–7 type sizes, 2–3 weights | "Use ONLY these values — spacing: 8pt grid (8/16/24/32/48). Type: 12/14/16/20/24/30/36. Weights: 400/600. Grays: #0a0a0a, #161b22, #8b949e, #e6edf3. No values outside these lists." |
| Contrast is up/down, not absolute (Refactoring UI) | Making everything moderately pretty = nothing stands out. Loud primary, quiet rest | "The primary button is the most visually heavy element on the screen. Everything else gets less visual weight than it." |
| Alignment: everything lines up with something | AI eyeballs positions; near-alignment reads as broken | "Pick a 12-column grid. Every element aligns to a column edge or another element. No free-floating positions." |
| Don't make me think (Krug) | Obvious beats clever; users scan, they don't read; conventions (logo→home, cart top-right) exist because they work — AI 'innovating' on them breaks usability | "Follow platform conventions exactly — don't reinvent navigation or icons. Headings front-load meaning for scanning. Any choice offered to the user must be self-evident without explanation." |
| Affordances & feedback (Norman) | Things must look like what they do, and every action needs visible response — the design-theory version of the empty/loading/error rule | "Buttons look pressable, links look clickable. Every interaction gives immediate feedback: hover, active, loading, success, error. Nothing changes state silently." |
| Use familiar patterns (Refactoring UI) | Cards, search bars, tab bars are solved problems — AI inventing novel versions is usually worse, not fresher | "Use established patterns for cards, nav, and search as they appear in [reference app]. Novelty is a bug here, not a feature." |
| Form design | Labels above fields (never placeholder-as-label — it vanishes on input, and sub-16px inputs trigger iOS auto-zoom), one column, validate after blur | "Forms: one column, labels above fields, 16px+ input font, validate each field on blur with inline messages next to the field, never a single error blob at top." |
| Mobile-first | Constraints clarify hierarchy — designing small first forces the content priority you'd otherwise skip, and matches how your users actually arrive | "Design the 390px layout first. If it doesn't work there, the desktop version is wrong too. Then enhance upward." |
The design rubric pass — same trick as code
Screenshot the built screen and hand the canon back to the model as a critique rubric:
"Critique this screenshot against these principles, listing every
violation with its location:
1. Hierarchy: can I tell in 2 seconds what the ONE primary action is?
2. Grouping: is any unrelated pair visually closer than a related pair?
3. Scales: any font size, spacing, or color not in the approved lists?
4. Contrast: does the primary action outweigh everything else?
5. Alignment: does every element align to the grid?
6. Feedback: any interactive element without visible states?
Then fix each violation and re-screenshot."You don't need to be able to produce these designs — you need to recognize violations. These books train exactly that eye, and the named principle turns your vague dissatisfaction into an instruction the AI can execute.
09 Platform: where you run it matters as much as the prompt
| Surface | What it actually is | Verdict for real apps |
|---|---|---|
| claude.ai chat / Artifacts | Single-file React demo in a sandbox; no real files, no backend, no repo context | Demos only Fast validation surface — will never produce a real multi-page app |
| Claude Code (terminal agent) | Works on your real filesystem, runs tests, installs deps, takes screenshot input, uses CLAUDE.md project memory | This is the videos The loop: plan → build → verify → iterate actually lives here |
| Lovable / Bolt / v0 / Replit | Hosted builders; fast start, own deploy pipeline | Convenient Great for non-devs; consensus is terminal-comfortable users get more from Claude Code/Cursor |
| API + custom harness | Full control of system prompt, effort, tools, history | Advanced Where the official Fable 5.1 prompting guidance really applies |
If you've been prompting Fable 5.1 inside the claude.ai chat window and comparing that to videos of Claude Code session output — you've been comparing a vending machine to a workshop. Same engine, radically different leverage. Claude Code on your existing Max subscription is the intended home for this model.
10 Your four models, honestly compared
| Claude Fable 5.1 | Kimi K3 | DeepSeek V4 / Flash | GLM 5.3 | |
|---|---|---|---|---|
| What it is | Anthropic frontier model (Sept 1, 2026), above Opus 5; 1M ctx, 128K out, adaptive thinking always on | Moonshot open-weight (July 2026), 2.8T params, 1M ctx | Open-weight value line; V4 Pro has low/high/max reasoning | Z.ai open-weights, coding-focused |
| Headline numbers | Leads public coding lane 84.2 (vs Sonnet 5's 64.2); AA Index ~60 (top tier) | #1 Frontend Code Arena, Elo 1679 — beats Fable 5 in blind dev votes (#1 in 6 of 7 frontend domains); #1 Vercel Next.js evals; AA Index 57.1 | 87.9% Terminal Bench 2.1 (V4 Pro); strong long-context to ~200K; "best value on the market, not the best coder" | 91% on one independent coding benchmark (topped Opus 5 & K3 there); matches Fable 5 on 3D/UI tasks; behind Fable at max effort on Z.ai's own bench |
| Web-app UI quality | Very good — especially with references + verification loop; vision for self-QA | Best-in-class by blind human preference on generated website code | Competent, generic-leaning; not its strength | Strong UI/3D results; good value per token |
| Analyze existing apps | Best — walks real call chains in huge messy contexts, pushes back when you're wrong, 1M context | Excellent agentic stamina, long-horizon tasks, large codebases | Solid for its price; long-context capable | Good cross-file reasoning per independent tests |
| Cost | $10 / $50 per MTok; cache reads $0.25 (≈25–45% cheaper workloads vs Fable 5) | ≈$0.30 cache-hit / $3 cache-miss input — a fraction of Claude pricing | Cheapest of the four | Cheap; Flash variant you've run is ~15 tok/s (slow) |
| Known weaknesses | Stalls/over-delivers without the guardrail prompts; dense prose; pricey; at low effort answers from memory | Not quite frontier on general reasoning (57 vs 60 AA); newer ecosystem | Below GLM 5.1/Kimi on public coding boards; generic front-ends | Vendor-reported numbers; your flash variant's speed hurts agentic loops |
| Use it for | Architecture, multi-file analysis, audits, code review, long autonomous runs | Front-end/UI generation + high-volume agentic coding at low cost | Volume/mechanical tasks, bulk edits, budget runs | Cost-effective coding passes; UI when tuned |
Numbers from Arena.ai's blind Frontend Code Arena, Artificial Analysis Intelligence Index, Terminal Bench, Vercel evals, and vendor docs as of Sept 2026. Benchmark lead changes monthly — treat rankings as a tiebreaker, not a religion; the workflow section above moves the needle more than any of these deltas.
11 Recommended setup for your stack
- Build real apps in Claude Code (you already run it on vps-apps with your Max sub) — not the claude.ai chat window. Add a
CLAUDE.mdper project with build/test commands, style rules, and gotchas. - Route front-end generation to Kimi K3 where your Kimi subscription makes it available — it's the current blind-vote champion for exactly the "looks like crap" problem, at a fraction of Claude token cost. Keep your existing highspeed Kimi routing for mechanical speed work.
- Use Fable 5.1 for the hard thinking: analyzing an existing app, architecture calls, gnarly root-cause hunts, final review. Paste the autonomy + scope + targeted-edit guardrails from section 04 into its system prompt or first message.
- DeepSeek V4 for volume work — bulk mechanical edits, format conversions, cheap passes where style doesn't matter.
- GLM 5.3 as a cost-effective coding pass — but your Flash variant's ~15 tok/s will make agentic loops painful; prefer the standard variant for anything tool-heavy.
- Always close the visual loop: screenshots in, screenshots out. This single habit is the biggest separator between your results and the videos.
12 Sources
- Prompting Claude Fable 5.1 — official Claude Platform docs
- Introducing Claude Fable 5.1 and Mythos 5.1 — Anthropic
- Claude Fable 5.1 model overview — Claude Platform docs
- Arena.ai: Kimi-K3 #1 Frontend Code Arena, 1679 pts
- Tom's Hardware: Kimi K3 beats Fable 5 in Frontend Code Arena
- Kimi K3 tops Vercel Next.js evals — explainx.ai
- Kimi K3 review: AA Index 57 vs Fable 5's 60
- DeepSeek V4 review — "best value, not best coder"
- GLM-5.3 benchmark results vs Opus 5 / Fable 5
- Fable 5.1 vs Sonnet 5 coding lane — benchlm.ai
- Why your AI-generated UI looks bad: 15 mistakes — GenDesigns
- Fable 5.1 AI website design: the 7-step workflow — SolidAITech
- 12 Fable 5.1 prompting techniques — DDS Hub
- "Used Fable 5.1 all day" — hands-on thread, r/claude
- Vibe coding with Claude Code (screenshot loop) — r/ClaudeCode
- Using Fable in Claude Code: architect, not autocomplete — Wavect
- 35 AI prompts for code review, debugging & refactoring
- 18 copy-paste coding prompt templates
- 5 prompt mistakes that make AI generate worse code
- Why AI-built websites look the same — Unpromptable
- Claude Artifacts vs Claude Code — ShareDuo
- AI code quality crisis: 4× duplication since AI adoption — byteiota
- DRY vs AI-generated code — Faros AI
- agent-rules-books — Clean Code/Refactoring/DDD distilled as AGENTS.md rules (Matt Pocock)
- Clean Code for AI Agents — AkitaOnRails
- Refactoring UI — Wathan & Schoger (book)
- Books: Clean Code (Martin) · Refactoring (Fowler) · The Pragmatic Programmer (Hunt & Thomas) · Don't Make Me Think (Krug) · The Design of Everyday Things (Norman)