DEV Community: Malik Chohra

Claude Cowork acts across your files now. Confidence is not correctness.

Malik Chohra — Tue, 14 Jul 2026 08:12:31 +0000

TL;DR

Chat makes you drive every step. Cowork flips it: you describe the outcome, it plans the steps, works across your files and connected apps, and hands back the finished thing.
Anthropic says more than 90% of Claude Cowork usage is not software development. It is expense memos, contract trackers, client decks, folder cleanup. This week it went to web and mobile, and scheduled tasks run with no device online.
That is a governance surface, not just a convenience. It acts across whatever you connect, and it is confident when it is wrong. Scope the access, keep the review.
Start with one task you already resent, give it context first, and check its work like a code review.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.

This Monday Anthropic put a number on something most of us felt but hadn't measured. They expanded Claude Cowork to web and mobile and shared what people actually run on it: more than 90% of usage is not software development. Not code. The biggest categories were business operations and content work. Reconciling the quarter's spend and drafting the memo about it. Turning a folder of contracts into a renewals tracker with the risks flagged. Building tomorrow's client deck from call transcripts.

They call it "the work around work." Good name. It is the layer of the job that is real work, takes real hours, and somehow is nobody's actual job.

If you write code, you have had this delegation engine for a year in the terminal. Cowork is that same engine pointed at everyone else's work. The interesting part for us is not the convenience. It is that the tool now acts, on its own, across whatever you connect it to. That changes what "review" means.

what Cowork is, in one honest paragraph

You already know chat: you ask, it answers, you ask again. You are the project manager of every tiny step.

Cowork is the same Claude with a different job description. You hand it an outcome: "turn this folder of contracts into a renewals tracker, flag anything risky." It makes a plan, breaks it into steps, works across the files and apps you have connected, and comes back with the finished thing. While it runs, you do something else. Since this week it follows you: start a task at your desk, check the status on your phone, pick up the result later with the laptop closed. Scheduled tasks run even with no device online.

Chat: you drive. Cowork: you describe, then review.

my actual Claude home. one toggle flips chat into Cowork, and "send me a daily briefing" is already sitting there as a suggestion.

One tool, two jobs, and the second job is most people's actual day.

what people actually run on it

Not moonshots. Chores. The patterns showing up again and again in the early write-ups:

Folder archaeology. Sort, rename, and deduplicate a cluttered folder. Rename 400 photos to match the product list. The task postponed for a year because it is three hours of mind-numbing clicking.

Pile of documents, should be a list. A folder of contracts becomes a renewals tracker with dates and risk flags. A stack of receipts becomes an expense sheet. Dense PDFs in, structured table out.

The recurring report. The weekly status, the morning brief, the numbers pulled into the same format every Monday. Described once as a routine, in plain language: what to gather, what format, where to deliver it. It runs every morning without you. Cron, described in English, with file and app access.

First drafts from your own material. Tomorrow's client deck from the call transcripts. The variance memo from the spreadsheet. Not "write me something generic," but "turn my raw material into my draft."

The common shape: high effort, repeatable, source material already in your files.

the part that should get your attention

Here is where the senior-dev instinct earns its keep. Two things about this tool are load-bearing, and both are easy to wave past.

It has access to what you give it. That is the feature and the risk in one sentence. Connect the folders and tools the job needs, not everything you own. This is least privilege, the same principle you apply to a service token or an OAuth scope, except the person setting it up may never have thought about blast radius in their life. A general-purpose agent with read and write access to your whole drive is a very different thing from one pointed at a single project folder.

And it is confident, including when it is wrong. A renewals tracker with one silently wrong date is worse than no tracker, because someone will trust it. You already know this shape from AI-generated code that compiles clean and still ships a bug. The difference is that a non-engineer has no compiler, no test suite, no diff habit to catch it. The review step is not optional politeness. It is the entire job that does not get automated away.

So the honest framing is not "AI does your admin now." It is "AI does your admin now, and it needs the same governance you already give your code: scoped access, and a review before you trust the output."

how to start: one resented task

Don't tour the features. Pick the one task you flinched at earlier. Then:

Give it context first. Before the task, point Cowork at a short context file: what this project is, what good output looks like, what to leave alone. If you have given an AI a memory folder before, this is the same muscle. Two minutes, and the output quality jump is not subtle.
Describe the outcome, not the steps. "Make this folder make sense: group by client, newest first, flag anything duplicated" beats a 12-message back-and-forth.
Review like a manager, not a believer. Open the deliverable, spot-check five rows against the source. A code review with different file types.
If it worked twice, make it a routine, and scope it tight. Describe it once, give it access to exactly the folder it needs, and stop doing it forever.

the punchline

The AI didn't take the work. It took the work around the work. What's left over is the part that needed you all along: deciding, and checking. For us that is not new. We just called it code review and least privilege. The rest of the world is about to learn why we were so annoying about both.

I am putting together a routines starter pack: three plain-language routine templates (the folder cleanup, the pile-to-tracker, the morning brief) you can adapt in five minutes. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 03 of Using AI, properly. Episode 02 was give the AI a memory, episode 01 was the art of prompting. New guides land there first.

i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. The delegation habit started in the terminal, moved to my second brain, and now it does the work around the work. Next up: where a single sentence stops helping, and context begins.

Memory you can't inspect is memory you can't trust

Malik Chohra — Fri, 10 Jul 2026 14:48:10 +0000

TL;DR

Every new session your AI starts from zero. It doesn't remember you, your repo, or the thing it got wrong yesterday.
The fix is not a feature you wait for, it's a file you write. Two, actually: house rules (CLAUDE.md) and a diary (a memory folder).
The habit that makes it work: end each session with "what should you remember from this? write it down," and save the answer as one small note.
Wrong memories are worse than none. Keep each note to one fact so you can delete it the day it stops being true.

This piece is from Code Meet AI, my newsletter where i document how i actually use AI to ship real products, receipts included. New guides land there first.

This Tuesday my AI told me a piece of work was shipped. Merged, published, CI green, the whole report. It wasn't. The server was still serving week-old code, and i only caught it because i went and hit the actual endpoint instead of trusting the summary.

Annoying. But here is the part worth stealing. Instead of fixing it and moving on, i had the AI write the lesson down. One small note in the project's memory folder: "merged is not deployed. before you say shipped, curl the live thing and check the release SHA against the merge, twice."

Next morning, new session, zero context, the model has no memory of Tuesday. I run an npm publish and it stops me: the version on the registry didn't match the build we had just tested. It caught the exact same class of mistake, on its own, because Tuesday's note was sitting in a file it reads on startup.

That's the whole trick, and it lives in your repo, not in some feature you're waiting for.

I didn't plan any of this. It grew out of my repos. Each project got a small folder of markdown the AI reads before it writes a line of code, so it never opens the thing cold. That worked well enough that i lifted the whole pattern out of the codebase. My second brain runs on it now, the Obsidian vault too, and every work session i close ends by writing to the same kind of file. The pattern i built for my repos runs my notes.

your AI opens the project blind

You know this if you pair with Claude Code or Cursor daily. The first ten minutes of every session go to re-explaining the same things. The stack, where the API client lives, which files are generated, the conventions you moved to and the pattern you moved off. Good session. Next morning it opens the repo like it has never seen it.

So you type it all out again. Every day.

There was a thread on r/ClaudeAI this week, roughly titled "I often forget how many people are clueless when it comes to Claude (or any AI)." A bit harsh. The gap it points at is real though, and it is not intelligence, it is setup. The people getting compounding value out of these tools are not smarter. They stopped re-briefing the assistant every morning.

A session is a phone call. When it ends, the other side keeps no notes unless somebody writes them down. So write them down.

two kinds of memory, two files

Everything worth keeping splits into two buckets, and they belong in two different places.

House rules. The stuff that is always true: the stack, the conventions, the boundaries, the things it should never touch. One standing file the AI reads at the start of every session. In Claude Code that file is literally CLAUDE.md. Cursor calls it .cursorrules, some tools read AGENTS.md. Same idea everywhere, a one-page briefing that is just always there.

The diary. The stuff it learns as you go: a correction, a decision that closed a debate, a gotcha. "The Android build breaks if you bump reanimated past the pinned version." "We dropped the March API, stop importing it." "Merged is not deployed." Learned facts, they change, so they don't belong in the house rules.

Here is the part people overbuild. On day one the diary is one file. Make a memory.md in the repo root, tell the AI to read it at session start, and add a line whenever something worth keeping shows up. A working memory system, no framework, no folder. The folder version is an upgrade you grow into, and i'll show you mine in a minute. But it starts as one file you could open in any editor.

House rules are written once and edited rarely. The diary grows a note at a time.

Why the split matters: CLAUDE.md you write once and edit rarely, the diary grows every week and any note in it can turn out wrong later. Mix them and your always-on briefing slowly fills with stale facts, the one file you least want rotting. Keep them apart and each stays honest.

The tools already exist and you'll meet them as you go. Claude Code reads CLAUDE.md plus a memory folder automatically, the community ships things like claude-mem that record whole sessions, ChatGPT and Claude both have built-in memory they fill on their own. All fine. The plain file has one quiet advantage though: you can open it, diff it, and delete the wrong bits, and git already keeps the history. Memory you can't inspect is memory you can't trust, and a file you wrote is the most inspectable memory there is.

the capture loop

The memory folder doesn't fill itself. The habit that fills it takes about two minutes.

At the end of a session, ask: "what should you remember from this session? write it down."

That's it. Every correction, every "actually, do it this way," every decision that closed a question becomes a candidate. The AI writes each as its own small note and adds a line to the index.

I'm not the only one on a version of this. One of the most upvoted posts on r/ClaudeAI this month, close to three thousand upvotes, was titled "I end every AI session with two questions." The session-ending ritual is quietly becoming the power move, because it converts a good session, which evaporates the moment you close the tab, into a note, which does not.

One turn of the loop per session. It compounds fast.

Mine runs on two habits. During the day, anything worth keeping gets dumped into an inbox note without stopping to sort it. At the end of a session the AI does the ritual: sorts what it learned, writes the notes, updates the index. Next morning it reads the index and picks up where we left off.

the memory bank: one folder per repo

Once the one-file memory.md clicks, there's a natural upgrade, and it's still just files. I call it a memory bank: one small folder per repo, two files inside.

The first is the context: what this repo is, the stack, the conventions, the boundaries, the things the AI must never touch. You write it once and edit it rarely. The second is the progress: a dated log of where the work actually stands, updated at the end of each session. Drop both in a .memory/ folder in the repo (or docs/, wherever your team already looks) and point the AI at them on startup.

Here's the whole thing:

