DEV Community: Malik Chohra

Wire AI Is Live: Beta tester open

Malik Chohra — Thu, 30 Jul 2026 16:19:58 +0000

TL;DR: Wire AI is live and early access is open. It's an AI-native growth engineer for mobile apps: your React Native app embeds an SDK, a LangGraph backend decides what to ask each user next, and deterministic code owns the routing while the model only generates content. On one live app, activation went from 69% to 93%. 15 early-access seats, 3 taken, free and installed by hand.

This article is part of my Code Meet AI newsletter: https://codemeetai.substack.com

Wire AI is live today, and early access is open.

It's the AI-native growth engineer for mobile apps: AI that replaces your growth team. It runs four versions of every step of your users' journey, live at once, and keeps what makes them stay.

On the first app it ran on, activation went from 69% to 93%.

15 seats. 3 are already gone. Free, installed by me personally, and there's no price attached because I haven't set one yet.

Below: what it does, what already shipped, what's still rough, and how to claim one of the 12 that are left.

How it works

Your users' journey has stages. They onboard, they get a plan, they hit their first real win, they get asked for a review. Wire AI runs four versions of each of those stages, live, at the same time. Users are assigned to a version and stay in it, the funnel says which version keeps more of them, and the winner gets promoted.

Then the part a testing tool doesn't do. Every finished journey feeds back in: Wire reads what happened and writes a sharper variant for the next round.

It isn't a dashboard that tells you to go run a test. It's the loop, already running.

What that looks like in your codebase

Your React Native app embeds a small SDK. When a user opens the app, the SDK talks to a backend I run, and that backend decides, one screen at a time, what to ask that specific person next. It renders as native cards. Not a webview, not a chat window bolted onto your product.

At the end it hands your app a structured plan you can save and act on, and every step streams into a funnel you can read.

So instead of writing an onboarding once and guessing for the next two years, you write a config and the AI runs it.

The part that makes it work is boring on purpose. Deterministic code controls the flow and the model only generates content. Routing is a pure function of where the session is, how many questions are left, whether the user is bailing, so the whole flow is testable without a model in the loop.

The AI writes the next question, grounded in every answer the person already gave, and writes the final plan. Everything it emits gets validated against a fixed vocabulary of components before it's allowed anywhere near a screen.

That's the difference between a generative UI demo and something you can put in front of paying users. Most AI UI demos let the model draw whatever it wants and hope. This one gives the model a small, checked job and keeps the state machine in code where it belongs.

What that gets you

A journey that adapts per user. The static onboarding asks everybody the same seven questions in the same order. Wire AI asks what follows from what the person just said, stops when it has enough, and skips what it can already infer.
Experiments that run without you. A/B/C/D variants across the journey, five stages, four arms, twenty combinations, without anybody sitting in a meeting deciding which to try next. This is the direction the product is built toward and I'll be straight about where it sits today, further down.
A funnel you can actually read. Completion, drop by step, time per screen, and the transcript of any individual session so you can read exactly what the AI asked and what the person answered. Most apps at this stage are guessing about where users give up.
You find out who your users actually are. Wire AI reads every session and hands you the patterns: what people came for, which question makes them hesitate, which wording converts. Most founders are still running on a persona doc written before launch.

Our pilot client, and what actually happened

I can't name the app, that's a client boundary I hold. What I can tell you is what it does: it helps people find spots to hang out. Live React Native app, real users, and an onboarding people were quietly dropping out of.

Here's the run, in the order it happened.

We started with an experiment, not a redesign. Three versions of the onboarding running live at the same time, users assigned stickily so nobody got a different flow on their second open, every version chasing the same goal event. Nobody sat in a room deciding which one was better.
The first read was wrong, and the loop is what caught it. One arm came back looking like a 17 point winner. At around fifty sessions that feels like a result, and it's exactly the moment a human growth team ships it and builds the next quarter on top. At scale it was worth about three and a half points. Mostly noise wearing a nice hat.
The version that actually won was the short one. The deep, thorough discovery flow lost to a fast one of about eight screens. On a flow with no real leak in it, where every individual question converts in the high nineties, length turned out to be the only lever that moved anything.
Then the part I didn't expect: we found out who the users actually were. The product context we had written assumed one kind of person, someone new to the city looking for places. The answers said something else. Younger, local, born there, social, budget conscious. My actual reaction, reading the answers: wait, these people already live here. We had spent months onboarding a user who didn't exist.
So we rewrote the messaging to the real one. New product context, questions rewritten for the person who actually shows up, one question cut completely because it was seasonal noise nobody cared about, and a guard added so the AI stops asking the same thing twice in different words.
Three learning loops in, activation had gone from 69% to 93%, and the first movement showed up inside the first week of running live.

