How I’m actually using Fable 5 with loop engineering
Everyone one-shot a landing page with it. I create loops.. How i m using Fable 5, with loops for debugging my codebase and an example for my marketing usage.
I had not been surprised by a model in about a year.
I run Opus every day. I know roughly what a good one hands back before I finish reading it. So when Fable 5 landed I did not one-shot a landing page with it like everyone else that week. I pointed it at my own SDK, read only, and asked where the code breaks when you build on top of it. It found eleven real problems, each cited to a file and a line, six more than the two other models I ran on the same job. I had a cheaper model re-check all eleven against the source. None got refuted.
That was the surprise. It is not what this piece is about.
My last 7 days in Claude Code. Opus 4.8 and Fable 5, split about 58/42. This is not a test drive: Fable does roughly 40 percent of my real work now.
Because a model that good at finding things is only worth the bill if you do something with the finding, and “chatting with it” is not that. The way I actually use a model like this is the way I use every model now. I do not talk to it. I put it in a loop, and I spend my own time on the one part of the loop that still needs me.
Here is the loop, the prompts, and the part that does the real work.
What a loop actually is
Every loop has the same four beats.
Goal. You write down what done means before anything runs. Not a vibe, a test. Something that can come back true or false.
Act. The model takes one step toward that goal.
Check. Something compares the result against the goal.
Repeat. Failed the check, go again. Passed, stop.
The check is the beat everyone skips. It is also the whole game, and I will come back to it, because it is where finding a bug and actually shipping a fix stop being the same thing.
For content people the goal might be “beats my best newsletter.” For me the goal is a codebase that stays green. Same shape, different done. I run this loop as a system I call Spec Harness: plan, spec, build, verify, learn. The model does the building. The verify step is the check. The learn step is what makes tomorrow’s loop tighter than today’s.
The loop, four beats. Goal, act, check, repeat. The check is the one everyone skips.
How I prompt Fable for the read that sets the goal
The loop needs a goal, and for code the goal starts with an honest read of what is actually wrong. That read is the one place I pay for the frontier model, because it is a single expensive pass I run once, not the grind that comes after.
Four things make the read worth the money.
Give it the reason, not just the task. “Audit this SDK, two apps are about to ship on top of it” gets a sharper read than “find bugs.”
Set a boundary. Read only. It audits, it does not touch the code. Finding and fixing are different beats of the loop, and letting one model do both in one breath makes both sloppy.
Make it cite everything. Every finding points at a real file and line. A made-up bug cannot cite a real location, so this one rule kills hallucinations. It is also how I spot-checked eleven findings in minutes.
Make it grade itself. Rate each finding high, medium, low. A model that will admit “medium, not certain” on its weak calls is one you can trust on the strong ones.
The paste-able version, adapt the paths to your repo:
Audit the architecture of <package or feature dir> in this React Native / Expo app. Read only. Do not edit a single file.
Context: this ships to real users on real phones in a few days, and other screens (in my case, other apps too) are being built on top of it. I care about the problems that survive to production and page me at 2am, not style nits.
For every problem you find:
- cite the exact file and line
- explain how it breaks when someone builds on top of it, or when it hits a real device: slow or dropped network, the app backgrounded mid-request, low memory, a cold start, or the OS killing and restoring the process
- name the layer it lives in: state, navigation, data fetching, a native module, or the public API other code depends on
- rate your confidence high / medium / low, and for anything medium, say exactly what you’d need to read to make it high
Prioritise, in this order: silent data loss, a failure the user never sees but that corrupts state, anything that only breaks after the app is killed and reopened, and any API shape that forces a breaking change on the screens already built on it.
Do not pad the list. Ten real, cited problems I can fix today beat forty maybes. If an area is genuinely solid, say so plainly instead of inventing a finding.Then I hand the list to a cheaper model and ask it to refute each finding against the source. Zero of the eleven survived as false. Frontier finds, cheap checks, I do neither by hand. That verified list is the goal the rest of the loop runs against.
If you do not write code, the same four rules work on anything you ship. Here is the one I run on the marketing side once a week. It reads the week’s news in my space, hands back posts I could actually publish, and ranks them against what has already worked for me. Different job, identical bones: give it the reason, keep it read-only, make it cite every claim to a real source, make it grade its own confidence.
Scan the last 7 days of news and discussion in <your space>. Read and gather only, publish nothing.
Goal: three posts I could ship this week that would beat my best-performing post, not generic hot takes.
For each one:
- link the exact article, thread, or number it is built on (no angle without a real source)
- write it as a post I could publish as-is, in my voice, not a summary of the news
- name which of my patterns that has worked before it matches, and why it should land
- rate your confidence high / medium / low; for any medium, say what you would need to know about my audience to make it high
Then rank the three against what has actually worked for me before, and tell me the one you would cut.
Do not pad. One post I can ship today, tied to a real source, beats five vague trend-chases.Swap “posts” for “emails,” “landing sections,” or “feature ideas” and the shape holds. The domain changes; the four rules do not.
The effort dial, and the one place I still switch models
The advice going around is to stop switching models and just use Fable’s effort dial. Turn it down for easy work, up for hard, one model for everything. For a single reasoning pass, that is right. I leave the dial on high, push it up when the read is genuinely hard, and I stopped babysitting the model picker for one-shot work.
The dial does not save you inside a loop, though.
A build loop iterates for hundreds of turns, and every turn re-sends a growing context at the model’s per-token rate. That rate is what compounds, not how hard the model thought on any single turn. I watched the same cheap model that audited my SDK for fifty nine cents spend four dollars building one fix, because building means running tests and reading errors over and over. Put a frontier model on that loop with the dial turned down and you are ordering the cheap wine at a three-star restaurant. You saved on the wrong line.
A normal day. I run the window down to the wall, it resets, I do it again. That is what “I actually use it” looks like on the invoice.
So I do both. The dial for the single read. A cheaper model for the loop that grinds. One is a knob inside a model, the other is a knob across phases. They are not the same knob.
Pay the frontier rate once for the read. Drop to a cheaper model for the build loop, where the cost compounds every turn.
Building the loop: the check is the part you actually build
Writing the loop is easy. Writing the check is the job.
Charlie Hills, whose piece got me writing this one, builds his check as a rubric. He fed a model a hundred and ten past newsletters plus their engagement numbers, had it pull out a scoring rubric, and now a separate judge agent scores every draft against it until it clears the bar. Separate judge, on purpose, so nothing grades its own homework.
My check is not a content rubric. It is tests, plus agents that read like a senior reviewer, all run in a clean context so nothing marks its own work.
The check is tests plus a reviewer agent plus a workflow-tester, all in a clean context so nothing grades its own homework.
Two of those agents earn their keep every week.
A reviewer agent. I was wiring the same AI onboarding into two apps at once, mine and a client’s, built days apart. The reviewer read both and found the same three mistakes in each. Config hand-rolled separately instead of calling the one shared helper, the copy-paste that drifts the second you touch it. An onboarding that asked the user what they cared about and then threw the answers away before saving, a quiet data-loss bug I would never have caught by eye. And a fallback I promised in a code comment and never wired, so a backend timeout would have dead-ended the new user instead of dropping them back to the old flow. Three real bugs, twice, caught by the check, not by me.
A workflow-tester agent. On another job it caught a status-code bug: a database outage was reaching the client as the wrong HTTP code, a four hundred where it had to be a five hundred. The kind of thing that passes every happy-path test and pages you at 2am.
That is the check. It is boring, it is most of the work, and it is the reason I can let the loop run on something without watching it.
The one Fable finding I actually shipped went through exactly this. The goal was a failing test for a timeout bug it found, a path that advertised a sixty second limit in its own docstring while a hidden thirty second cap killed the request first. Opus wrote the fix. The check ran the full suite, eighty eight of eighty eight green, plus the review gate, before it ever became a pull request. Goal, act, check, repeat, then stop.
Your codebase is the moat
Charlie’s line is that your data is the moat, because every model read the same internet and everyone’s output sounds the same, so the differentiator is your own history fed into the loop. For code it is the same idea one layer over.
Every model has read the same open source. What it has not read is your bugs.
The learn step of my loop turns every bug the check catches into a dated rule the harness enforces next time. The reviewer’s three mistakes became an eight-point review bar, so app number three cannot repeat what apps one and two did. The eleven Fable findings, the ten I deferred, the triage note for when they come back, all of it is a private test set that grows every week and belongs to nobody else. A general model finds a bug. My harness knows which bugs I keep making. That accumulation is the thing you cannot download.
41 million tokens, a 9-day streak, active every single day. The loop is a habit, not a demo, and the rules it has ratcheted out of my bugs are the part nobody else has.
The check is the job
Finding got cheap. Fable proved it on my own code, eleven real problems for the price of lunch, better than I did by eye. That skill, the one you used to pay a senior nine years in for, just got commoditized.
The check did not.
The tests you wrote, the rules you ratcheted out of your own mistakes, the judgment to ship one finding and defer ten in launch week because you know which ones touch the path that is actually shipping, none of that came in the box. A model in a loop with no check is a confident intern shipping unwatched. Slop is a failure of judgement, not tooling, as Charlie puts it. The loop scales you exactly as far as your check is good, and not one inch further.
So that is how I actually use Fable 5. I do not chat with it. I pay it once for the honest read, I drop to a cheaper model for the grind, and I spend my own time on the check, because that is the part that is still mine.
Finding what is wrong is free now. Checking it is the job.
Want the loop itself? Reply LOOP and I will send the loop starter kit, the four-part loop plus the verifier and ratchet templates I actually run it on.
Written by Malik Chohra, AI-first mobile engineer, 9 years building health, wellness, and coaching products (Mindshine, acquired by Greator; DocMorris; CoachHub). I build the AI-native infrastructure the next wave of mobile products runs on, and write about it every week.
The newsletter runs on receipts like these. Real numbers, real bugs, real loops, no hype. Subscribe at codemeetai.substack.com.