your-repo/
  .memory/
    context.md    stack, conventions, boundaries, hard no's. written once.
    progress.md   2026-07-09: shipped the auth refactor. open: token-refresh race. next: wire the retry.

Same shape for every repo you touch. The context file barely moves. The progress file is a diary with dates. Open a session, the AI reads both, and it starts from where the code actually is instead of from zero. This is not theory for me: my whole work life runs on these folders, and the "merged is not deployed" catch from the opener came straight out of one.

You don't have to hand-roll it either. Paste this into the AI once, per repo:

I want to give you a memory for this repo. Do two things.

First, create .memory/context.md. Interview me before you write it: ask one question at a time about what this repo is, the stack, the conventions, and the things you must never touch. Then write a one-page briefing you would want to read at the start of every session.

Second, create .memory/progress.md. Start it with today's date and one line: where the work stands right now.

From now on, read both files at the start of every session on this repo.

And at the end of each session, this one:

Before we finish, update .memory/progress.md. Add today's date and 3 to 5 lines: what we did, what we decided, what is still open, and anything you should remember next time. If i corrected you today or gave you a convention, put that in context.md instead. Keep both files short. Cut anything that is no longer true.

That second prompt is the whole engine. It's the capture loop from the last section, turned into a habit you can paste.

one fact per note, so you can fire it

The rule that took me longest to learn: one fact per note.

Not a session summary. Not a changelog. One fact, a couple of lines, with a date. "2026-07: merged is not deployed, verify the live endpoint before reporting shipped." That's a whole note.

The reason is not tidiness. Memories go stale, and a stale memory is worse than no memory, because the model states it with full confidence. The component gets refactored, the workaround you swore by gets fixed upstream, the dependency you pinned moves on. When each fact lives alone, you delete that one note and the rest stays intact. When facts live tangled in a long summary, you can't pull the rotten one without rewriting everything, so nobody does, and the whole thing quietly rots.

My memory folder is a few months old now. Notes get added most days, and deleted too, and that is not the system failing, that is the system working. Tuesday's "merged is not deployed" note earned its place by catching a real mistake inside twenty-four hours. A note that never fires again for months gets cut.

where this breaks

Honest limits, because there are some.

Memory doesn't make the AI right, it makes it consistent. Write down a wrong fact and you now have a machine that repeats your mistake politely, forever. Re-check anything important that came out of memory, especially anything with a date on it.

No secrets in there. Tokens, keys, other people's private data. A memory folder is a plain readable file and it's probably tracked in git, so treat it like one.

And don't over-collect. The goal is not to remember everything, it's to stop re-explaining the same ten things. If your index runs longer than a page, you're hoarding, not remembering.

start on your next branch

Two files. A CLAUDE.md with your stack and conventions. An empty memory folder with an empty index. Then end your next session with "what should you remember from this?" and let it write note one.

That's the whole setup. The assistant you pair with next week already feels different from today's, and the gap only widens from there.

I put together a memory starter pack: the CLAUDE.md template i actually use, the note format, the index file, and the exact session-ending prompt. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 02 of Using AI, properly. Episode 01 was the art of prompting. New guides land there first.

i'm Malik, i've been a mobile engineer for 9 years, and i run my work and this newsletter on the system these episodes describe. The memory folder is where the second brain and this newsletter both live now. Next up: putting the AI to work on the work around the work.

Loop engineering with Fable 5

Malik Chohra — Wed, 08 Jul 2026 19:52:33 +0000

TL;DR

I pointed Fable 5 at my own React Native SDK, read only. It found 11 real bugs, each cited to a file and a line, six more than the two other models on the same job. A cheaper model re-checked all 11 against the source. 0 got refuted.
Finding bugs just got cheap. The moat moved to the check: tests plus reviewer agents run in a clean context, the part that does not come in the box.
A model in a loop with no check is a confident intern shipping unwatched. The check is the discipline that keeps it useful instead of dangerous.
Below: the two paste-able prompts I run (a read-only architecture audit and a weekly news loop), the receipts, and the loop I run them in.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first. It was originally published there.

Finding bugs used to be the expensive, senior skill. Then I pointed Fable 5 at my own React Native / Expo SDK, read only, and asked where the code breaks when another app builds on top of it. It handed back eleven real problems, each cited to a file and a line, six more than the two other models I ran on the same job. A cheaper model re-checked all eleven against the source. Zero got refuted.

That should scare you a little, not excite you. A model that good at finding things, wired to also fix and ship them unwatched, is a confident intern with commit access. The risk is not that it is wrong. The risk is that it is confidently, plausibly wrong on the one path that actually ships, and nobody checked. The discipline that keeps that intern useful instead of dangerous is the check. That is the whole job now, and it is the beat everyone skips.

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.

So 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 run 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? The loop starter kit is 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, including getwireai.com and aimobilelauncher.com.

This was one issue of Code Meet AI. I document how I actually use AI to ship real products, receipts included, and new guides land there first. Subscribe at codemeetai.substack.com.

GLM 5.2 for 59 cents: the read is cheap, the build isn't

Malik Chohra — Tue, 07 Jul 2026 17:21:40 +0000

TL;DR

GLM 5.2 is the open-weight model everyone is benchmarking right now: a tenth of Claude's price, a one million token context window. Instead of reading takes, I ran it on my own SDK.
The setup is five lines in your Claude Code settings, routed through OpenRouter. Pin the Z.ai provider and turn off fallbacks, or you might be testing a quantized knockoff.
The architecture read: 41 files, every citation real, 59 cents, six minutes. The build: it worked, 92 tests green, but cost four dollars, most of it test-loop stamina.
My split now: GLM for the reading, Claude for the building. Private code never leaves my machine, cheap or not.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

My Claude Code bill had been bothering me for a while. Not scary numbers, just creeping ones. I run a lot of agents, sometimes a whole harness of them at once, and the number at the end of the month kept drifting up. So I went looking for a cheaper engine, and the thing everyone kept pointing at was a Chinese open-weight model called GLM 5.2.

Two reasons I wanted to try it. One was pure cost. If a model a tenth of the price could do even half my work, that's real money back. The other was a curiosity I'd been avoiding, if I'm honest. The Chinese labs have been shipping fast, the benchmarks look absurd, and I had never actually run one of their models on my own code to see past the marketing.

So I put five dollars on OpenRouter and decided to stop reading takes. I'd run GLM on the one codebase I know better than anyone, my own generative UI SDK, and check every line of what it gave back.

This is what I did, what it cost, and the part I got wrong before I started.

The setup, because it's shorter than you think

GLM 5.2 is an open-weight model from Z.ai. It came out in the middle of June, it has a one million token context window, and the thing people keep saying about it is that it codes like a frontier model for a fraction of the price. The public numbers back the noise up: on OpenRouter's Design Arena board it sits in the top one percent for code, across more than three thousand head-to-head tournaments. I didn't want to take that on faith either. Benchmarks are somebody else's code.

The public claim, as of this week: top one percent for code on Design Arena, 3,243 tournaments. This article is me checking it against my own repo.

Claude Code doesn't care which model sits behind it. It speaks the Anthropic API format, and it reads two environment variables to decide where to send requests. Point those at a different endpoint and the whole tool keeps working, same agent, same file editing, same test running, different brain.

I used OpenRouter as the endpoint. The reason is simple: one account, one API key, and it can route that key to dozens of model providers including Z.ai. I didn't want a separate billing relationship with a Chinese lab to run one experiment. OpenRouter sits in the middle, I top up a few dollars, and I can try any model behind one key.

Here's the whole path, start to finish.

Three steps to set it up.

First, make the key. On OpenRouter you create an API key and put a few dollars of credit on the account. There's no free GLM 5.2 tier, but the credit goes a long way, my whole experiment ran on five dollars and I didn't finish it.

Creating the key. The credit limit field is the safety net: mine got five dollars, hard cap.

The same key after the experiment: $4.59 of the five dollar cap used. Everything in this article ran inside that.

Second, point Claude Code at it. Five lines in your Claude Code settings:

ANTHROPIC_BASE_URL = https://openrouter.ai/api
ANTHROPIC_AUTH_TOKEN = your_openrouter_key
ANTHROPIC_DEFAULT_OPUS_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_SONNET_MODEL = z-ai/glm-5.2
ANTHROPIC_DEFAULT_HAIKU_MODEL = z-ai/glm-4.5-air

Drop that in, start Claude Code, and you're talking to GLM. To go back to Claude you comment it out. That's the entire switch.

Third, and this is the step most people skip, pin the provider. On OpenRouter the same model name can be served by a long list of different companies, and the prices are all over the place, from under a dollar per million tokens to over three. That spread is not a coincidence. Some of those hosts run quantized copies of the model, smaller and faster and measurably dumber, and the Providers tab even has a quantization filter because of it. If you let OpenRouter auto-route you might land on one of those, and then you're testing a compressed knockoff while thinking you're testing the real thing.

Same model name, a dozen hosts, a real price spread. This is why you pin the provider.

I set the routing to Z.ai directly, the first-party host, and turned off fallbacks. Every request hit the real full-precision model and nothing else. If a fair comparison is the point, this toggle is the whole game.

The part I got wrong: my own code is not all mine to share

Here's the mistake I almost made. I was about to point a third-party model at my whole monorepo.

My SDK is open source. But sitting in the same repo are the things that are not open: the dynamic onboarding kit, the billing, the tenant logic, the work that's supposed to make money. Sending that to a hosted model in another country is exactly the kind of casual leak you only notice after it's gone.

So before anything ran, I built a clean copy. I pulled out only the showable parts, the SDK package and the mental coach example with its agent backend, and I left the commercial code on my disk where it belongs. Then I did the boring but important step: I searched the copy for the words that would give the game away, onboarding, billing, tenant, stripe, and confirmed there were zero hits before a single token left my machine.

That habit is the whole point. The model being cheap doesn't change the rule. Public code can go to a hosted API. Private code either stays local or it doesn't go at all. I wrote about choosing a more expensive but EU-safe model for a client backend a while ago for the same reason, and the logic didn't change just because this one was fun to try.

Task one: read my SDK and tell me where it breaks

The first job was a pure reading test. I told GLM to audit the architecture as if I were about to build a new generation of tooling on top of it. Find the load-bearing seams. Name the files. Tell me what will crack first. And the rule that mattered most: cite a real file and line for every claim, and if you're not sure, say so instead of inventing something.

It read forty-one files. Then it handed me an audit that found the three real problems I already knew were there.

It found that my component types are sealed into the bundle when the app starts, which means an agent can't define a new component at runtime, which is the exact thing my next feature needs. It found that streaming is quietly dead on my main agent path, because the adapter that handles it never implemented the streaming method. And it found a drift bug I'd been ignoring, where my SDK can render thirteen components but the server only allows eleven of them and only tells the model about seven, so two perfectly good components were unreachable through the agent.