Two honest caveats on that number, because it's the one people will quote. It's activation on one app, in one category, over one window, so it isn't a portfolio of case studies and I won't dress it up as one.

And the winning arm's completion rate moved by about thirteen points between generations of the experiment, which is a reminder that you read these numbers per run, never all-time. That lesson cost me a re-read of my own dashboard.

What already shipped

Not a landing page and a waitlist. These pieces exist and run.

The SDK is open source. wireai-rn on npm, MIT licensed, eleven built in components with validated schemas, six adapters for different model providers. Swapping providers is one environment variable, so you're not married to whoever is winning this quarter.
The transport is an open standard. The device and the backend speak Google's A2A over JSON-RPC 2.0, the same contract implemented on both ends. That's how a Python agent graph ends up driving a native React Native screen. One call, one turn, one card.
The backend is a real service. Python, FastAPI, LangGraph. Multi tenant, per app keys with scoped access, session state living outside the process so it scales sideways, data in eu-central-1 because GDPR isn't a Q3 problem.
There's a console. Register an app, edit the config without cutting a release, read the funnel, open any session and read the transcript.
It's tested like something people depend on. The drop in kit runs 630 tests on every merge, and the agent routing has its own eval suite with an accuracy gate, so "the agent got worse" shows up as a failing build instead of a feeling.

First card lands in about 130 milliseconds, against roughly three and a half seconds when I started. Onboarding is the one screen where a spinner costs you the user permanently.

What a seat gets you

If Wire AI doesn't lift your activation, you've paid nothing and you still keep the teardown.

That's the deal in one sentence. Here's everything inside it.

The Activation Teardown, before you commit to anything. I put your existing onboarding through the analysis and send you a report: where people drop, which step leaks, what I would change first and why. It's yours whether you take a seat or walk away, and you don't need to install a single line of code to get it.
The install, done by me, by hand. Up to four hours on a call, in your codebase, together. Not a docs link and good luck. This is the part that doesn't scale, and it's exactly why there are 15 seats and not 500.
Your bugs jump the queue. When you hit something broken, and you will, it gets fixed that day instead of queueing behind everything else. That stops being possible the moment this cohort is full.
A direct line to the roadmap. What gets built next is what early-access apps need next. At this stage that isn't landing-page language, it's just how the queue works, because there is nobody in front of you.
Analytics free to 1 million events a month. Any app, not only early access, and it doesn't expire when the beta does.

No price, and that's deliberate. I'm not deciding what Wire AI costs until early access tells me what it's worth, so nobody in these 15 seats gets priced by a guess.

What I want back

One thing: the truth, while you use it.

When a question the AI asks is stupid, say so. When the console confuses you, say so. When a number looks wrong, say so, and that one is worth more to me than any testimonial you could write.

That's the whole trade. You get the teardown, the install, the queue and the roadmap line. I get the thing I can't buy, which is honest reactions from a real app with real users in it.

If it isn't you, it might be someone you know

All three seats that are gone came warm. Somebody knew somebody. Not one came from a cold email, and I have sent a lot of cold emails, so I've stopped pretending that's the channel.

So if your own app doesn't fit but a name came to mind while you were reading, that's the ask. Forward this to them, or drop the name in a comment and I'll reach out and tell them you sent me.

Anyone arriving through a referral skips the queue and goes straight to a call. And I'll run the Activation Teardown on your app too, even if you never install anything.

Before you say yes, two things you should know