I didn't take its word for any of this. I went through its citations and grepped each one against the code. They were real. The file paths were right, the line numbers were right, and it hadn't made up a single function. It even caught something I hadn't flagged: a comment in my backend that proudly says it uses the latest Claude models, sitting directly above code that actually calls a cheaper OpenAI model. A stale comment that became a small lie. Good eye, for a model I was ready to dismiss.

That audit cost fifty-nine cents and took six minutes.

Task two: now fix one of them

A read is one thing. Reading is where every model looks smart. So I said: ok, you can read my code. Now touch it.

I gave it the hardest fix from its own audit: kill the component drift for good. Make the SDK the single source of truth, generate a manifest from it, and have the server read that manifest instead of its own hand-typed list, so the two can never fall out of sync again. And write a test that fails if they ever do.

It did it. It generated the manifest, rewired the server to read it, promoted the two orphaned components into real SDK built-ins so they were finally reachable, and wrote a drift guard test. When I ran the suite myself, ninety-two tests passed, the original eighty-seven untouched and five new ones added. Then I tried to break it on purpose. I deleted a component from the manifest by hand and re-ran the guard. It failed, loudly, exactly where it should. The safety net had teeth.

It also hit a genuinely annoying toolchain trap along the way, a syntax issue in React Native that stops the test runner from loading certain files, and instead of hiding it or giving up it built a small workaround and then wrote the problem down in its report as a caveat. That honesty is worth more to me than a clean-looking result.

The catch, because there is always a catch

The build cost four dollars. The read cost fifty-nine cents.

The receipt behind the "ten times cheaper" line: same audit, same 41 files, priced twice.

That's the number nobody in the hype videos mentions. On the reading task GLM was a clear win, ten times cheaper than what I usually run, and three times faster. On the build it succeeded, but it spent most of those four dollars not on the fix itself but on grinding through the test harness, run the tests, read the error, edit, run again, over and over, three hundred turns of it. The actual code changes were maybe thirty of those steps. The rest was stamina.

So the lesson I'm keeping is not "GLM replaces my setup." It's narrower and more useful than that. For reading, reviewing, auditing, explaining a codebase, the kind of work where the model thinks hard once and hands you an answer, GLM 5.2 is a genuine bargain and I'll reach for it on purpose. For long unattended building, where the cost is paid in debugging loops, it works, but the price gap closes and the reasons I pay for a frontier model come back into focus.

Five dollars, one afternoon, my own code, and a clear answer instead of a feed full of opinions. That's the cheapest research I've done all month.

How I actually use this now

Two routes, depending on the code.

For anything public, I keep the OpenRouter config above in a commented block in my Claude Code settings. When I want a cheap second opinion on an open-source repo, an architecture read, a "what is wrong with this," I uncomment it, pin Z.ai, and let GLM do the heavy reading for cents. Claude stays my default for the building.

For anything private, the model goes to the code, the code doesn't go to the model. Local weights or nothing.

If you want the exact settings block, the provider-pinning step, and the little script I use to strip a repo down to the showable parts before sending it anywhere, reply LOCAL and I'll send it over.

This was one experiment in a longer thread I keep at Code Meet AI, where I document how I actually use AI to ship real products, receipts included. It's the hosted-model sibling of my post on running Claude Code offline with a local LLM. Next week: the full three-way comparison, GLM against the frontier models on the same tasks.

If you have run GLM 5.2 or another cheap model on real code, where did it hold up and where did it fall apart for you? I'm still calibrating my own split, and the build-cost number surprised me most.

The one habit that fixes generic AI answers (and 7 ways to ask)

Malik Chohra — Mon, 06 Jul 2026 10:41:07 +0000

TL;DR

You don't need to be technical to prompt well. You need to stop typing three words and hitting enter.
The one habit that fixes almost everything is context: tell the AI who it should be, what you want, and what a good answer looks like.
Seven simple ways of asking cover most of daily life, from summarizing an email to planning a week of meals.
The best place to practice is your own life: your messages, your plans, your notes.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real things, receipts included. New guides land there first.

Prompting is just how you ask an AI for something. The AI reads your words, not your mind, so a lazy question gets a lazy answer. The fix is context: tell it who you want it to be, what you actually need, and what a good result would look like. After that, a handful of simple patterns handle almost anything. No jargon. You get good by practising on the things you already do every day.

The AI reads your words, not your mind

The first time a lot of people try one of these tools, they type something like "make me 1 million," read the bland thing that comes back, and quietly decide it is overrated. I did a version of this for months. I treated it like a smarter Google, typed three words, and was annoyed when i got three-word-quality answers back.

Spoiler alert: the "make me 1 million" prompt doesn't work. Which i think you already know by now.

What changed for me was not a better app. It was an afternoon in a park. Instead of firing one-line questions at it, i opened the AI on my phone and just talked to it for about three hours: what i was working on, what was stuck, what i had been avoiding. By the evening it could help me in a way it never could when i was firing one-liners at it.

That is the whole game. When you leave a question vague, the model fills the empty space with something generic, because generic is the safest guess when it does not know what you actually meant.

What a good prompt actually contains

A good prompt is not longer; it is clearer. Four things usually do it, and you rarely need all four: who you want the AI to be, what you want, the bit of context it cannot see, and what a good answer looks like.

Lazy: "give me dinner ideas." You get a generic list, half of which you would never make.

Clear: "You're a practical home cook. Give me three vegetarian dinners for a tired weeknight. I have pasta, spinach, and eggs, i want each under twenty minutes, and just give me the three with a one-line reason, no essay." Same question, but now it knows the situation, the limits, and the shape you want back.

The same question, minus the guesswork.

The seven ways to prompt

Friendly names first, the technical name in brackets for the curious.

Just ask it clearly (zero-shot). "Summarize this email in three bullets and tell me whether i need to reply." Your default for anything simple.
Show it an example (few-shot). "Here's a thank-you note i wrote once that felt right [paste it]. Write one like it for my neighbour." It copies your taste instead of guessing at it.
Make it think out loud (chain-of-thought). "I'm choosing between two flats. Walk through commute, cost, and daylight step by step, then tell me which one and why." Forcing the thinking first beats a snap answer.
Break the big thing into steps (decomposition). Planning a five-day trip becomes: rough day-by-day, then one day in detail, then the packing list. Small steps you can check.
Ask for the plan, then the work (reason then act). "Tell me how you'd structure a monthly budget for an irregular income, then build it as a table i can fill in."
Have it check its own answer (self-critique). "Reread that message to my landlord and flag anything passive-aggressive, then give me a warmer version." The easiest quality check there is.
Keep improving, and save what works (iterate). Tell it exactly what was off, teach it your taste, and save the asks that work so you can reuse them.

If you only remember three: ask clearly for the simple stuff, make it think out loud for anything you are deciding, and have it check itself before you send anything that matters.

The seven, one line each. This is the cheat sheet.

Your own notes are the best place to practice

You learn this on your own life, not from a course. I keep what people call a second brain, a plain folder of my own notes that the AI can read, and it is the best practice ground i have.

Try the smallest version. Drop a week of messy notes into one place, then ask: "group these into themes, tell me what i keep circling back to, and what i seem to be avoiding." Giving it your real material instead of a blank question is patterns 1 through 7 at once. If you want the full setup, i wrote up how i built mine with Obsidian.

Ask, read what came back, steer, save what works. Then again.

Where a better question stops helping

Asking well fixes one conversation. It does nothing about the fact that the AI forgets you the moment you close the chat. That is where the work moves from the question to what is around it: giving the AI a memory it can read, which is exactly what a second brain is for. That is the next part of this series.

How to get good: practise on your own life

Try, look at what came back, adjust, go again. When an answer is bad, read it instead of deleting it, because it is telling you which of the four things you left out. And when a way of asking works, hand it back to the AI: "write me a cleaner version of this prompt i can reuse." Using the AI to improve how you talk to the AI is the fastest way i know to get good.

The seven live on a one-page cheat sheet, plain language, ready to copy. Grab it free here.

I'm Malik. I build with AI every day and write about using it well, minus the hype. This is part 01 of Using AI, properly. Next: giving the AI a memory. New parts land first at codemeetai.substack.com.

Your AI agent checks its own work. That's not a loop, that's a confident intern with a cron job.

Malik Chohra — Sun, 05 Jul 2026 16:24:29 +0000

TL;DR: a loop is memory + rules + verify + schedule. Most agent setups have three of the four. The one they skip is a separate verifier, and skipping it means the agent that does the work also grades the work. That is the difference between self-correcting and self-confirming.

This piece is from Code Meet AI, my newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

I run background AI agents on a schedule. For months I was quietly proud of the setup, until I lined it up against what a real loop actually requires and found I had skipped the one part that makes it trustworthy. If you have any agent running unattended, this is the question I had to ask myself, and you should too.

The ladder, fast

Prompt engineering tuned the words. Context engineering got the right things into the window. Harness engineering is the scaffolding around the model: tools, rules, sandboxes (I mapped the harness floor here). Loop engineering is the floor above, the harness running on a timer, spawning helpers, feeding itself. Each layer wrapped the last. Nobody got replaced, the edge just climbed a floor.

A loop has four parts

Memory it reads before acting and writes after. Rules it cannot break. A verifier that confirms the output before it counts. A schedule that triggers the cycle. Memory, rules, verify, schedule.

Where I told on myself

Three indexing layers per project, a curated memory bank, a structural index of what imports what, a temporal recall layer (the full second-brain setup is here). Background agents on a schedule on top.

Count it against the four parts. Memory, yes. Rules, yes. Schedule, yes. That is three. The fourth is verify, and I did not have it.

I never built a separate checker. The loop produced work and then trusted its own work. No second model, no sub-agent whose only job is to read the output and return true or false. The agent that does the work also decides the work is fine. In any human process you would flag that conflict of interest immediately. In an automated one it is somehow the default.

That is the whole point. Memory plus rules plus schedule gives you an agent that runs a lot. It does not give you an agent you can trust to run unattended. Verification is the difference between self-correcting and self-confirming.

What verification actually means

Not the agent re-reading its own output and saying "looks good." A separate checker: a sub-agent or a second model, given the acceptance criteria of the goal, whose only output is true or false against a defined end-state. It does not see the reasoning that produced the work, it sees the work and the spec. That independence is the entire value. If you build one thing this week, build this, because it is what makes the rest safe to leave alone.

The governance angle most people miss

The loop does not know what you are using it for. Two teams build the identical loop and get opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. Same files, same cron line, same checker, opposite outcomes. The responsibility moved up a floor alongside the capability.

So, the one question: who checks the output? If the answer is "the same agent that wrote it," you do not have a loop. You have a head start.

I packaged the skeleton I am using to close my own gap, the memory bank, the rules file, a goal with a verifiable end-state, the checker sub-agent, the schedule, and guardrails so it cannot run off a cliff. It is free, name your price: the Loop Engineering Starter Kit. The deeper write-up, with the diagrams, is on Code Meet AI.

I lean on these loops daily building Wire AI, my generative onboarding SDK for React Native, where unverified agent output would land in front of real users.

I write Code Meet AI: real AI workflows, real numbers, from someone shipping with it every day.

How are you handling verification in your own agent setups? I am still wiring mine in and would take notes from anyone further along.

How I built a Claude Code skill for on-brand UI

Malik Chohra — Tue, 30 Jun 2026 09:01:21 +0000

I have shipped mobile apps for nine years, and UI is still my weakest skill. I can architect a backend-for-frontend or wire up NFC health cards without sweating it. Ask me to make an onboarding screen feel premium and I stall out. For a long time I treated that as a fixed fact about myself and shipped slightly-off-looking apps because of it.

I know app UX. I have shipped enough flows to feel where they break. The part I lack is the eye for detail: color matching, branding, fonts, spacing. That has never come naturally to me.

If your AI-generated screens look generic, the fix is not a better model and it is not hiring a designer. Claude already knows what good design looks like. It does not know what your app looks like. Give it two things before it generates anything: a design tokens file (your colors, spacing, and type as named values) and a short rules block describing how your app uses them. With those in the prompt, the output lands on-brand and ships. Without them, you get a template you have to rebuild by hand.

Tokens and rules are not a magic button. You still have to describe the app: who uses it, how it should feel, an app or two you want to borrow the direction from. The model needs that steer. What the tokens and rules do is stop it from guessing on the part you cannot put into words anyway.

Then I stopped pretending the gap would close on its own. I treat it now the way I treat every skills gap: I use AI as a multiplier. The part that took me a while to learn was not prompting. It was what to hand the model so it covers the exact thing I am bad at, instead of guessing and handing me homework. Here is that setup, with the real before and after from my own React Native boilerplate.

Why does Claude's design skill produce generic screens?

Claude Code ships with a design skill. Out of the box it writes components that look fine alone and wrong next to each other. Generic spacing. A violet-and-white card look it falls back on. Hardcoded colors that ignore the palette you already picked.

Nobody told the model your colors, your spacing, your fonts, or your rules, so it reaches for a 2021 template. The whole job is closing that gap. Same content, same app above. The right side is what happens when the model stops guessing.

What are design tokens, and why do they fix most of it?

A design token is a named value. Instead of #7C3AED scattered across forty files, you have accent.primary. Instead of random padding, a spacing scale: 4, 8, 12, 16, 24. Instead of five fonts, one type ramp. You define them once, then paste them into every prompt so the model builds with your system instead of inventing a new one each time.

I skipped this for too long because it felt like overhead. The token file is the asset that keeps the next fifty screens consistent without me thinking about it. Everything downstream reads from it, mobile or web.

What goes wrong when you run the default skill on a real app?

You install the skill, run it on your home screen, it looks decent, you ship it. Two weeks later you have nineteen one-off components that share no styles, and your design system has quietly forked into a mess. I have done this. It is how I learned the rest.

The fix is not a better tool. It is giving the model four things before it generates anything:

Your tokens, inlined into the prompt.
A real component from your app, so it matches your conventions.
The mistakes to avoid: no inline styles, no hardcoded colors, no generic look.
Where the file goes, so you are not pasting output around by hand.

Give it those four and the output ships. Skip them and you get orphan components.

What does a non-designer actually get from this?

The one design skill you do not have, applied on every screen for free. Every new screen matches the last because the model builds from the same tokens. The first screen takes setup, the fiftieth takes a sentence. And the product reads as funded instead of hacked together by someone who is good at code and shaky at design.

That last part is not vanity. Researchers at Carleton University found people form a visual judgment of an interface in roughly 50 milliseconds, and that snap judgment colors how much they trust everything after it (Lindgaard et al., 2006, Behaviour & Information Technology). A first-time user decides whether your app looks legit before they read a word. A coherent system buys that trust, even when a designer never touched the file.

How do you start this week?

You do not need to redesign everything. Do this:

Pull your colors, spacing, and fonts into one short list. That is your token set.
Pick your worst screen.
Paste the tokens plus "here is the screen, refactor it to use only these, no inline styles" into Claude.
Compare. Then do the next screen.

That is Claude Design 101. The system is the asset. The model is the labor. I have been running this exact setup for months. The onboarding in Morrow Self, my wellness app, came out of the agent already looking like the product instead of looking like AI. My two boilerplates ship with the same wiring: AI Mobile Launcher for React Native, and AI Web Launcher for Next.js. Different tokens, same workflow, whether it is a mobile app or a web app, same engineer who still cannot design a screen from scratch.

Want the exact prompts? I packaged the two I ship with, the design-system refactor prompt and the token-block template, plus the open-source skill that runs the whole flow:

chohra-med / claude_design_skill

A Claude Code skill that front-loads design tokens and rules so AI can only produce on-brand UI, then verifies the output.

claude-design-idea-to-ready

From a one-line idea to on-brand, shippable design, in the right order.

A Claude Code skill that front-loads the constraints (design tokens + a CLAUDE.md design-rules block) so the model can only produce on-brand UI, then runs generation last and verifies it against the rules.

Created by Malik Chohra · Code Meet AI newsletter

Sponsored by AI Web Launcher and AI Mobile Launcher and CasaInnov

Most AI-generated UI looks the same because it is handed zero constraints. This skill front-loads the constraints (design tokens + a CLAUDE.md design-rules block) so the model can only produce on-brand output, then runs the generation last and verifies it against the rules.

Before / after

Same screen, same prompt. The difference is the foundation the model was given before it generated.

Generic (no constraints)	On-brand (this pipeline)

It works because the brand lives in two files the model reads first:

The pipeline

Idea…

View on GitHub

If you would rather start from a boilerplate that already has the tokens, components, and design system wired in, that is AI Mobile Launcher Standard for React Native, or AI Web Launcher for the web.

I write Code Meet AI weekly on this kind of AI-first building. I broke down the tool side of this in Stitch vs Claude Design, and the wider idea, own the structure and swap the model, in the harness engineering piece.

FAQ

Do I need to be a designer to use this?

No, and the whole point is that you are not. The tokens and the rules hold the design decisions, so you make a few calls once (colors, spacing, type) and the model applies them after that. I am the proof. I still cannot design a screen on a blank canvas.

What exactly is a design token?

A named value that stands in for a raw one. accent.primary instead of a hex code, space.4 instead of a number. It gives the model and your codebase one source of truth instead of forty scattered copies that drift apart.

Why does Claude produce generic-looking UI by default?

Because it has no information about your app. It knows good design in general, not your palette or conventions, so with no context it reaches for a safe template. Feed it your tokens and a short rules block and that stops.

Does this work outside React Native?

Yes. The tokens-plus-rules approach does not care about the framework. I run the same setup on the web with AI Web Launcher, my Next.js boilerplate, and the before and after looks the same. The examples here are React Native because that is most of what I ship.

Is the design skill enough on its own?

Not on a real app. Run it blind and you get one-off components. The four inputs above are what turn it from a demo into something you can actually ship.

Open your worst screen. Pull its colors into one file. Paste it in with "use only these." That is the entire on-ramp, and it is the same one I used to stop shipping apps that looked like I built them alone.

RN UI from Stitch vs Claude Design: which one ships a committable diff

Malik Chohra — Fri, 26 Jun 2026 15:24:48 +0000

I had the same prompt open in two tabs this week.

On the left, Google Stitch. On the right, Claude Design. Same onboarding flow, same brand colors, same instruction: make these four screens look like they belong in the app, not like a Tailwind starter someone forgot to theme.

I was going to write you the clean version of this. Stitch vs Claude Design, here is the table, here is the winner, pick one and move on. I ran the test, I had the verdict, the draft was basically written.

Then Anthropic shipped a /design command inside Claude Code and quietly deleted the question I was answering.

I will get to that. But the comparison still matters, because the thing that decides the winner is the same thing that decides whether the new /design command is any good. So let me show you the test first.

Same prompt, two tools

The job was a real one. Four onboarding screens in my AI Mobile Launcher Standard app, currently a generic violet stack of cards, and I wanted them to match the rest of the product. I gave both tools the same brief and timed each from first prompt to "I would actually commit this."

Stitch is a UI generator. You describe a screen, it gives you a layout. And it is good at that. Inside a few minutes I had four mockups that looked tighter than what I would have drawn from a blank file. The hierarchy was right. The accent was used sparingly enough to read as intentional. If I needed something to drop in a deck or send to a designer, I was already done.

Then I tried to use it. The React Native export came back as four standalone files with hardcoded hex values, inline styles, and import paths that pointed at a design system I do not have. None of it knew about my tokens, my Screen wrapper, or where anything lived in my project. So I spent the longer half of the work hand-replacing color values with token references and rewiring imports. The whole Stitch run, cleanup included, came to about three and a half hours. The mockup was a gift. The code was homework.

Claude Design, pointed at the same four screens, was slower to feel impressive and faster to actually finish. No mockup to admire. It read my existing screens, copied the visual direction already in the app, and wrote the refactor back into the original files, using my tokens, my wrapper, my prop types. About 45 minutes, most of it Claude reading and writing, and a few minutes of me reviewing the diff and changing one copy string.

Here is the same screen after that run. Same question, same options, but it reads as the product now instead of a starter template.

The honest verdict, before the news broke: Stitch to explore, Claude to ship. Stitch wins when you have no design system yet and want a strong opinion on what a screen could look like. Claude Design wins when you have a real codebase and need the output to land in the right files without a cleanup pass. They are not competitors. They sit at different stages of the same workflow, and people kept treating them as substitutes.

That was the article. Clean enough.

Then they deleted the question

This week, a /design command landed inside the Claude Code terminal. You create, edit, and sync design straight from where you already write code: design system imports, code round-trips, no screenshot, no rebuild. The same overhaul moved Claude Design from a flashy demo toward something closer to a design-system compliance layer, and it fixed the token burn that made the old version expensive to run.

Read that back. The thing that made Stitch lose my test was that it could not see my codebase. The thing that made Claude Design win was that it could. And now the design step has moved inside the terminal that already has the whole codebase loaded.

The seam between design and code did not get a better bridge. It disappeared. The tool-versus-tool fight I was refereeing became a sub-plot in a bigger story: the harness is eating the stack. First it absorbed the planning step, then the review step, and this week it reached over and took the design handoff too.