Only the onboarding stage is live and proven. The journey wide experimentation I described up there is the roadmap, not a shipped feature. I'd rather you hear that now than find it out in week two.
I have an open number I can't explain yet. This week my own dashboard read 23% completion on an app that had been finishing north of ninety. I spent a morning on it and I still don't have a clean answer. Best guess is the dashboard, there are two honest ways to compute a completion rate and my headline tile looks like it's reading the wrong one, but I haven't proven it and I'm not going to pretend I have.

Both of those are in a launch post on purpose. The product is deliberately incomplete at this stage, and the fastest way to harden it is with a few real apps inside it rather than a year of me polishing it alone. If that reads as a red flag, this isn't the right moment for you and that's a fair call.

Who this is for

You're a fit if you have a React Native or Expo app that's live, with real users going through an onboarding right now, and you're a solo founder or a tiny team where the person who feels the activation problem is also the person who decides.

It helps if your app already has AI or personalization in it, because then I don't have to sell you the idea and we can go straight to the mechanics.

You're not a fit if you already have a growth team running experiments every week. Genuinely. A larger company passed on this recently for exactly that reason and they were right to. The value here is removing a person from a loop you don't have. If you have the person, you don't need me.

Pre launch is also a bad fit, and I say that with some regret because those are usually the most fun conversations. Without traffic there's nothing for the loop to learn from.

How to claim a seat

Reply to this email. That's the whole process, there's no form and no demo request.

Tell me what your app does and roughly how many people go through onboarding in a week. Two sentences is plenty. If it's a fit I'll send you a time this week. If it isn't, I'll tell you straight instead of quietly moving you into a nurture sequence.

Not sure you qualify? Ask for the teardown anyway. Worst case, you get a report on your own funnel and we both move on.

12 seats left of 15. The cap is real, because the install is manual and I'm the one doing it.

How I make this

I draft with AI. I've written about my workflow more than once and it'd be strange to hide it here. The receipts, the numbers, the decisions and the opinions are mine, the sentences get a drafting partner and then a lot of editing from me. If that disqualifies me for you, fair enough. If it interests you, that's most of what this newsletter is about.

I'm Malik, 9 years building mobile apps, React Native and Expo. I write Code Meet AI, where I show what I'm building with AI and what it costs me. Wire AI lives at getwireai.com, and the SDK is open source.

Fable 5 vs Opus vs GLM: I had a cheaper model grade the audit of my own code

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

i'm building Wire AI, and the next piece i have to build is the learning loop. It's the self-improving core of the engine: it takes each user's journey inside the app, generates variations of that flow, tests them, and keeps whatever makes people activate and stay. Real implementation work, a big pile of it, and the kind you'd rather not write by hand at frontier prices every single time.

so i wanted to do that build with a cheaper Chinese model, GLM 5.2, instead of reaching for a frontier model on reflex. one problem. cheap-and-wrong is the most expensive thing there is, and i was not about to let a model i hadn't vetted write production code inside my own engine. so before i trusted it with anything, i gave it a hard, real technical challenge: audit the actual codebase behind Wire AI and tell me where it breaks. not a benchmark, my own code, the files i'd opened a dozen times and thought i understood.

and i didn't just point GLM at it and hope. i ran the same audit through three models to see where the cheap one really lands: GLM 5.2, the candidate i actually wanted to hire for the build; Opus 4.8, my daily driver and the reference i already trust; and Fable 5, the ceiling. cheap, reliable, frontier, same job, and i'd grade every finding myself.

Here is what happened, with the receipts, because a feeling is not evidence.

Most model comparisons you read are benchmark charts on tasks neither you nor the author care about. i wanted the other thing. One real task, my own codebase, the actual numbers off the runs instead of vibes. So i gave three models the identical job inside Claude Code: audit the architecture of this SDK and tell me where it breaks when i build on top of it. Same prompt, same files, same instruction to cite every claim with a real file path. Then i read every output against the source and counted what was actually true.

a quick aside on what the codebase even is

The code i audited isn't a side project. It's the engine behind Wire AI, the thing i'm building, and it helps to know what it does before you watch three models take it apart.

Wire AI finds your app's winning formula. The one-breath version of how: it runs the experience inside your app, the first session a user gets, the moment they finally get it, the parts of the app they find, what they tell you back, then tests the variations itself and keeps the ones that make users stay. You set the goal. The AI runs the loop.