One honest caveat, because I would want one from you. /design shipped basically yesterday. Nobody has months on it. I am not going to tell you it is battle-tested, because it is not, and the first person who tells you a day-old command changed their life is selling something.

So here is the part that is proven, and the part that actually matters whether you use Stitch, Claude Design, or the new /design command.

The setup that decides all three

None of these tools output on-brand code because of the model. They do it because of the boring scaffolding underneath, and that scaffolding is the same in all three cases.

Two pieces carry almost all the weight.

Design tokens as one source of truth. A single file that holds your color, type, spacing, and radius, with names instead of hex values. color.bg, color.accent, space.4. Every tool I named can read a tokens file. None of them can guess your palette. The difference between "pretty picture I have to rebuild" and "diff I can commit" is almost entirely whether the tool was pointed at this file before it generated anything.

A CLAUDE.md design-rules block. A short section that tells the agent the things your tokens cannot. Which wrapper component every screen uses. That the accent color is for one call to action per screen, never decoration. That nothing animates faster than 240ms. That danger red never shows up on a celebration. The rules a designer on your team would learn in week one and an agent will violate forever unless you write them down.

Give a tool those two things and it stops generating artifacts and starts producing changes that fit. Withhold them and even the smartest model hands you a cleanup pass. That was true for Stitch, it was true for Claude Design, and it is the exact thing that will decide whether /design is useful in your repo or just another demo.

This is the same lesson as the harness piece I wrote a couple of weeks ago. The model is the swappable half. The structure around it is the half you own, and the half that does the work.

The receipt

I am not theorizing. The onboarding in Morrow Self, my own app, runs on this setup. Same approach, different tokens, a warm rust palette instead of the dark one from the test, and the screens came out of the agent already looking like the product instead of looking like AI.

Same workflow, different tokens. That is the whole trick. When the design rules live in the repo, the tool you point at them almost stops mattering. Which, conveniently, is why I am not panicking that /design just absorbed the comparison I spent a week on.

So which one do you use

If you have no codebase yet, start with Stitch. Get a strong visual opinion on the page, commit to tokens and components, and the day you create that tokens file is the day you switch.

If you have a real codebase, the design step now lives in Claude Code. Build the two pieces above first, then let /design or the design skill work against them. Watch it for a few weeks before you trust it with anything you cannot review, because it is new, but build the scaffolding now, because the scaffolding is not new and it is what pays off.

The tool you pick matters less every month. The setup you point it at matters more.

I wrote up the exact tokens file and the CLAUDE.md design-rules block I actually ship as a one-pager you can paste into your own repo today. It goes out free to newsletter readers at Code Meet AI.

FAQ

Is Stitch better than Claude Design?

Neither, in the abstract. Stitch is better at proposing a look when you have no system. Claude Design is better at landing code when you do. Now that /design lives in the terminal, the second job moved even closer to the code.

What is the /design command?

A command inside Claude Code that lets you create, edit, and sync design work without leaving the terminal: design system imports, code round-trips, no screenshot handoff. It shipped in Anthropic's June 2026 Claude Design overhaul. New, so review its output before trusting it.

Do I need Stitch at all anymore?

Yes, if you are early and want visual ideation before you have committed to a system. Once you have tokens, the center of gravity moves to whatever runs against them in your repo.

What actually makes the output on-brand?

A tokens file plus a short CLAUDE.md design-rules block. That is the part that is proven, and it works the same across every tool here.

Building a generative-UI SDK for React Native: registry, Zod, Hermes-safe streaming

Malik Chohra — Mon, 22 Jun 2026 19:25:49 +0000

TL;DR