Here's the part that's easy to miss, and it's the reason i keep testing this thing against real code. Changing the app with no release isn't the trick, plenty of tools do that now. The difference is who's holding the pen. In the usual setup a person sits in a no-code builder and drags the new flow together by hand. In this one there's no builder and nobody in the middle: the AI writes the variants, runs them, and promotes the winner. That's the whole bet, and it only works if the engine underneath is right.

The part i keep pointing models at is exactly that engine, the piece that generates and renders those flows at runtime, the server deciding what a given user sees and the app drawing it without a new binary. It's the code with real users behind it, so it's the code i actually need to be right. Which is why i handed it to three different models and read every word back against the source.

the audit, scored

GLM 5.2, the cheap one. Opus 4.8, the one i run every day. And Fable 5, the frontier model, the most capable one i have access to. Same job for all three.

GLM and Opus found the same five problems. Not similar problems. The same five, down to the files.

They both caught that my component types get sealed into the bundle at startup, so an agent can't define a component at runtime. They both caught that streaming is dead on the agent path because the adapter never implemented it. They both caught the drift between what my SDK can render, what my server allows, and what my model actually gets told about. They both traced the coupling between the SDK and the agent backend to the same leaky spot. And they both landed on the same fix, make the registry the single source of truth.

i verified the citations on both. Zero hallucinations, every file path checked out. GLM even found one extra thing Opus missed: a comment in my backend claiming it runs the latest Claude while the code underneath quietly calls a cheaper OpenAI model. The kind of lie your own codebase tells you.

So on those two it was a tie. One costs roughly ten times less than the other and it found the same five things. If the story ended there the headline writes itself, run the cheap one for audits, go home.

Then i gave Fable 5 the identical prompt, and it found eleven.

Not five. Eleven distinct architectural problems, plus three smaller ones it flagged separately as lower severity. The same five the other two found are in there. Then six more, and i checked those against the source the exact same way. The streaming path advertises a sixty second timeout in its own docstring while a hidden thirty second poll cap kills the request first. The mechanism the SDK exports to tell an agent what components exist is built, tested, and wired into nothing. The registry silently ignores a component swap if you keep the same name. The agent card reads a private Zod internal that a supported version of Zod no longer has, so it degrades to typeless without ever throwing an error. Real, cited, reproducible. Zero hallucinations again, and it rated its own weaker findings as medium confidence instead of overselling them.

Later i ran the inverse experiment, because trusting a frontier model on my own code without a check is exactly the mistake i tell everyone else not to make. i had a cheaper model independently re-verify all eleven findings, line by line, plus the three secondary ones. Fourteen confirmed, zero refuted. The frontier model found the problems, the cheap one confirmed the homework.

Take one of them, the sixty-versus-thirty-second one. My agent path promises sixty seconds right there in its own docstring, and underneath it a hidden thirty second poll cap kills the request first. i would have built onboarding flows on top of that, watched a perfectly legitimate agent run die at thirty seconds, and burned an afternoon blaming my prompt or the network before i found the real thing. Fable found it by reading. That's the one that landed for me, because it's the exact kind of bug you only ever meet in production, on a user's screen, at the worst possible time.

That's the finding that reframes the whole comparison. It's not that Fable is a better model on a leaderboard. It's that on a genuinely hard read, depth is not free, and the cheaper models stopped at the obvious layer.

the numbers behind the runs

This is the part i actually care about, pulled from the session logs, not estimated.

	GLM 5.2	Opus 4.8	Fable 5
Distinct problems found	5 (+1)	5	11 (+3)
Hallucinations	0	0	0
Turns / tool calls	69	64	40
Fresh input tokens billed	644,000	88,000	62,000
Wall clock	6.0 min	18.1 min	~8 min
Cost	$0.59	~$6	~$14

A few things jump out.

Token consumption runs the opposite direction from price. GLM billed six hundred and forty four thousand fresh input tokens for the job. Opus billed eighty eight thousand. Fable billed sixty two thousand, the fewest of the three, and it did the deepest read. The two expensive models lean hard on context caching, reusing what they've already read at a steep discount, and that's most of why they can cost more per token and still not blow up on input. You're not just paying for the weights, you're paying for how few fresh tokens the model needs to hold the whole codebase in its head at once.

But few tokens is not cheap. Fable billed the fewest fresh input tokens and still cost the most, because the frontier price sits on top of every token and its denser output is expensive to generate. GLM is a tenth of that. So the cost curve and the depth curve run in the same direction: you consume more, you get more, and the more here is real problems in real files, not padding.

Speed didn't track price either. GLM was fastest at six minutes. Fable came in around eight. Opus, on maximum reasoning effort, took eighteen, because i deliberately run it slow and thorough. Fast and cheap didn't mean shallow on the five, and slow and expensive wasn't the deepest. The deepest was the frontier model, at a middle speed. None of the tidy stories hold.

then i made one of them build

A read tests reasoning. It doesn't test whether a model can do unattended work. So i ran a second round, GLM only, on a real build: take the drift bug from the audit and fix it properly. Single source of truth, generated manifest, a test that fails if anything drifts again.

It worked. Ninety two tests passing when i ran them myself, a drift guard that failed correctly when i sabotaged it on purpose, two previously unreachable components wired through end to end. A clean, verified, tested refactor.

And the build burned nearly seven times what the audit did. Same model, same codebase, one fix. Not because the fix was large, because building unattended means iterating, and iterating burns tokens. Three hundred and seventeen turns. A hundred and twenty seven tool calls, more than half of them just running tests and reading the errors. On a read the cost gap is enormous and it's in GLM's favor. On a long build it closes fast, because the cheap model pays for its discount in extra steps.

what each model actually gave back

All three earned a job. That's the real conclusion, and it's more useful than a winner, because it tells me what to do on Monday.

Opus is the daily reliable read. It found the same five things GLM did, cited clean, no drama, on the everyday work where the answer sits at the obvious layer. It's the one i trust without babysitting it, and on a long autonomous build the token efficiency i pay for stops being a luxury and becomes the reason the job finishes cheaper than the sticker suggests.
GLM is the cheap different lens. It found the same five, at six hundred and forty four thousand tokens of brute-force reading instead of clever caching, and it surfaced the one comment the frontier model didn't. i don't care how it got there when the output is right and the run comes in an order of magnitude under the one i trust. For volume reads it's the pick, and even on a build it finishes, it just pays in turns.
Fable is the surprising deep finder. It found six real problems the other two walked straight past, in the exact files, with honest confidence about the ones it was less sure of. That's the model you point at the thing before you commit six months to building on top of it. One deep read to not ship on top of a broken assumption is the cheapest line item in the project.

None of them replaced the others. Cheap for volume, efficient for endurance, frontier for depth. Better outcome than a leaderboard.

where this actually went

Here's the part that isn't abstract. Those findings didn't sit in a doc. They went back into the engine, and the first tenant running it in production felt the difference.

The sixty-versus-thirty-second bug and the drift bug were the exact kind of thing that shows up as a mystery failure on a real user's phone. Hardening them was the point of the audit. Around the same stretch i chased the first-card latency on the onboarding and it dropped from about 2279ms to 71ms, because i prefetch the adaptive card while the user answers the fixed questions instead of after, so the first screen a user sees is close to instant now.

And the loop holds. On the live tenant it runs about 88.5% completion with zero server language-model fallbacks, on real production traffic. When the AI tested the flow length itself, the short version, roughly eight screens, won at 92.8% on its arm. Earlier in that tenant's life the same loop found the message that actually resonated and daily installs went from about 100 to 1,000, because it landed on the exact problem users showed up to solve.

i want to be honest about what that is. It's a set of real receipts, not one clean before-and-after conversion number. i don't have a single "we lifted X%" figure and i'm not going to invent one. What i have: a hardened engine, a first card that went from a beat-and-a-half to instant, a live flow completing in the high eighties to low nineties with nothing falling back to a language model on the server, and an acquisition number that moved because the loop found the words. That's the improvement, stated as the numbers i can actually stand behind.