Generative UI lets an AI model assemble the interface at runtime instead of hard-coding every screen.
The web already ships it (Vercel AI SDK, Tambo, Google's A2UI). Mobile has almost nothing native.
React Native blocks it three ways: broken streaming, costly nested trees, no native agent renderers.
So I'm building Wire RN, an open-source generative UI SDK for iOS and Android.

Short version up front: the web already has good tools for generative UI, mobile has almost none, and I got tired of waiting. So I'm building one. The longer version is the more interesting part, and it starts with how interfaces have always changed.

Every era of the interface moved in the same direction. You just have to squint to see it.

Command lines made you learn the machine. Exact syntax, no forgiveness. The graphical UI flipped some of that: windows, a mouse, things you could see instead of memorize. Touch went further, the screen became the thing you manipulated directly. Then chat arrived and you could just type what you wanted in plain language. Each step moved a little more of the burden off the user and onto the software.

Generative UI is the next step on that same line. And it's the biggest one yet.

I'm a React Native engineer, nine years in. I've spent the last six months building with this pattern daily. I want to show you the SDK I'm building and why. A sneak peek.

A flow in my own app, built on the pattern this whole piece is about. The screen changes shape between turns because the model is choosing what to render next.

What generative UI actually is

Generative UI is when a model decides the interface at runtime, instead of a developer hard-coding every screen in advance. The model reads context (your last answer, your history, the task) and emits structured data that says "render this component, with these props." Your app maps that to a real component. The user never sees the structured data. They see a screen that happens to be different from the one their neighbor got.

The distinction that matters: this is not a chatbot. A chatbot returns text and you read it. Generative UI returns interface. Things you tap and type into. The model is behind the screen.

Google now defines it in almost exactly these terms: a front-end architecture where the interface is built by AI in real time rather than hard-coded by developers. They frame the old way as the "wall of text" problem. Models could reason and plan, then collapsed it all into a paragraph of markdown, which is what generative UI fixes. Let the natural output of a capable model be an actual interface.

Why big tech suddenly cares

Because the data backs it up. Google's own evaluations show people strongly prefer generated interactive experiences over plain text answers. And Google is openly calling this work the first step toward fully AI-generated user experiences, where interfaces get tailored to the user instead of pulled from a fixed catalog of apps.

Read that last part again. The endgame they're describing isn't "nicer chat answers." It's interfaces assembling themselves per user, per moment, personalized by user need, the fixed app catalog dissolving into something generated on demand. When the company that owns Android and Chrome writes that down as a direction, mobile teams should pay attention.

Tambo, one of the web libraries leading here, puts the same idea in plainer language: we used to adapt to software, now software adapts to us.

What web companies already ship

This is the uncomfortable part for mobile people. On the web, generative UI is past theory. It's npm-installable. The players worth knowing:

Vercel's AI SDK wires a model's tool calls straight to React components. The model calls a tool, the tool returns data, and that result connects to a component instead of a string of text.
Tambo is the clearest template for the pattern. You register your React components with Zod schemas, and the agent picks which one to render from natural language. Zod validates the props at runtime, so a malformed output gets caught before it ever reaches render. No "undefined is not a function" in production. The catch: it's React-only, and "other frameworks" includes the one your phone runs.
CopilotKit's AG-UI pushes toward a declarative middle ground, where agents emit a structured spec of cards, lists, forms, and widgets rather than free-form code, so one spec can render across React, mobile, and desktop.
Google's A2UI (a2ui.org) is the open protocol version of that idea: agents send declarative component descriptions, the client renders them with its own native widgets. The reference renderers shipped so far are Angular, Flutter, Lit, and web components. React Native is not on the list.

The registry-plus-schema pattern is the through-line in all of them, and it's the thing that makes this safe to ship. The model isn't writing UI code at runtime. It's filling out forms your components already defined. Creative freedom over the flow, zero freedom over what a component is.

The Gemini moment

Then there's the example everyone's actually seen now.

Gemini shipped generative UI into its own app as two experiments. Dynamic View uses agentic coding to design and code a fully custom interactive response per prompt. Visual Layout generates magazine-style multimodal responses with photos and interactive modules. Ask it to plan a three-day trip to Rome and you get a visual itinerary you can actually explore and adjust across multiple turns. Not a wall of text. A built thing.

Gemini generating an interface, not an answer. The image and the interactive steps get built into the chat itself. This is the version most people will meet first, and it's worth knowing exactly how it works.

Here's the part that matters for us. Even Gemini's mobile experience is the model writing HTML, CSS, and JavaScript and rendering it in an app shell. It generates web code in real time and shows it inside the app. Impressive. But it's generated web, displayed in an app. It is not native components, your design system, or your offline behavior. Which is exactly where mobile's real problem lives.

So why is mobile still behind?

Because every generative UI library that works is web-shaped, and mobile punishes web-shaped assumptions. Three walls, in the order you hit them:

Streaming doesn't work. React Native's Hermes engine doesn't implement ReadableStream on fetch. Every LLM SDK that streams tokens through response.body.getReader() breaks on a real device. OpenAI's, Anthropic's, Google's, all of them. The first thing every mobile AI developer learns is that the model provider's own quickstart doesn't run on their phone.
Recursive component trees are a tax. Web generative UI emits nested trees: a Card holding a Row holding Buttons. On mobile, that recursion multiplies validation work, hammers the JS thread mid-stream, and hands the model more places to invent a prop. Models are measurably worse at deep nested structures than flat ones. Token cost climbs, malformed output climbs with it.
No agent rails. The agent protocols (A2A, AG-UI, Google's A2UI) were spec'd web-first. A2UI ships native renderers for Angular, Flutter, Lit, and web. If you want an agent to drive native React Native screens today, you're writing the adapter yourself.

And look at what mobile actually has in 2026. The "best React Native UI libraries" lists are all static kits: Tamagui, NativeWind, gluestack, Restyle. Excellent component libraries. Not one of them is generative. The category just doesn't exist on mobile yet the way it does on web.

So mobile teams do what teams always do. They patch a polyfill, give up on streaming, hand-roll a JSON-to-component mapper, and accidentally write 1,200 lines of glue code. I know the number because I wrote that glue for a client in 2024, and it broke every time the model invented a prop name.

How far does this go?

Worth zooming out before I get to the building part. The designer Andy Budd recently sketched a ladder of "adaptive software," borrowing the metaphor from the autonomy levels we use for self-driving cars. At the bottom, humans author every screen. Near the top, a product stops shipping one best version and starts assembling a different experience per cluster of users, then eventually per individual, per session, per task. The reframe that stuck with me is his: the question stops being "what's the best version of this flow?" and becomes best for whom? At the far end, each interaction becomes a design problem of its own.

He names the catch too, and it's a real one. A product that can adapt to your needs can adapt to your weaknesses just as easily. Personalization and manipulation run on the same engine. Anything that assembles interfaces per user needs rules about what it's allowed to optimize for, and in whose interest. That isn't a mobile problem or a web problem. It's a "we can suddenly do this" problem, and it shows up whether or not anyone writes the rules first.

Here's the bridge back to my corner of it. You don't reach the top of that ladder with hard-coded screens. Per-user, per-session interfaces need a system that builds UI at runtime from validated components, and that mechanism is what generative UI actually is. The web has it. Mobile, as we've covered, mostly doesn't. Which is the gap I'm building into.

So I'm building it

I'm building the thing I kept needing: an open-source generative UI SDK for iOS and Android, built on React Native. Wire RN.

Same core pattern the web libraries proved. A fixed registry of components, strict schema validation between the model and the screen, the model choosing the flow and never inventing a component. But built for the walls above instead of around them:

Streaming that survives Hermes, so token streaming actually works on a real device.
Flat components instead of recursive trees, because mobile screens are sequential anyway, and flat is where models make fewer mistakes.
The registry stays yours, so your brand, design system, and accessibility never leave your control.

I rebuilt my own app's onboarding on it first.

Three turns of the same onboarding flow, left to right: the model rendered a text field, then a "reading your answer" beat, then a different choice-chips component. Same code, a different screen per user, no release cycle to change it.

The first version confidently rendered a date picker when it should have asked about sleep habits. So no, the robots are not running the show yet. Validation matters. And a rule of thumb on where to even use this:

Good fits: onboarding, check-ins, recommendations, anything high-variance where the right next screen depends on the last answer.
Bad fits: settings, billing, anything you want stable and predictable. Please do not make your settings screen generative.

So that's the why. The interface has always drifted toward adapting to the user instead of the other way around. The web got the generative version first. Mobile is late, but it's the surface where most people actually live, and being late means whoever picks it up now gets a personalization lever their competitors can only iterate on through App Store review cycles. I'd rather build the tool than keep writing the glue.

I'm shipping Wire RN open-source this month.

FAQ

Is generative UI the same as a chatbot?

No. A chatbot returns text that you read. Generative UI returns interface: real native components you tap, type into, and swipe. The model decides which component renders next from your context, and your code decides what components are allowed to exist. The conversation happens through the UI, not in a chat bubble.

Does the AI write code at runtime?

No, and this is the part most people get wrong. The model emits structured data that maps to pre-built, schema-validated components from a registry you control. It never writes React Native at runtime. If it emits something malformed, your validation layer rejects it before render and the user sees a fallback, not a crash.

Why can't I just use Tambo or the Vercel AI SDK in React Native?

They're built on web assumptions. They expect browser streaming APIs that React Native's Hermes engine doesn't implement, and they emit recursive component trees that perform badly on mobile and give the model more room to hallucinate props. They're excellent on the web. Mobile needs a runtime shaped for mobile.

Is generative UI safe for production apps?

Yes, if it's validated. The registry-plus-schema pattern means the model can only ever pick from components you shipped, with props checked against a schema before anything renders. The risk profile is closer to "remote config with opinions" than to "AI writes my app." The model owns the flow, never the component definitions.

Where does generative UI make sense first?

Onboarding, check-ins, recommendation flows, coaching: anywhere the ideal next screen depends on what the user just did. These are high-variance and conversational, so personalization pays off. Static utility screens like settings and billing should stay hard-coded. Please do not make your settings screen generative.

I write Code Meet AI, a weekly newsletter on AI-native mobile engineering. Wire RN goes open-source this month — the build, the bugs, and the repo are the next issue.

Harness Engineering 101: Prompt Engineering wasn't enough. Neither was context. The harness was.

Malik Chohra — Thu, 18 Jun 2026 09:17:46 +0000

TL;DR

Prompt engineering and context engineering both still left me as the bottleneck. I re-explained myself every single session.
The fix was structural, not verbal. A harness: standing context, memory files, real account access, delegation, and skills, so the model starts every morning already knowing my work.
The term got named in 2026 (Agent = Model + Harness). Two camps now argue about it and miss that they agree: the edge moved out of the model and into the structure around it.
A harness is not free. It rots. Maintaining it is the actual job. And the version nobody is building yet is a harness inside the product you ship, not just around your desk.

A harness is everything you build around a model so it can do real work in your world: your files, your accounts, your standards, your history. The model is the swappable part. The harness is the part that makes the model useful, and it is also the part nobody screenshots.

Prompt engineering, then context engineering, then the wall

About a year and a half ago, my whole relationship with these models was prompt engineering. I collected phrasings that worked. "Act as a senior React Native engineer." "Think step by step." "Return only the diff." I had a notes file of magic openers. When an output was bad, my first instinct was that I had said it wrong.

If you remember the wave of new AI influencers back then ("steal these prompts," "the prompt that killed marketing," and so on), the whole premise was that a better prompt was the fix.

That works until it doesn't. The problem with prompt engineering is that the model still knows nothing about you. A perfect prompt produces a good answer to a generic question. I was not asking generic questions. I was asking about my codebase, my locked decisions, my half-built product. The prompt was clean and the answer was still confidently wrong, because the model had no idea what Morrow Self was or that the accent color was already decided.

So I moved to context engineering, which is the obvious next step. Stop tuning the words, start assembling the right context window. Paste the relevant file. Paste the conventions. (I wrote a piece a while back on context engineering. [→ link to add])

Paste yesterday's decision. The answers got dramatically better. Then I hit the wall, and the wall was me.

I was the context. Every morning I sat there hand-assembling the same window: who I am, what I am building, what is locked, what shipped yesterday. I was a human glue layer copying my own life into a text box, and the moment the session ended, all of it evaporated. Context engineering made the model smarter per session and did nothing about the fact that every session started cold.

That cold start is the actual problem. Not the wording. Not even the context itself. The fact that none of it persisted, so I rebuilt it by hand every day.

What I built instead: a second brain that starts warm

One of the first AI use cases that pulled me in was the second brain approach. I started early, and I will say one thing: it is amazing. I would recommend a second brain to anyone. No AI use case is better, for me personally. I have a whole guide to help you get started: the second brain starter guide.

I did not solve the cold-start problem on purpose. I solved it one annoyance at a time, and only later found out the pile of fixes had a shape.

It started with a single file. A root CLAUDE.md that tells the model who I am: nine years in React Native, how I write, what I am launching, which decisions are locked and not up for debate. Then a CLAUDE.md per project, so inside the Wire RN repo it knows that codebase's rules, and inside my vault it knows the content rules. The model stopped starting cold. It started as someone who had worked with me for months.

Then memory. Nearly a hundred markdown files now (97 the morning I counted), one fact each, with an index file the model reads at the top of every session. For example:

"Morrow Self is the locked app name."
"The accent is teal, not violet, retired on June 11."
"My ICP is B2C mobile app founders."

The index is now big enough that it trips its own size limit, which tells you something honest about how this accretes. I do not re-explain my own business every morning anymore. It remembers, and when it is wrong, I fix one file instead of repeating myself for the hundredth time.

Then access. MCP connectors into Gmail, Calendar, Drive. The model reads my actual schedule and my actual inbox, not a sentence describing them. Context engineering was me narrating my calendar. This is the model just having the calendar.

Then delegation, which is where my one real rule lives. When I need ten files grepped or a codebase mapped, that runs in a separate context and hands back the conclusion. This is the same principle I run on every build: the newest, most capable model plans, a cheaper and simpler one executes. The expensive brain decides what to do. The cheap one does the grunt work in its own window and never pollutes mine.

On top of all of it sit the skills. Sixty-some of them: write a LinkedIn post in my voice, draft a newsletter, run the daily plan, plus scheduled jobs that fire without me sitting there.

None of that was clever. Every piece exists because I got tired of repeating myself. That is the whole thing, and it is much more boring than the posts about it sound.

So this has a name now: harness engineering

Three months ago, someone replied to one of my posts to explain harness engineering to me. Kindly. Like I had never heard of it. He linked a newsletter, told me an agent is only as good as the scaffolding around it, and signed off with "wild stuff, right?"

It was wild. I had been doing it since December. I just did not have the word.

Here is the word. Mitchell Hashimoto coined "harness engineering" in early 2026: Agent = Model + Harness. The model is the brain. The harness is everything around it that lets the brain act in your world. People break the harness into roughly five parts:

personalisation
context
action
memory
delegation, with skills and scheduled jobs as multipliers on top.

I mapped my own setup against that list expecting gaps and found I had quietly built all five.

The number everyone repeats comes from a teardown of Claude Code, where the claim is that something like 98% of the system is harness and under 2% is the model. I will be honest: I have not verified what that figure actually counts, and most people reposting it have not either, so hold the exact number loosely. Directionally it matches what I see every day. The model is the small, swappable part. The scaffolding is where the work lives. (Martin Fowler's notes and HumanLayer's practitioner write-up are the two least hyped explainers I have read if you want the real version.)

Why it blew up, and the fight that misses the point

While Hashimoto was naming the harness, another builder, Jake Van Clief, went the opposite direction and grew a community of tens of thousands in about six weeks, telling everyone to stop using agentic frameworks entirely. His pitch: delete LangChain, delete the orchestration libraries, replace all of it with numbered folders and markdown files. A folder and a model, he argues, beats a custom agent.

Big shoutout to Jake. I love the guy, I follow him, and the advice and content are genuinely good. Highly recommend you follow him too: youtube.com/@JEVanClief.

So one camp says build more scaffolding and the other says tear the framework out and use the filesystem. They sound like enemies. They are saying the same thing.

Both are telling you the model is not the point. The architecture around the model is the point. Whether your architecture is a LangChain graph or a folder named 02-draft, the bet is identical: the edge moved out of the model and into the structure you wrap around it.

That is the thing I had been saying for six months before I had either of their vocabularies. I wrote a piece called "I spent 6 months on architecture, then redesigned everything in 2 hours". The redesign was fast because the harness was already there. The harness debate is the same argument in a newer hoodie. It blew up because two people gave a clean name to something a lot of us had already half-built and could suddenly point at.

The harness rots. Maintaining it is the job.

Here is the part the harness posts leave out. A harness is not a one-time build. It is maintenance, and the maintenance is the actual job.

Memory files rot. Mine contradict each other if I do not prune them. A good chunk of my files were one launch date out of sync within a month of being written. A stale memory is worse than no memory, because the model trusts it and so do you. People who run bigger memory systems than mine clear them out on a schedule, quarterly, and I now understand exactly why.

Skills rot the same way. I have sixty installed. In a normal week maybe twelve fire. The other forty-eight are clutter I keep meaning to audit. A harness left untended does not stay neutral. It quietly fills with confident lies about your own life.

So when someone tells you the harness is the new moat, the honest version is that the harness is the new gym membership. Owning it does nothing. Showing up to maintain it is the entire return.

How to start one without a course

If you are starting from zero, you do not need a framework, a course, or a community of thirty thousand people. You need three things:

One CLAUDE.md (or its equivalent) that tells the model who you are and what is locked.
A handful of memory files, one fact each, that the model reads at the start of a session.
The discipline to add a new file every time you catch yourself explaining the same thing twice.

That is a harness. Everything past that is refinement, not foundation.

If you already have one, do not build more. Audit. Open your own memory files and count how many are still true. Count how many of your skills actually fired this week. The number will be humbling, and the prune will make the whole thing run better than any new addition would.

Where this goes next: a harness inside the app, not around the dev

Here is the gap I keep staring at. Everyone writing about this is pointing it at their own desk. Coding agents. Research assistants. Second brains like mine. Dev tools and knowledge work.

Nobody is building a harness for shipping a consumer mobile app.

That is the unclaimed corner, and it is the one I am standing in. The same idea, a model wrapped in structure it can trust, is what lets a mobile app render a different onboarding flow per user instead of the same six hard-coded questions for everyone.

The harness for a product is not a CLAUDE.md. It is a validated component registry, a streaming runtime that survives on a real phone, and an agent that drives screens instead of chat. That is what I have spent six months building into Wire RN, and it is the same lesson as the second brain, pointed at a different surface.

That is also what I am shipping this week. Wire RN hits Product Hunt in a few days, and the next issue takes this exact harness idea and points it at an actual app, with the runtime and the component registry on screen instead of in theory.

The people naming the harness are right. They are just looking at their own desk. The more interesting move is what happens when you put the harness inside the thing you ship.

Now there is a shift toward Loop engineering. I already started playing with it, but as always, I want to test things first before I write a generic, AI-generated article about a new concept.

I write a weekly issue on building AI-native software, mostly on mobile, mostly with receipts like these. If the cold-start problem in this piece sounds familiar, the next one shows the harness running inside a real app. codemeetai.substack.com.

Fable 5 Crashed My Subagents. The Fix Was the Cheaper Setup.

Malik Chohra — Mon, 15 Jun 2026 12:02:00 +0000

TL;DR for builders

I ran Claude Fable 5 over a free-window weekend to rebrand six live sites on one design system. The lesson is a routing one:

Fable 5 (about 2x Opus 4.8 per token) earns its price on judgment: the design system, the token structure, the calls the rest of the build inherits.
Route the routine propagation to a cheaper model. I pinned subagents to Opus 4.8.
Running Fable as the session model crashed my parallel subagent fan-outs. Pinning the subagents fixed the crash and happened to be the cheaper setup.
None of it works on a codebase an agent can't read. The indexed repo did more for output quality than the model choice.

Full story below.

Fable 5 dropped on a Monday or a Tuesday, I forget which. What I didn't forget: my weekly session resets Wednesday at 10am European time, and I'd just come back from holiday sitting on most of my limit with two days to burn it. After all the noise before the Mythos release, I wanted this model on a real job, not a demo.

So Tuesday night I set two alarms. 2am, then 7am. The plan was stupid and simple. Wake up, run Fable until the session cap cut me off, sleep, wake up, finish. The cap came fast. Thirty minutes of real work, then a four-hour wait. I'd landed home with a backlog anyway, so the waits filled themselves: catch up in the morning, nap at night, run Fable in the windows between.

Anthropic had Fable 5 on a free window for a couple of weeks, so I wasn't paying the 2x in euros. I was paying it in session caps. Same lesson, different currency.

Most people one-shot a landing page with a model like this, watch it burn faster than Opus, and decide it's a tax. I did the opposite. I pointed it at a job I'd been avoiding: fix my branding across every site I own. I'd finally admitted the obvious. My palette was mostly violet, which is what every vibe-coded site on the internet looks like right now.

I asked Claude Design for four color directions and picked between them. I pulled references from Aceternity UI, Magic UI, and Refero. The full "how I build a site I actually like" workflow is its own piece, coming soon. If there's an AI topic you want me to break down, reply to the email and tell me.

The one I shipped is the teal. Here is the before and after as a system, not a vibe.

It started with one site to replace the Linktree in my bio. Then I remembered I already had four more sites built. So I stopped and changed the goal. Instead of hand-fixing each one, build a system that launches a site with AI, scales, ships with its own rules and skills, and that I can reuse. That was the weekend.

The honest catch: my old structure wasn't built for a model that bills like Fable 5. Before I could finish, I had to learn how to spend it.

What is Claude Fable 5, and is the 2x worth it?

Fable 5 is Anthropic's most capable public model right now. It sits above Opus 4.8 and costs about twice as much per token. That 2x is the whole conversation with this model, and most people get it backwards.

It's not a tax. It's a routing decision.

The newest, most capable model plans. A cheaper, simpler one executes. That is the rule I run on every build.

On any real build there are two kinds of work. There's the work where one wrong call costs you an hour of cleanup later: the design system, the token structure, deciding what "one accent line, never a fill" actually means in CSS across five sites. And there's the routine work: applying that decision to the hundredth component. Fable 5 earns its 2x on the first kind. The second kind, a cheaper model handles fine and you never notice the difference.

So the question isn't "is Fable 5 worth 2x." It's "what am I asking it to do." Pay the premium where judgment lives. Route everything else down. I treated the model like a senior engineer I was renting by the token. I didn't have it rename variables. I had it make the calls the rest of the weekend would inherit.

The memes about the bill are funny because they're half right. It is expensive if you point it at the wrong work.

What did I build with it?

Six live sites, rebranded onto one editorial system, in a weekend. AI Web Launcher, AI Mobile Launcher, Wire RN's site, my personal site, my agency site, and one consumer app I left on its own palette on purpose. They all run on one shared boilerplate, so a rebrand is "change the design system once, let it propagate."

Fable 5's job was the thinking, not the typing. It set the token structure, made the calls about what stayed consistent across sites and what was allowed to differ, and held the line on the rule that made the whole thing portable. The propagation, the hundred small edits behind each decision, I routed to a cheaper model. That split is the only reason a six-site rebrand fit into two days instead of two weeks.

The output wasn't rough. Here are three of the six on Lighthouse, desktop, the morning after.

I also filmed the whole weekend, from the first color pick to the last deploy. The long version is going up on YouTube: [https://youtu.be/51SS-kl-llo?si=JP5ClRDp47n3DtCn]. If you want the build narrated end to end, that's where it'll be.

The thing the weekend produced: AI Web Launcher

The system I built to do all this is now a product. AI Web Launcher is a production-ready Next.js 15 boilerplate plus the workflow that takes a site from idea to deployed:

Idea, brief, spec
Copy and design
Memory and architecture
Build and deploy

The part that matters isn't the starter screens. It's that the codebase ships documented and indexed, so an AI agent understands what already exists and edits that instead of guessing. That one property is the difference between "Fable made a clean call" and "Fable invented three files I didn't ask for." You get the full chain and the guardrails, not a blank repo and good luck.

It's 99 euro. The first 10 people who apply get 50% off. I approve those by hand and send the discounted link, because I want feedback from the first ten more than I want the money. Apply at aiweblauncher.com.

Where did it bite me?

Day one, I ran Fable 5 as the session model and it crashed my subagent fan-outs. I parallelize work across subagents constantly, and Fable as the orchestrator kept falling over on the parallel runs. The exact moment I wanted momentum, I got a stall.

The fix was to stop using one model for everything. I pinned the subagents to Opus 4.8 for the routine fan-out and kept Fable for the decisions that mattered. The crash forced the exact setup the bill wanted anyway: expensive model for judgment, cheaper model for volume. I'd have gotten there from the cost side eventually. The bug just got me there by lunch.

That's the honest version. This was not a frictionless "AI did my work" weekend. It was a model that's worth its price if you route it right and a waste if you don't, plus one setup bug I had to eat before it ran clean.

My Fable 5 session setup

The thing that made it work isn't a prompt. It's a routing config:

Which model runs the session
Which model the subagents are pinned to
The rules that tell the agent to stop and ask before it spends Fable tokens on grunt work

This is also where the architecture earns its keep. Fable only made good calls because the codebase shipped with a map it could read, so "move everything to the new accent token" meant something specific instead of a guess. That map is part of a system I run called UAMOS, and I'm breaking the full thing down on the newsletter soon.

I packaged the setup so you don't have to find the subagent crash yourself: the session config, the model-routing rules, the subagent pinning, and the short ruleset I ran. Reply to the newsletter with FABLE and I'll send it back.

Where this breaks

Fable 5 is not a default. Two ways it stops paying off:

Your work is mostly routine. CRUD screens, copy tweaks, predictable refactors. You'll pay 2x for output a cheaper model would have nailed, and you'll feel like the people who call it a tax. They're not wrong for their workload. They're wrong to generalize from it.
Your codebase is one an agent can't read. I got good judgment out of Fable because the repo was indexed for it. Point any model, cheap or expensive, at an unmapped codebase and it guesses at the structure and breaks things a new way each session. The model is the smaller half of the result. The map is the bigger half.

And the free window is closing. After that, the routing discipline isn't optional. It's the only way the bill stays sane.

FAQ

Is Claude Fable 5 worth the cost?

For judgment-heavy work, yes. It costs about 2x Opus 4.8 per token, and it earns that on calls where one wrong decision costs you an hour later: architecture, design systems, token structure. For routine, high-volume work, route to a cheaper model. The skill is knowing which is which.

Fable 5 vs Opus 4.8, which should I use?

Both, on the same job. I ran Fable 5 for the decisions and pinned subagents to Opus 4.8 for the routine propagation. Using one model for everything is how you either overpay or underperform.

Why did Fable 5 crash my subagents?

In my case, running Fable as the session model fell over on parallel subagent fan-outs. Pinning the subagents to Opus 4.8 and keeping Fable for the orchestrating decisions fixed it. It also happens to be the cheaper, correct setup.

Can a better model fix a messy codebase?

No. A capable model on an unindexed codebase still guesses at the structure. The reliable speedup comes from indexing the repo so the agent edits what exists. Model quality is secondary to that.

If you want my actual Fable 5 session setup, the routing config, subagent pinning, and the rules I ran, reply to the Code Meet AI newsletter with FABLE and I'll send it. One issue a week on AI-first mobile and web development: codemeetai.substack.com.

The boilerplate this ran on, AI Web Launcher, is for sale now. It's 99 euro, and the first 10 people who apply get 50% off. Apply at aiweblauncher.com. I approve the first 10 by hand and send the discounted link.

I'm Malik. I've built mobile products in health, wellness, and coaching for 9 years, and I'm building the AI-native infrastructure the next wave of those products will run on: Wire RN, open-source generative UI for React Native, and the launcher boilerplates. I write weekly at Code Meet AI.

WWDC 2026: App Intents, Foundation Models, and what RN devs should ship

Malik Chohra — Tue, 09 Jun 2026 14:51:27 +0000

Apple made AI visibility mandatory and AI integration provider-agnostic. What changed, why it rhymes with App Tracking Transparency, and what to ship before iOS 27 lands in September.

TL;DR

App Intents is now the only way Siri reaches your app. No App Intents means your app is invisible to the new Siri.
Foundation Models added a model abstraction layer. Swap Apple's on-device model, Gemini, or Claude with one line of code.
The framework now ships a Python SDK, runs on Linux, and accepts image input from third-party apps.
The EU and China get the developer APIs but not the consumer Siri AI features at launch.

At WWDC 2026, Apple turned two things into platform defaults for mobile builders. First, AI visibility: App Intents is now the only way Siri can reach into your app, and SiriKit is on a deprecation clock. Skip it, and your app disappears from the assistant on iOS 27. Second, AI integration: the Foundation Models framework added a model abstraction layer, a Python SDK, Linux support, and image input, so adding on-device or multi-provider AI is a small, portable change now instead of a bet on Apple's roadmap.

The habit that made this keynote boring (in a good way)

Years ago I kept a browser tab pinned to the Apple developer release notes. When Apple shipped App Tracking Transparency and made the data-sharing prompt mandatory, it broke analytics and attribution across half the apps I knew. You could not measure anything without explicit user consent, and teams scrambled for months to catch up. I had the consent flow wired into my React Native apps the week it went mandatory, because I had been watching it coming for a long time before that.

That habit, watching what Apple makes mandatory and shipping it early, is most of the game on this platform. It is also why yesterday's keynote did not surprise me. The mandatory shift this year is not a tracking prompt. It is whether AI can see your app, and whether your app can use AI without betting the whole architecture on one vendor.

Here is what mattered, filtered for people building mobile products. The React Native specifics are at the bottom.

Why your app is invisible to Siri without App Intents

I had the question before yesterday: how do you make your app visible to the AI tools running inside the phone? I half expected the answer to be an MCP server exposing your backend data, or something equally involved. App Intents was the answer I expected, just not as direct as Apple made it this time.

Siri AI runs on App Intents. SiriKit is deprecated as of WWDC 2026 with compile-time warnings, and App Intents is the only supported way Siri can call into a third-party app. If your app does not expose its core actions as intents, the new Siri cannot see or trigger any of them.

This is the App Tracking Transparency moment repeating. Back then the mandatory thing was a consent prompt. This time, it is a machine-readable description of what your app does. The assistant became the front door on iOS 27, and App Intents is the only key that fits the lock.

App Intents 2.0 added richer entity types, streaming responses for long-running actions, and multi-turn conversational follow-ups. If you ship a consumer app and your users touch Siri, this is the single highest-priority addition to your project before September. I am treating it the way I treated the tracking consent flow in 2021: not optional, and better done early.

This is the work I am doing right now in Morrow Self, the habit app inside my AI Mobile Launcher. Morrow Self sits at the center of someone's daily routine, so making it reachable through Siri is exactly the kind of integration that earns its place: add a habit, check today's progress, log a streak, all by voice, without opening the app. I am wiring its core actions up as App Intents ahead of iOS 27 so the assistant can drive it directly.

Why App Intents need generative UI, and why that part is not solved yet

App Intents answer one half of the question: the assistant can now call your app's actions. They do not answer the other half, which is what the user sees when it does. An intent can hand back a small SwiftUI snippet, but the moment the response is richer than a confirmation, a chart, a multi-step form, a list the user can act on, you are back to hand-building a fixed screen for every possible response.

That is the generative UI gap. On the web the pattern is settled: the model picks from a set of registered components and fills them in, so the interface adapts to the request instead of being hard-coded for it. On mobile, that pattern barely exists in any packaged form. App Intents gives you a typed surface of actions the assistant can choose between. Generative UI would give you a typed surface of components it can compose into a response. Apple shipped the first half this year. The second half is still an open problem, and nobody has a clean answer for it yet.

I care about this because it is the real product question hiding behind "make your app usable by AI." Being callable is table stakes. Being able to answer with the right interface, generated for that moment instead of pre-built for it, is where the experience is won. It is also why I am building Wire RN: a way to register React Native components an assistant can pick between, the same way App Intents lets it pick between actions. The intent layer is standardized now. The UI layer is the part still up for grabs.

Apple just made AI providers swappable in one line

Foundation Models in iOS 27 introduced a LanguageModel protocol (docs here). Apple's on-device model, Google Gemini, and Anthropic Claude all implement it. You write your session logic once, and switching providers is a one-line change.

Until yesterday, building on Foundation Models meant committing your AI architecture to Apple's model and Apple's release schedule. Most teams I talk to refused that bet and built on the OpenAI API instead, eating the cost and the privacy trade-offs. The abstraction layer removes the reason to refuse.

The practical shape is hybrid routing. Short, private, or simple calls go to the on-device model, which is free and works offline. Complex reasoning routes to Claude or Gemini through the same API. You pay only for the calls that need frontier quality. Production teams have built this by hand for two years, and Apple just made it a one-day job.

Foundation Models now runs on Linux and speaks Python

Apple shipped a Python SDK for Foundation Models and made the framework run on Linux. An Apple Intelligence-adjacent runtime is now callable from a Python script on a Linux server.

That sentence would have been absurd a year ago. It means you can prototype mobile AI features without an iOS device, run the same evaluation suite on CI and on-device, and target Apple's model from a Python agent framework next to Claude and Gemini. The cost of building for the Apple stack just fell to roughly what it costs to build for the OpenAI API.

The on-device model also accepts image input from third-party apps now. Any app doing photo analysis, OCR, or scene understanding can drop its bundled 1 to 2 GB vision model and call the system API instead. Cal AI, the photo-to-calorie app that hit 40 million dollars in revenue before MyFitnessPal acquired it, is built on exactly this kind of vision call. After yesterday, that capability is free and on-device for everyone.

What the Apple and Google deal admits

Apple Foundation Models on Cloud is the frontier-quality tier, and it runs on Google's infrastructure. AFM Cloud Pro runs on Nvidia Blackwell B200 chips inside Google Cloud, under a partnership that reportedly costs Apple around 1 billion dollars a year for a custom Gemini model. Apple's contract bars Google from training future models on Siri queries.

Apple framed this as a privacy decision. The simpler read is that Apple cannot build frontier LLMs alone yet, so it rented Google's. For builders, the upside is that the cloud tier gives you Gemini-comparable quality through Apple's API surface, wrapped in Apple's privacy contract. If you need frontier reasoning in a regulated context, that is a real option now.

The EU and China caveat, which is personal for me

Siri AI consumer features are not launching in the EU or China at WWDC 2026, citing regulatory constraints. If you ship consumer apps in those markets, your users do not get the new Siri at launch.

The nuance that matters: the Foundation Models developer API works everywhere. Your apps can call the on-device model, the cloud model, and the multi-provider abstraction in every region. The gap is on the consumer side, not the developer side. I am in Berlin, so the people around me will not see Siri AI on day one. The apps I build can still use the full framework today, which is the part worth acting on.

What to do before iOS 27 ships

Audit your iOS app for App Intents coverage. If you have none, your app is invisible to the new Siri. Plan the migration off SiriKit now, not in August.
Wire the on-device Foundation Models into one real feature, behind an adapter, so you can swap providers later without a rewrite. Start with structured extraction or classification, not chat.
If you ship native iOS, connect Claude Code or OpenAI Codex to your Xcode MCP server. Xcode 26.3 already exposes build, test, and diagnostics over MCP. This is the workflow change with the highest payoff from the keynote.
If you build an AI product, apply for the Extensions developer beta. Apple opened Siri Extensions so users can pick Claude, ChatGPT, or Gemini as their assistant provider. That is a distribution channel on 2 billion devices, and the public launch is about three months out.

For React Native developers

Most of this translates to React Native, with one caveat and one opportunity.

The caveat: Foundation Models is a Swift framework, so calling it from RN needs a bridge. The cleanest path today is @react-native-ai/apple from Callstack, which already wraps the framework in a Vercel AI SDK-compatible interface. It was built against the iOS 26 version, so the iOS 27 additions (model abstraction, multimodal, fine-tuning) will need bridge updates before you can use them from RN. Watch the repo.

The opportunity: the multi-provider story Apple shipped on native is the same one @react-native-ai was already building toward. Register providers, swap with one line, same API. The two are now describing the same architecture from opposite ends, so the RN side should catch up fast.

For App Intents, you expose them through Swift in the native side of the project, and there are community packages that reduce the boilerplate. For MCP, you do not need anything RN-specific: the Xcode integration works at the Xcode level, so point your agent at the workspace and it works. And Wire RN, the open-source generative UI SDK I am building at getwireai.com, will track the Foundation Models multi-provider API as it stabilizes.

FAQ

Do I have to rewrite my app to support App Intents?

No. App Intents are added alongside your existing UI, not instead of it. You declare your app's core actions as intents in Swift, and Siri, Spotlight, Shortcuts, and the Action button can all call them. Your existing screens keep working exactly as they do now.

Is the on-device model good enough to replace cloud API calls?

For some tasks, yes. The on-device model handles classification, structured extraction, summarization, and simple tool calling well, all for free and offline. For complex reasoning, long context, or frontier-quality generation, you still route to the cloud. The point of the new abstraction layer is that you can do both through one API.

Can React Native apps use Apple Foundation Models?

Yes, through a bridge. The @react-native-ai/apple package from Callstack wraps the framework in a Vercel AI SDK-compatible interface. It currently targets the iOS 26 version of Foundation Models, so the new iOS 27 features will need bridge updates before they are available from React Native.

Does Siri AI work in the EU?

The consumer Siri AI features are not available in the EU or China at launch, due to regulatory constraints. The Foundation Models developer API, however, works in every region. Your app can use on-device and cloud models in the EU even though end users will not get the new consumer Siri yet.

Is App Intents only useful for Siri?

No. App Intents power Siri, Spotlight search, the Shortcuts app, widgets, and the Action button. Adopting them makes your app reachable across all of those surfaces, not just the assistant. That breadth is why it is worth doing even before iOS 27 ships.

What I'm shipping this week

I am going back through my own apps with the same checklist I just gave you, starting with App Intents coverage in Morrow Self, because I would rather migrate off SiriKit now than during the iOS 27 beta crunch. On the Wire RN side, the model abstraction announcement lines up almost exactly with the provider-swap design I was already building, so I am revisiting that interface to match the LanguageModel shape Apple just standardized.

If you want help shipping any of this on a React Native or native iOS stack, including App Intents migration or a multi-provider AI setup, that is what CasaInnov does.

I write Code Meet AI on AI-first mobile development. Next issue goes deeper on the Future of Mobile, the foundations worth building on once on-device AI and generative UI become table stakes.