That engine is Wire AI, and here's the one line that matters if you build apps. You put AI in your product, a feature, a chatbot, a recommendation. i let AI run mine, the loop above is the AI operating the product's experience, not sitting inside it as one more feature. Same instinct you already have, pointed one layer up. The easiest way in costs you nothing. Analytics free to 1M events/month. Forever. Any app. Wire it up and watch where your own funnel actually leaks before you commit to a thing. If you want the loop itself running your product, i'm taking 10 founders into a free founding cohort right now, and the deal is plain: don't pay if we don't improve your activation. i set it up with you hands-on and stay in it with you month to month, no invoice attached. If you just want to see where your app leaks first, i'll run you a free Activation Teardown, one AI report on your real users, ending in "here's what to fix", no strings. If you ship React Native and you've already got AI somewhere in the app, you're exactly who i want in that cohort. Reply and i'll run your teardown.

the honest caveats

Four, so nobody quotes this out of context.

This is one task type on one codebase. Strong evidence about reading and reasoning over real code. On building it's exactly one data point, GLM only, not a verdict.
The depth result is one audit. Fable finding eleven where the others found five is a real, verified result on this codebase. It is not a promise the frontier model always doubles the count. Run your own hard task before you trust the pattern.
The provider matters. i pinned GLM to its first-party host at full precision. The cheaper resellers serving the same model name can be quantized and worse, and then you're measuring the host, not the model.
And the telemetry isn't perfectly symmetric. The Opus and GLM numbers came from the original run transcripts. Fable's came from a clean re-run of the identical audit, and i've flagged every number that's measured slightly differently instead of smoothing it over.

If you want the raw data, the full audit from each model, the telemetry table, and the config i used to run all three, reply RECEIPTS and i'll send the breakdown.

context engineering, simplified

Malik Chohra — Tue, 21 Jul 2026 09:43:04 +0000

TL;DR

A prompt is the ask. Context is the ground it stands on: who this is for, what good looks like, the real material, and what to leave alone.
When the AI gives you generic or wrong output, the reflex is to write a cleverer prompt. Usually the prompt was fine and the context was thin.
More context is not better context. Dump everything in and the model loses the thread. Curation is the actual skill, and the boundary (what to ignore) is the load-bearing half.
Write the context down once, in a small set of files next to the code, and every future task starts from ground instead of a guess. Stale context is worse than none, so treat it like a dependency you keep current.

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.

A few weeks ago an AI i built into an app asked a real user to name a beach-party plan. First thirty seconds in the product. The app can technically make a plan called that, so it wasn't a hallucination exactly, it was worse: a real feature dragged to the front because the model had nothing better to go on. i had handed it a one-line description of the app and told it to get the user to a concrete first action. A one-line description is an invitation to guess. So it guessed, confidently, in front of someone i was trying to keep.

That was the moment context engineering stopped being a phrase i skimmed past and became a bug with a name. And here is the part that should get a senior dev's attention: the failure looked exactly like AI code that compiles clean and still ships a bug. Confident, plausible, wrong. The fix was never a better prompt.

a prompt is the ask, context is the ground

The prompt is what you want. "Write the migration." "Refactor this service." "Draft the onboarding." Short, and you already know how to write one. Context is everything the model needs to answer that well and doesn't have unless you give it: which service owns this, which files are generated and off-limits, what the system actually does and who is on the other side of it. The prompt points at a target. Context is whether the model can see the target or is throwing in the dark.

Most bad AI output is not a bad prompt. It is a fine prompt fired into an empty room. The model fills the empty room with the most statistically average thing, and average is exactly what makes you close the tab and call it overhyped.

the four things you are actually feeding it

When people say "context," they mean four different things stacked together. It helps to see them apart.

A prompt is the arrow. These four are the ground it lands on.

The goal. Not the task, the outcome. "Turn these contracts into a tracker" is a task. "so i can see at a glance which renewals are risky this quarter" is the goal. Give the model the why and it makes better calls on the hundred small things you didn't specify.

The ground truth. The real material, not a description of it. This is the one people skip. Don't tell the AI "our style is terse and functional," paste two modules that already read that way. Examples beat adjectives every time. A model shown three real things you like will out-perform any paragraph describing them.

The constraints. What good looks like and what to never do. The format. The interface it has to satisfy. The generated files it must not edit. Constraints are not the AI's handcuffs, they are how it knows it succeeded instead of guessing at your taste.

The boundary. What to leave out and what not to touch. This is the half nobody talks about, and it is coming next, because it is the one that separates people who are good at this from people who just paste more.

more context is not better context

Here is the counter-move, and it is the part everyone gets wrong.

Once you learn that thin context causes bad output, the obvious next step is to feed it everything. The whole repo. The entire history. Every doc, in case it helps. It feels thorough. It is the exact opposite of thorough.

A model has a working memory, and past a point, adding more doesn't inform it, it distracts it. The signal you actually needed gets buried under fifty files of nearly-relevant noise, and the answer gets vaguer, not sharper. i have watched a model give a worse answer to the same question after i "helpfully" pasted three more files. The good lines were in there. It just couldn't find them anymore.

So context engineering is not "add context until it works." It is "give it exactly what this task needs, and nothing that competes with that." Curation, not accumulation. Telling the model what to ignore is as load-bearing as telling it what to read. This is the same discipline as scoping a service token: you grant the access the job needs, not everything you own, because blast radius is real whether the risk is a leaked secret or a distracted model.

The test i use now is embarrassingly simple. Before i paste something in, i ask: does the model need this to answer, or am i adding it to feel safe? The second kind is the noise.

how to actually do it

You don't need a framework. You need four sentences before the task, roughly in this order.

State the goal, not just the task. One line on the outcome you're actually after. "so that..." is the most useful phrase in the whole practice.
Show, don't describe. Paste two or three real examples of what good looks like. A before, an after, a module you'd be happy to merge. This single move fixes most "it sounds generic" complaints.
Name the constraints and the anti-goals. The format, the interface, the hard limits, and the one or two things it must never do. Short bullets are fine.
Draw the boundary. Say what to use and what to ignore. "Only this package." "Don't touch the generated types." "The old implementation is background, not a template."

That's it. Four sentences turns a coin flip into something you'd actually ship.

write it down once

The last move is what makes this compound instead of repeat. The first time you assemble the context for a recurring job, don't throw it away. Put it in the repo, next to the code it describes. Next time, you point the AI at the folder and add one line for today's task. A five-minute setup becomes a five-second one, and the output stays consistent because the ground under it stopped moving.

On a real project this is not one file, it is a few, and the names are becoming a standard any agent already reads. PROJECT.md for what the thing is and why. CONTEXT.md for what you are working on right now. CLAUDE.md and AGENTS.md for the rules and conventions you want followed. README.md for the human who lands cold. And progress.md, the memory file from episode 02, for what happened last.

the context lives in the repo, not in your head. any AI you point at the folder reads it and knows where it is.

If episode 02 sounds like it is happening again, that is because it is. A memory folder is context that persists across sessions. A context file is the same instinct pointed at a single repo.

where this breaks

Two ways, both worth knowing.

Stale context is worse than no context. A context file that still describes last quarter's architecture will make the AI confidently wrong, and confidently wrong is the expensive kind. When the thing changes, change the file. It is a living note, not a monument, and it belongs in code review like anything else that drifts.

And context is not a substitute for the check. Grounding the model dramatically raises the floor, it does not remove your job of reading the diff before you trust it. A non-engineer has no compiler and no test suite to catch a confident lie, but neither does your prose. The review step is the job that does not get automated away, and it is its own episode later in this series.

The punchline is small and annoying and true: most of the time the AI wasn't wrong because it is dumb. It was wrong because it was guessing, and it was guessing because you didn't tell it the thing you assumed was obvious. Context engineering is just the discipline of saying the obvious thing out loud, once, and then reusing it.

I put together a context starter pack: the four-line context you write before a task, the set of files that give any AI your whole project's context (PROJECT, CONTEXT, CLAUDE, AGENTS, README, and the progress.md memory file from episode 02, each explained), and the one prompt that sets them up for you. It goes out through the newsletter first.

Written by Malik at Code Meet AI. This is episode 04 of Using AI, properly. Episode 02 was give the AI a memory, episode 03 was put the AI on the work around work. 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. Next up: how to make the AI check its own work, before you do.

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.