DEV Community: Malik Chohra

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

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

TL;DR

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

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

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

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

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

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

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

What generative UI actually is

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

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

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

Why big tech suddenly cares

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

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

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

What web companies already ship

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

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

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

The Gemini moment

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

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

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

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

So why is mobile still behind?

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

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

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

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

How far does this go?

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

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

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

So I'm building it

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

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

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

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

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

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

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

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

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

FAQ

Is generative UI the same as a chatbot?

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

Does the AI write code at runtime?

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

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

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

Is generative UI safe for production apps?

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

Where does generative UI make sense first?

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

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

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

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

TL;DR

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

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

Prompt engineering, then context engineering, then the wall

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

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

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

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

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

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

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

What I built instead: a second brain that starts warm

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

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

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

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

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

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

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

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

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

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

So this has a name now: harness engineering

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

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

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

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

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

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

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

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

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

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

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

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

The harness rots. Maintaining it is the job.

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

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

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

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

How to start one without a course

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TL;DR for builders

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

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

Full story below.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What did I build with it?

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

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

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

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

The thing the weekend produced: AI Web Launcher

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

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

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

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

Where did it bite me?

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

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

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

My Fable 5 session setup

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

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

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

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

Where this breaks

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

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

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

FAQ

Is Claude Fable 5 worth the cost?

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

Fable 5 vs Opus 4.8, which should I use?

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

Why did Fable 5 crash my subagents?

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

Can a better model fix a messy codebase?

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

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

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

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

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

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

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

TL;DR

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

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

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

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

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

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

Why your app is invisible to Siri without App Intents

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

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

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

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

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

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

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

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

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

Apple just made AI providers swappable in one line

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

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

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

Foundation Models now runs on Linux and speaks Python

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

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

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

What the Apple and Google deal admits

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

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

The EU and China caveat, which is personal for me

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

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

What to do before iOS 27 ships

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

For React Native developers

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

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

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

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

FAQ

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

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

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

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

Can React Native apps use Apple Foundation Models?

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

Does Siri AI work in the EU?

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

Is App Intents only useful for Siri?

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

What I'm shipping this week

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

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

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

How to write a Claude Code skill (and the gotchas the docs skip)

Malik Chohra — Tue, 02 Jun 2026 08:23:44 +0000

I put off Claude Code skills for six months because the docs made them sound like a framework. Then I opened one and it was a markdown file. One file, a few lines of YAML, done.

If you already keep a CLAUDE.md and a memory folder, you're most of the way there. This is the from-scratch guide: what a skill actually is, how to write one, the gotchas that aren't in the docs, and a real, non-trivial example (a memory system I packaged as a skill in an afternoon).

TL;DR

A Claude Code skill is a folder with one SKILL.md file inside it. That's the whole mechanic.
The description field is the trigger. Spend most of your writing time there, not on the body.
The minimum viable skill is about 30 lines. References, templates, and scripts are optional add-ons.
I packaged my memory system, UAMOS, as a skill: 4 layers, 5 modes, version-controlled. The lessons are at the end.

What a skill is, mechanically

Four parts, three of them optional:

A folder at ~/.claude/skills/<name>/ for a global skill, or <project>/.claude/skills/<name>/ for a project-local one.
A SKILL.md file inside it. Required.
YAML frontmatter at the top with name and description. Required.
Markdown instructions below the frontmatter that tell Claude what to do once the skill fires.

Optionally, you add one or more of these. None are required for a working skill:

references/: docs Claude reads when it needs depth, but never copies.
templates/: files Claude copies into a project, usually with placeholders.
scripts/: code Claude runs when a prompt isn't enough.

The mental model that helped me: a skill is to Claude what a cron job is to a server. It sits as files on disk and fires automatically when its trigger condition is met. You don't call it explicitly. You talk to Claude normally and it picks the right skill.

How to create one, step by step

Here is a complete, working skill in 30 lines:

---
name: my-skill
description: Run when the user says "do X", "perform Y", or asks for a Z report. Used for ABC purpose.
---

# My Skill

You are a specialist in [whatever]. Your job: [one sentence].

## Steps

1. Read the file at [path].
2. Do [thing].
3. Output [format].

## Hard rules

- Never [the thing that would break trust].
- Always [the thing that compounds].

Save that to ~/.claude/skills/my-skill/SKILL.md, restart Claude Code, and ask for "do X." It fires. That's the entire create-a-skill loop. The hard part isn't the syntax. It's writing a description that actually triggers, which is the first and most important best practice.

Best practices nobody put in the docs

I burned a few hours on each of these.

The description is the trigger, so write it for the matcher

When Claude starts a session, it reads the description of every installed skill and matches your request against them. The description does two jobs at once:

It tells you, the human, what the skill does.
It tells Claude, the matcher, when to fire it.

My first version of a skill had the description "Manages my project operations." Claude never fired it. Not once. I rewrote it to list the literal phrases I'd type ("set up the project here", "audit this", "rebuild the index") and it fired on the first matching request. Abstract summaries don't match concrete requests. Spend 80% of your effort here. The body is for Claude to follow after the skill is already firing; the description decides whether it fires at all.

One skill, one purpose

Your first skill will be tempted to do five things. Resist. If you find yourself writing three workflows that don't share state, those are three skills, not one. A bloated description has to cover too much, so it matches inconsistently, and editing one part risks breaking the others. When several skills need the same knowledge, put it in one shared skill they all read, rather than copying it into each.

Know the difference between references and templates

This one bites people. Templates are files Claude copies into your project, usually with placeholders to fill in. References are files Claude reads for context but never copies. Folder naming carries the meaning: put scaffolds in templates/, put background docs in references/. Get it backwards and Claude will either write a reference doc into your project (wrong) or treat a scaffold as read-only and never produce the output (also wrong).

Skills don't auto-reload

If you edit a SKILL.md mid-session, the running Claude Code instance is still using the version it loaded at startup. Restart the session to pick up changes. I lost 20 minutes debugging "why isn't this rule firing" before I realized this. The same applies to brand-new skills: they're discovered at session start.

Version-control your skills folder

A skill is codified workflow. If ~/.claude/skills/ isn't version-controlled, every machine you work on runs a slightly different version of it, and you stop trusting them. I keep mine in my notes vault and symlink. Committing the folder to a personal repo works just as well. Doing neither is how skills quietly drift apart across machines.

The worked example: building UAMOS as a skill

Most of my skills are a single file. UAMOS is the one that needed all the optional parts, so it's the best example of how the pieces fit.

UAMOS (Universal AI Memory Operating System) is the layer that gives a project memory: it loads consistent context, rules, and an index before any AI session writes code, so the agent stops reinventing things that already exist. It's stack-agnostic. I run it on a React Native codebase, but the same skill installs on Node or Python, because the structure is the same and only a couple of stack-specific rules get swapped at install time.

It's four layers, and each one is a precondition for the next:

Read top to bottom:

Indexing tells the agent where everything lives, so it stops running blind grep and glob.
Memory bank keeps state across sessions in 9 tiered files (hot, warm, cold).
Rules constrain what the agent is allowed to write, in three tiers.
Agents split the work across 5 specialists, each loading only the layer it needs.

The relation is the part that matters: indexing prevents the agent from hallucinating files that don't exist, memory keeps state across sessions, rules constrain the diff, agents specialize the workflow. Pull one layer out and the others degrade.

The file tree

UAMOS uses every optional part of the skill spec:

~/.claude/skills/uamos/
├── SKILL.md                    # the brain: modes + hard rules
├── references/                 # docs Claude READS, never copies
│   ├── 4-layer-architecture.md
│   ├── 7-point-checklist.md
│   └── memory-tiering.md
└── templates/                  # scaffolds Claude COPIES into a project
    ├── CLAUDE.md
    ├── globalRules.md
    ├── context_map.md
    ├── memory/   (9 tiered starter files)
    └── rules/    (3 critical rule files)

The SKILL.md holds the modes and the hard rules. The references/ files explain the system in depth so the SKILL.md can stay short and point at them when a question needs detail. The templates/ files are working scaffolds with {{PROJECT_NAME}} placeholders that get filled in during install. Keeping depth in references means the skill loads light every session and only pulls the heavy explanation when a mode actually needs it.

The modes and the commands that trigger them

A single skill can package several related workflows as modes, each with its own trigger phrases. UAMOS has five, and I drive them in plain language:

init ("set up UAMOS here") interviews me with five questions about the project, then scaffolds the full folder structure and inventories the existing code.
audit ("audit my memory bank") walks the current setup and reports staleness with a status table, flagging a Hot tier that hasn't been touched this week or an inventory that's drifted from the real file count.
reindex ("reindex this codebase") rebuilds the inventories after a batch of new code ships.
progress / decide / learn ("append progress", "capture a decision", "capture a lesson") write dated, append-only entries to the right memory file. Memory is sacred here: nothing overwrites, and the skill never writes the progress log unless I trigger it.
migrate ("migrate this project to UAMOS") is init for a codebase that already has code: it indexes first, preserves any existing AI rules, and fills in the memory bank from the real structure.

Modes are how you package related-but-distinct workflows in one skill without splitting it into five skills with overlapping descriptions. UAMOS is honestly borderline on the one-skill-one-purpose rule, but the modes share enough underlying knowledge of the same file structure that splitting them felt worse than keeping them together. Make that call on purpose, not by accident.

What it cost and what it returned

The skill took an afternoon to build, most of it on the templates, not the SKILL.md. On the project I've run it on longest, the numbers after a month:

Context spend: down roughly 91%, because the agent stops searching blindly.
Hallucinated edits: down roughly 93%, because it stops inventing things that already exist.
Setup cost: about a day for the full install, an hour or two for a minimal one.

The part that compounds is the feedback loop. A recurring problem in the progress log becomes a new rule. A non-obvious pattern I had to work out gets logged so I don't relitigate it next month. Each session makes the next one cheaper, and that only works because skills are plain files reading and writing other plain files. No database, no orchestration engine.

When a skill is overkill

Skills are for workflows you run by hand more than three times. A heavyweight skill like UAMOS is overkill in some cases and worth it in others:

Overkill for: a throwaway script, a solo prototype you'll abandon in a week, or any codebase you won't reopen.
Worth it for: long-lived projects, code that more than one AI tool touches, and anywhere consistency across sessions matters more than raw speed in a single one.

Two honest caveats beyond that:

Auto-trigger isn't perfect. Even with a sharp description, Claude occasionally misses the match, and the fallback is to invoke the skill by name.
Skills rot. An inventory drifts, a rule stops being true when the stack changes. Plan on a periodic audit, or you'll stop trusting the system, which defeats the point.

Where to start

Don't build something like UAMOS first. Start small.

Pick one workflow you run by hand more than three times a month. One specific thing, not "everything I do with Claude."
Create ~/.claude/skills/<name>/SKILL.md and write the 30-line skeleton from earlier.
Spend most of your effort on the description. List the literal phrases you'd type to trigger it.
Restart Claude Code and test by saying one of those phrases word for word.

If it fires, you have a skill. Build the next one when you catch yourself doing the same thing by hand a fourth time. The memory layer can wait until you have a project worth remembering across sessions.

I write Code Meet AI, one issue per week on AI-native mobile development. The UAMOS skeleton bundle (the SKILL.md, the 9-file memory bank, and the 3 critical rule templates) goes out to subscribers.

FAQ

What is a Claude Code skill in one sentence?

A folder at ~/.claude/skills/<name>/ containing a SKILL.md file with YAML frontmatter (name and description) and markdown instructions, which Claude loads at session start and fires when your request matches the description.

How do I create a Claude Code skill from scratch?

Create the folder, add a SKILL.md, write YAML frontmatter where the description lists the actual phrases you'd say to trigger it, write your instructions below, and restart your Claude Code session. The minimum viable skill is about 30 lines.

Why isn't my skill firing?

Almost always the description. Claude matches your request against it to decide what to fire, so an abstract description ("manages my project") won't match a concrete request ("set up the project here"). Rewrite it with the literal phrases you'd type, then test by saying one of them verbatim. Also remember skills don't reload mid-session, so restart after editing.

What's the difference between references and templates in a skill?

References are files Claude reads for context but never copies. Templates are files Claude copies into your project, usually with placeholders. Put background docs in references/ and scaffolds in templates/. Confusing the two is one of the most common skill-authoring mistakes.

Can one skill do more than one thing?

Yes, through modes: distinct workflows packaged in one skill, each with its own trigger phrases. UAMOS has five (install, audit, reindex, append-to-memory, migrate). Use modes when the workflows share underlying knowledge. When they don't, make them separate skills.

How to build a second brain with Obsidian and Claude Code (step by step)

Malik Chohra — Sat, 30 May 2026 16:18:48 +0000

Six folders, one context file, a memory directory, and a handful of slash commands. The exact setup, in build order.

TL;DR

A second brain fails when notes pile up and nobody reads them again. The fix is a layer underneath the notes that an LLM reads for you.
This is the setup I built in about a day and have run for two weeks: PARA folders, a CLAUDE.md context file, a memory directory, and slash commands.
Obsidian holds the markdown. Claude Code reads it, writes to it, and runs commands against it.
Steps 1 to 4 are the structure. Steps 5 and 6 are the part that makes it stick.
It is plain markdown in a folder. Nothing is locked in. If Claude disappears tomorrow, you still have your notes.

For the full guide, with the prompt that you can use directly to generate your second brain, and a step-by-step, detailed guide, is here: https://choumed.gumroad.com/l/nhgsxf. you can grab it for free

What is a second brain?

A second brain is a personal knowledge system that lives outside your head. It holds your ideas, decisions, project state, and references in a place you can return to and build on. The term comes from Tiago Forte's book Building a Second Brain. His original framing assumed a human would read the notes back. Mine assumes an LLM will.

Two tools do the work.

Obsidian is the storage. A desktop app that opens any folder of markdown files and adds links, search, and a graph view on top. Your files stay on your disk. No cloud unless you turn it on, no proprietary database, no export step. If you want your notes back, you already have them.

Claude Code is the operator. A tool from Anthropic that runs in your terminal, reads files in a folder you point it at, and runs against saved prompts. You tell it to read your vault and act. It does.

The pair is the whole idea. Obsidian makes the notes legible to a human. Claude Code makes them executable by a machine. Neither one alone gets you a second brain. Together, they do.

Why most second brains die, and the one change that fixes it

I have started a second brain six times. Roam, Notion, Tana, Logseq, Notion again, a short flirtation with Reflect. All six died the same way. I built the structure on a Sunday, filed notes through Wednesday, and by the next weekend the vault was just another inbox to clean.

The standard diagnosis is "capture is easy, retrieval is hard." That is correct. You write 200 notes and six months later cannot find the thinking behind the decision you made in March. The graph view looks great in screenshots. It does not answer questions.

But that diagnosis blames the tool. The real problem is that you were the only retrieval engine. Asking a human to read 500 markdown files back every week is asking them to be a database. They will not do it. The vault rots.

The fix is to put a reader underneath the notes. Not a human. An LLM that treats your vault as required reading. That is the whole trick. Everything below is how to set it up.

What you are actually building

Three parts, and the order matters.

The vault is your brain. Plain markdown files in folders. This is Obsidian's job.
Claude Code is the operator. It reads the vault, writes to it, and runs commands against it.
Slash commands are the interface. They turn the folder from a place you file things into a place you work from.

A vault without the operator is a filing cabinet. The operator without commands is a chat window. You need all three.

Step 1: Build the PARA skeleton

Install Obsidian and create a vault. A vault is just a folder. Inside it, create six folders at the top level:

00-Meta/        # the operating layer (read first by everything)
01-Projects/    # active work with a deadline and an outcome
02-Areas/       # ongoing responsibilities, no deadline
03-Resources/   # reference material and templates
04-Archives/    # done, paused, dead
05-Daily/       # one note per day, the journal

The middle four are Tiago Forte's PARA method. The two numbered additions are what a developer's vault needs and PARA does not specify: 00-Meta for the files that run the system, and 05-Daily for the journal.

Treat 01-Projects the way you treat a codebase. One folder per project. Each gets a progress.md (a dated log of what shipped) and a roadmap.md (what is next). Feature first, same as your repo.

The folders took me 30 minutes. Do not spend a Sunday on this. The structure is not the hard part, and it is not where the value is.

Step 2: Write CLAUDE.md, the file Claude reads first

This is the step that carries the weight. Create 00-Meta/CLAUDE.md. It is the file Claude Code reads before doing anything else, every session.

Keep it to 200 to 300 lines. Mine covers:

Who I am and what I am working toward right now
My current projects and how they relate
How I want Claude to work with me (direct, opinionated, no hedging)
Voice rules for anything it writes
A list of canonical source files, in priority order
Locked decisions that should not be reopened

Here is the shape of it, stripped to a skeleton:

# CLAUDE.md: context for this vault

## Who I am
[Role, what you are building, what you are optimizing for.]

## Current priorities
[The 3 to 5 things that matter this quarter.]

## How to work with me
[Tone, format, what to push back on.]

## Canonical sources (trust these first)
1. CLAUDE.md (this file)
2. [Your day plan file]
3. [Your active-work file]

## Decisions locked (do not reopen)
- [Decision, with date.]

The difference this makes is large. Without it, every session starts cold and you get generic productivity advice. With it, you ask "plan my day" and get a briefing that already knows your deadlines, your constraints, and the decision you locked last week. You stop repeating yourself. That alone is worth the setup.

Edit this file when decisions change. Twice a week is normal.

Step 3: Add the memory layer

CLAUDE.md is static context. It does not change much. But the state of your work changes daily: what shipped, what got renamed, which decision got made in last night's notes.

That state needs its own home. Claude Code keeps a memory directory per project. Drop one file per fact in there, plus a MEMORY.md index that lists them all.

Naming is boring on purpose:

decision_pricing_locked.md
project_app_launch_timeline.md
feedback_always_run_tests_first.md

One file, one fact. When you lock a decision in a chat session, write it to memory before the session ends. The next session reads the index, pulls what is relevant, and never asks "wait, what did we decide about pricing?" This is the part that gives the vault continuity. Obsidian gives you the spatial layout. The memory directory is what makes next week start from a richer state than last week.

Step 4: Link notes with wikilinks

Obsidian links files with this syntax: [[Project-Name]]. Use it everywhere. The rule I follow: when I create a file, I add links to the related project or area before I save it.

This builds the graph. Obsidian's graph view turns the vault into a visual map of how everything connects.

The graph looks impressive, and that is the trap. The pretty picture is not the point. The point is that wikilinks let Claude Code traverse relationships. When it reads a project file and sees a link to a decision note, it can follow it without you telling it where to look. The graph is for the machine, not for the screenshot.

Step 5: Write the slash commands

This is the step that converts the vault from storage into a system. A slash command in Claude Code is a markdown file in .claude/commands/. It is a saved prompt. That is all. today.md becomes /today.

I run 13. The ones that matter daily:

/context loads the full vault state at the start of a session. It reads CLAUDE.md, the memory index, and the active project files, then prints a situation report.
/today produces the day's briefing. It reads the day plan and the active work, then outputs a top priority with the steps under it.
/log structures the evening journal into the daily note.
/sunday runs the weekly review.

The rest are thinking tools: /trace to see how a decision evolved, /challenge to poke holes in a plan, /drift to catch where I am slipping from my goals. Start with the four above. Add the others when you feel the need, not before.

Writing a command is not hard. Open a markdown file, describe what you want Claude to read and what you want it to output, and save it in .claude/commands/. The first version of mine took an afternoon.

Step 6: Run the loops

Structure is dead weight without a rhythm. Two loops keep the vault alive.

The daily loop. Morning: open Claude Code in the vault, run /context then /today. Evening: record a short voice memo about what worked and what broke, paste the transcript into Claude, run /log. The command writes a structured note into 05-Daily/. A bare daily note looks like this:

# 2026-05-22

## Top 3 today
1.
2.
3.

## Shipped
- What:

## Wins
-

## Friction
-

## Notes and ideas
-

## End of day reflection
> One thing I would do differently tomorrow?
> What should move into a project file or the inbox?

No elaborate template. Five headings. The structure exists so /sunday can read across the week and find patterns.

The weekly loop. Sunday: run /sunday. It reads the week's daily notes, surfaces patterns you missed, and outputs one win, one friction, one thing to change. That output becomes next week's starting context.

Capture flows in through /log. Context flows out through /context. Decisions get locked into memory. That loop is the second brain. The folders were never the hard part.

How I built mine

I scaffolded the vault with Claude in an afternoon. Folders, CLAUDE.md, the first four slash commands. Then I did the harder part. I took my phone to a park, sat in the sun, and opened the Claude mobile app. For about three hours I talked to it like a partner. What I am working on, what is stuck, what I have been avoiding. It asked clarifying questions. I answered. When I got home, I opened the Claude desktop app, pointed it at the vault, and asked it to sync the conversation into the right files. Et voilà. The skeleton I had built in the morning was filled in with my actual life by the evening.

Structure first, content second. Use the mobile app for the talking, the desktop for the filing.

Where this breaks

The honest section, because tutorials never have one.

CLAUDE.md drifts from reality. Rename a file, forget to update CLAUDE.md, and /context produces confidently wrong output. Keep a changelog of structural changes. I still forget to use mine about a third of the time.
The memory directory will outgrow a flat folder. Thirty files is fine. Three hundred will need search or embeddings. The naming convention buys you a long runway, not forever.
It depends on Claude Code as the reader. If pricing changes hard or the CLI gets killed, the executable layer evaporates. The mitigation is that your notes are plain markdown and the commands are short prompts. You lose the operator, not the brain.

Get the prompt that builds this for you

If you want to skip starting from a blank page, paste the Vault Architect prompt into Claude, answer four short rounds of questions, and it builds the whole vault customized to you. Folders, your CLAUDE.md, the four slash commands, the daily template.

The whole thing is a free kit on Gumroad: this guide plus that prompt. Get the Second Brain Vault Kit, free.

I also write Code Meet AI, a weekly newsletter on AI-native developer workflows. One issue a week, tactical, no fluff.

FAQ

How do I connect Obsidian to Claude?

Obsidian stores your vault as plain markdown files in a folder. Open Claude Code with that folder as the working directory and it reads the files directly. There is no plugin or API to wire up. The connection is just the shared folder.

Do I need Claude Code, or does ChatGPT work?

The folder structure and the CLAUDE.md context file work with any LLM that reads context, including ChatGPT custom instructions and Cursor rules. The slash commands are specific to Claude Code, but they are short markdown prompts you can port to any CLI agent.

What folders should a developer second brain have?

Start with PARA: Projects, Areas, Resources, Archives. Add two more that PARA does not specify but a developer needs: a meta folder for the operating files like CLAUDE.md, and a daily folder for the journal. Six folders total. Resist adding more until something genuinely does not fit.

Is Obsidian or Notion better for an AI second brain?

Obsidian, for one reason: the vault is plain markdown in a folder you control, so an LLM can read it with no export step. Notion's data lives behind a database and an API, which adds friction. If you are starting fresh, Obsidian plus a local folder is the cleaner path.

How long does it take to build?

The folders take 30 minutes. The first CLAUDE.md took me about two hours. The slash commands were an afternoon. Total upfront cost is under a day. The memory directory then fills in on its own as you work.

Firebase Hybrid Inference + Gemini Nano: what changed for React Native at I/O 2026

Malik Chohra — Fri, 29 May 2026 14:27:26 +0000

Google I/O 2026 was the first keynote in three years where I came out with a different product roadmap than the one I brought in.

Not because the demos were impressive. Because three announcements have direct implications for product decisions I've been putting off — including specific decisions about my React Native stack. Firebase Hybrid Inference. Gemini Nano in ML Kit. Gemini Spark as a consumer agent. These change what mobile apps (including RN apps) need to do to stay competitive in the next 12 to 18 months.

Here is what mattered, filtered for mobile builders. There's a React Native-specific section at the bottom with concrete package paths.

Is your app's AI running in the right place?

Firebase AI Logic now supports the full Gemini 3.x family. The more important announcement: Hybrid Inference for Android and iOS. Your app decides at runtime whether a given AI task runs locally on the device via Gemini Nano or falls back to the cloud, based on network conditions, device capability, and cost.

The product implication is real. On-device AI is faster (no round-trip latency), cheaper (no API call), and private (data never leaves the device). Cloud AI handles complex reasoning that changes frequently. Most apps today make this choice once, at architecture time, and stick with it. Hybrid Inference makes the routing dynamic.

I always saw this coming. Small models are getting more powerful in execution and size. When I started working on my AI boilerplate for React Native apps (aimobilelauncher.com), I wrote an article predicting this hybrid approach: The Future of AI in Mobile Apps Beyond ChatGPT Wrappers.

Side note: I've opened a first cohort of 20 users — with or without a technical background — who want to launch their mobile apps. Contact me at malik@aimobilelauncher.com for access. You'll get 50% off, and we do the onboarding manually, from first run to shipped app, together.

Users who interact with on-device AI don't wait for a spinner. They get a result in under a second. The apps that feel fast and smart in 2026 will have figured out which tasks belong on-device. The apps that haven't will feel slow by comparison, and users won't know why. They'll just open your competitor's app instead.

Gemini Nano is already on modern Android devices. This is not a capability you are waiting for. It is available now through Firebase AI Logic, and Gemini Nano's latest version handles audio and image processing on-device too, not just text.

What agentic development changes for your team

Google announced Antigravity 2.0: a standalone desktop app and CLI that lets developers orchestrate AI subagents across their workflow. Scaffold a backend, write tests, and manage deployments simultaneously, in a sandboxed environment with credential masking and hardened Git policies.

If you follow AI development tools, this is Google's answer to Claude Code. The architecture is nearly identical: agents that take on complex multi-step tasks, not just autocomplete. Two major AI companies independently building the same model tells you something. This is not a product experiment. This is where software development is going.

Android Studio went further. It added Agent Skills: modular instruction sets that ground the AI in your specific stack and architecture. Parallel conversation threads, so one agent writes documentation while another debugs test failures. And a Migration Agent that autonomously analyzes React Native or iOS codebases and does the heavy lifting to migrate them to native Kotlin.

For a technical founder running a small team, the development teams that adopt agentic workflows will ship faster and with fewer context switches. The developer who spends four hours on scaffolding before writing any real logic is at a structural disadvantage against a team running orchestrated agents. That gap will widen as the tooling matures.

Since Cursor started getting momentum, my job has shifted from software engineer to review engineer.

Generative UI changes the product iteration speed

Google AI Studio now lets you describe an app idea, generate production Jetpack Compose code, run it in an in-browser Android emulator, push to a physical device via ADB, and deploy to Google Play's internal test track in one flow. They also teased a mobile app version for prototyping on the go.

The competitive implication is not about you using this tool. It's that your competitors will. The cost of generating a functional-looking UI prototype just dropped to a text prompt. The time between "should we test this product idea" and "we have something running on a device" is now hours, not days.

Your competitive moat is no longer in the ability to build quickly. It is in the judgment to build the right thing. The founders who use faster prototyping loops to run more product experiments per month will learn faster. The ones who don't will make the same number of bets at a higher cost.

Nothing will beat Generative UI in mobile apps. Our mobile apps need AI not on top, but as a primary source of interaction. I started working on a React Native library for that — the amount of interest and traction is confirming it. Check it out: getwireai.com. An example of my usage: food recommendation onboarding.

What your users are about to start expecting

Google announced Gemini Spark: an always-on AI agent that breaks a user's biggest goals into actionable steps across their apps. Daily Brief: an agentic digest that pulls from Gmail, Calendar, and Drive into a single prioritized view. Gemini Omni: video creation and remixing on mobile, directly from a prompt.

These are consumer features, not developer tools. But they set the expectation floor for what a smart app does. A user with Gemini Spark helping them organize their week will notice, at some level, when your app doesn't do anything proactive for them. Not because they'll articulate it. Because your app will feel passive and static.

The pattern has a clear history. Apps that felt sophisticated in 2022 had smart push notifications. Apps that felt sophisticated in 2024 had AI chat. The 2026 pattern is agentic: apps that act on behalf of users instead of waiting for taps. You don't need to ship a full agent runtime today. But you need to identify at least one place in your app where proactive AI would replace friction, and plan for it.

The honest limitations

Hybrid Inference is Firebase-native. If your stack doesn't include Firebase, you get the pattern but build the routing logic yourself. It's doable. It's not zero work.

The generative UI tooling in AI Studio generates Jetpack Compose. There is no cross-platform output. Flutter and React Native developers are not the target for that specific feature. The concept travels; the tooling doesn't.

Gemini Nano on-device is an Android story for now. iOS developers are watching WWDC (early June) to see what Apple does with on-device AI APIs at the OS level. The Android-iOS capability gap on AI features has narrowed over the last 18 months, but it still exists.

What to do this week

Map your app's AI features against the on-device/cloud split. Summarization, input validation, short text generation: strong on-device candidates. Complex reasoning over a large context: still cloud. Hybrid Inference is the pattern whether or not you use Firebase.
If your team isn't running agentic development tools, spend one week on a real task with one. The goal isn't to evaluate the tool. It's to learn what changes about your workflow when the AI can orchestrate tasks instead of answering single questions.
Find one screen in your app where a proactive AI action would replace a user decision. That's your first agent feature candidate.

If you're building in React Native

The Firebase Hybrid Inference pattern is accessible via @react-native-firebase. If you want the on-device/cloud routing without pulling in Firebase, react-native-litert-lm via Nitro Modules handles the on-device leg (Phi-3 Mini, Moondream2) and any cloud API covers the fallback. The routing logic is around 40 lines of TypeScript and doesn't require a Firebase dependency.

Gemini Nano via ML Kit GenAI APIs will reach React Native through the @react-native-ml-kit binding path. Official timeline for Gemini Nano GenAI API support in that binding is [VERIFY: check Callstack or the ml-kit-rn repo]. Today, react-native-litert-lm covers the same on-device capability.

Antigravity 2.0 is worth watching as a comparison point to Claude Code, but it doesn't replace Claude Code for RN development. The Claude Code + UAMOS workflow already gives you subagent orchestration, memory banking across hot/warm/cold tiers, and sandboxed execution. If you're running that workflow, I/O 2026 confirmed you're on the right architecture.

Agent Skills in Android Studio map to the same pattern as Claude Code skills and the UAMOS memory bank: domain-specific instruction sets that ground the model in your specific codebase. If you haven't set this up for your RN project yet, that's the highest-leverage AI tooling investment you can make right now.

The generative UI announcement (Jetpack Compose generation in AI Studio) is Android-specific. For React Native, Wire RN is the equivalent component model: LLM outputs structured JSON, Wire RN renders native components. MIT licensed, 15-minute quickstart at getwireai.com.

FAQ

What did Google announce at I/O 2026 that matters for mobile app founders?

The highest-impact announcements for product decisions: Firebase Hybrid Inference (on-device Gemini Nano plus cloud fallback routing for Android and iOS), Gemini Nano in ML Kit GenAI APIs for on-device multimodal processing, and Gemini Spark as a consumer always-on AI agent. On the development side: Antigravity 2.0 for agentic coding workflows and Agent Skills in Android Studio.

What is Firebase Hybrid Inference and how does it work?

It routes AI tasks between on-device Gemini Nano and cloud processing at runtime, deciding based on network conditions, device capability, and cost. Available through Firebase AI Logic for Android and iOS apps. If your stack doesn't include Firebase, the routing pattern is replicable with any on-device model package and a cloud API.

What is Gemini Spark and what does it mean for my app?

Gemini Spark is an always-on AI agent that breaks user goals into actionable steps across apps. It represents a shift in user expectations: apps that proactively act on behalf of users rather than waiting for interaction. Not every app needs a full agent runtime, but every mobile product should now have a clear answer to where it will add proactive AI value.

What is Google Antigravity 2.0?

Google's standalone agent harness for development, co-optimized for Gemini 3.5 Flash. Developers orchestrate subagents to handle complex workflows simultaneously, in a sandboxed environment with credential masking and Git policy enforcement. It's structurally the same model as Claude Code's agentic development workflow.

Should I migrate my React Native app to Kotlin after the Android Studio Migration Agent?

Probably not as a primary initiative. The Migration Agent will get clean codebases a significant percentage of the way, but production apps with years of history still require substantial manual work after the automated pass. More relevant question: is your React Native app using the on-device AI capabilities that are available now?

I write Code Meet AI weekly on AI-first mobile development, with a focus on where AI and mobile products actually intersect. If you want the local-vs-cloud LLM decision framework I use for routing between on-device and cloud AI calls, subscribe and reply to the newsletter and I'll send it.

If you want to think out loud about your AI mobile stack, I run a Vibe Coding service at CasaInnov.

qwen2.5-coder is too slow for Claude Code on a Mac. Here's the fix.

Malik Chohra — Sat, 23 May 2026 14:55:49 +0000

Claude Code does not care where the model lives. Point it at a local model and it works with no network. I tested that at 35,000 feet, picked the wrong model first, and swapped mid-flight.

TL;DR

Claude Code reads two environment variables to decide where its model lives. Point them at Ollama and it runs fully offline.
I tested this on a real flight. Berlin, May 13, wifi off, cabin door closed.
I started on qwen2.5-coder:14b. It was too slow for anything agentic. One tool call sat for 25 seconds, the next for 52.
I switched to gemma4:26b. That one carried the session.
Local is for offline work, privacy-sensitive code, and cheap drafting. Cloud is still better for heavy reasoning and large-context tasks.
The install takes 20 minutes once. After that, switching models is one command.

The setup, in one paragraph

Ollama runs an open-weights model on your laptop. Claude Code points at Ollama instead of Anthropic's servers. No network call leaves the machine. The cloud account is irrelevant for that session. The only real decision is which local model you run, and that decision is where I got it wrong the first time.

Why offline beats "just use a smaller cloud model"

Before the setup, the three objections I get every time:

"Just don't code on a plane." A flight is six uninterrupted hours. No social media, no notifications, nothing that pulls focus. That is rare now. Throwing it away because your LLM needs wifi, when the wifi problem is fixable, is a planning failure.
"Just use Copilot offline." Copilot's local mode does completions. Anything context-heavy still hits the network. The moment you ask for the work that justifies an AI assistant, you are back online.
"Just use a smaller cloud model." Haiku and GPT-4o-mini still live in the cloud. Smaller is not local. No network, no inference. Same failure, smaller bill.

Local is the only setup that runs at 35,000 feet. It also runs on a train through a tunnel, in a cafe with broken wifi, and on the morning the OpenAI status page goes red. The flight is just the stress test.

What you need

A Mac on Apple Silicon (M1 or newer). Linux and Windows via WSL2 work with minor changes.
Claude Code installed and already authenticated against your cloud account.
About 16 GB of unified memory. 32 GB if you want the larger models comfortable.
Homebrew, for the Ollama install.
20 minutes the first time. Roughly 90 seconds every time after.

Step 1 — Pull the model before you fly

Install Ollama and pull a model:

brew install ollama
ollama pull qwen2.5-coder:14b

Do this on home wifi the night before. The pull is around 9 GB. Airport wifi and hotspots will not cooperate, and finding that out at the gate is its own small tragedy.

Confirm it landed:

ollama list

This was my mistake, so I will be blunt about it: I prepped qwen2.5-coder:14b because it is the model every "local LLM for coding" post recommends. Pull more than one. You will see why in Step 4.

Step 2 — Point Claude Code at Ollama

Start the Ollama server in one terminal:

ollama serve

Then in a new terminal, launch Claude Code against your local model:

ollama launch claude --model qwen2.5-coder:14b

Wrap that in two shell aliases so the rest of your workflow has named modes. Add these to ~/.zshrc:

alias claude-local='ollama launch claude --model gemma4:26b'
alias claude-cloud='claude'

Then source ~/.zshrc. That is the entire switching layer.

claude-local runs offline against Ollama. claude-cloud runs against the real Anthropic API. Two commands, one decision per session.

Step 3 — Verify on the ground

Prove the setup works in airplane mode before you board anything. This is non-negotiable. Discovering a missing step at altitude is bad theater with no exits.

Make sure ollama serve is running.
Turn wifi off. Actually off, not "disconnected from this network."
Run claude-local and point it at a real file.
Confirm a real answer comes back.

If it loads your project and answers with wifi off, it will work on the plane.

Step 4 — The flight: qwen2.5-coder was too slow

The best move I made was running the model without wifi on the ground first and measuring real performance. Every forum I read pointed at qwen2.5-coder. I trusted them. They were wrong for this job.

File reads were fine. Short explanations were fine. Then the model tried anything agentic, and the wait times stopped being a rounding error.

One tool call crunched for 25 seconds. An earlier step had sat at 52. For a single step in a loop that needs five or six of them, that is not a workflow. That is staring at a terminal while the person next to you finishes a movie.

qwen2.5-coder:14b is a fine model for single-shot edits. For the multi-step tool loop that Claude Code actually runs, on this hardware, it could not keep up. The model every post recommends was the wrong call for the job I had.

Step 5 — The swap: gemma4:26b carried the session

I had pulled a second model before the flight, exactly because I did not fully trust the first one. So I switched to gemma4:26b.

Bigger model, 17 GB on disk, and on this MacBook it was the difference between a demo and a tool. The tool loop ran at a speed I would actually choose. The gap analysis completed. Multi-step reasoning held together instead of stalling halfway.

Honest scorecard for the flight: roughly 70 percent of my normal Claude Code workflow worked on gemma4:26b. The 30 percent that did not was the heavy "go reason across the whole repo" pattern, which is cloud territory anyway. For six hours of focus on a known task, it was a real working setup, not a downgrade.

Because I already had a tight context-engineering setup with optimised token consumption, it ran smoothly. The Mac started lagging briefly when I had Xcode and Antigravity open alongside, but closing those and cleaning up Chrome tabs sorted it. If you want the context-engineering side, the U-AMOS write-up is here: I spent 6 months losing fights with AI in React Native. Then I built U-AMOS.

Practical tip: install the OneTab Chrome extension. Collapse open tabs into a list when you start a focus session. RAM frees up immediately and so does your attention. OneTab on the Chrome Web Store.

Which local model should you actually run?

The lesson from the flight changed my default. Here is the short list I keep now:

Devstral Small (24B) — built for agentic coding, multi-file edits, tool use. Currently the strongest open-source option on SWE-bench.
Qwen3-Coder (30B) — RL-trained on SWE-bench, native tool calling, large context. The successor to the model that failed me, and it is a real upgrade.
Gemma 4 (4B to 31B) — the best size-to-capability ratio. The 26b variant is what saved my flight.
Llama 3.3 (70B) — solid general coding and stable tool calling if your machine can carry it.

Notice what is not on that list: qwen2.5-coder. That is not an accident. Pick a model that is RL-trained for tool use, not just code completion. Claude Code lives or dies on the tool loop.

When to use local vs cloud

After running both for weeks, the rule is simple.

Reach for claude-local when:

There is no network. Planes, trains, dead cafes, conference wifi.
The code is privacy-sensitive. Client work under NDA, anything you do not want crossing a vendor boundary.
You are drafting and iterating prompts before spending cloud tokens on the real run. Local cost stays at zero.

Reach for claude-cloud when:

The work is multi-tool and agentic. Subagents, MCP calls, parallel reads.
The task needs large context. Whole-repo refactors, "explain this project."
The output ships to production. The polish gap between a local model and cloud Claude is real.

You do not pick once and live there. The aliases exist so you can switch inside a single session. Draft offline, land, run claude-cloud for the high-stakes execution.

Where this breaks

The honest section, because AI-generated tutorials never have one.

Tool use is the weak point. Even good local models are less reliable than cloud Claude at chaining many tool calls. Expect rough edges if your workflow leans hard on subagents and MCP servers.
Context windows are smaller. Sessions that try to load the entire repo will choke. Scope to the files in play, not the whole tree.
Battery drains faster. Running a 26B model while your editor and browser are open will eat the battery noticeably quicker than cloud Claude. Plan for it on a long offline session.
The endpoint shape is a soft contract. Ollama's responses are close to Anthropic's, not identical. Most coding requests work. If you hit a strange parsing error mid-stream, that mismatch is usually why, and claude-cloud is the fix in the moment.
Model versioning is your job now. Ollama makes pulling easy, but you decide when to upgrade and which variant. Keep a note of what you run and why.

Where to go next

This offline setup is one of three layers in a full AI-coding stack: cloud LLMs for heavy reasoning, local LLMs for offline and private work, and on-device LLMs for the mobile apps you ship to users. The on-device side for React Native is its own problem, covered in the Phi-3 Mini integration walkthrough. All three ship pre-wired in the AI Mobile Launcher AI Pro tier, so you are not assembling this from scratch.

I packaged the rest of this into the Local LLM with Claude Code bundle: the paste-ready zshrc aliases plus a claude-status helper, the Ollama config tuned for Apple Silicon, the model-picker matrix, and a pre-flight checklist so the setup is never a surprise at altitude. Reply to the Code Meet AI newsletter and I will send it.

FAQ

Can I run Claude itself locally?

No. Claude is closed-weight, so there is no local-runnable Claude. This setup uses Claude Code, the CLI, with an open-weights model like Gemma 4 or Devstral serving the inference. The CLI is the interface, the model is whatever endpoint you point it at.

What is the best local LLM for coding with Claude Code?

For the agentic tool loop Claude Code runs, pick a model RL-trained for tool use: Devstral Small, Qwen3-Coder, or Gemma 4. Avoid older completion-tuned models like qwen2.5-coder. They handle single edits fine but stall on multi-step work.

Does Claude Code airplane mode actually work with no signal?

Yes. With Claude Code pointed at local Ollama, no request leaves your laptop. I ran a full session at 35,000 feet with wifi off. The only requirement is pulling the model in advance.

Why Ollama and not LM Studio or llama.cpp?

Ollama wraps llama.cpp with a clean HTTP API on a known port. LM Studio works too but is GUI-first. Direct llama.cpp gives more control and more setup pain. Ollama is the path of least resistance for getting this running in under 30 minutes.

Will I get the same code quality as cloud Claude?

No. A good local model is excellent for syntax-level work: refactors, cleanup, rewriting a hook. For plan-heavy or reasoning-heavy tasks the gap is large. Use cloud for design, local for execution, or use local to draft and cloud to polish.

Malik Chohra — 9 yrs software, 7 in React Native. Building Wire RN, AI Mobile Launcher, and Code Meet AI.

AI didn't cause 2026's layoffs. History predicts more developers.

Malik Chohra — Thu, 14 May 2026 12:25:49 +0000

Andrew Ng is right: there is no AI jobpocalypse. The Jevons paradox, BLS projections, and CEO behavior all point the same direction.

TL;DR

Andrew Ng's call: software engineering hiring stays strong despite being the sector most affected by AI tools.
US BLS projects 15% software developer growth from 2024 to 2034, vs. 3% for all occupations. AI is cited as a demand driver.
Jevons paradox and Bessen's ATM-teller research show cheaper tools historically expand employment, not shrink it.
For builders: learn AI tools to compound your skills, then build distribution before it commoditizes.

Most 2026 tech layoffs framed as AI efficiency are not about AI replacing workers. They're a mix of post-COVID over-hire correction, slowing revenue growth, and the need to fund $700 billion in AI capital expenditure. Andrew Ng's argument that there is no AI jobpocalypse is supported by US Bureau of Labor Statistics projections of 15% growth in software developer employment through 2034. Historically, when a productive input gets cheaper, total consumption expands. That's the Jevons paradox, observed since 1865 and confirmed in ATMs, spreadsheets, and compilers. AI is making building cheaper. The lesson for developers: learn the new tools, then learn distribution.

I keep getting DMs from senior devs panicking about the layoffs. The memos all say AI. The framing all says "efficiency." Most of them are reading the memo wrong and acting on the wrong lesson.

A friend got laid off from a Series B last month. His memo cited "AI-driven productivity gains." He spent the next two weeks trying to ramp up on Claude Code at speed because he thought he was behind. The real reason his role got cut? His company missed its Q4 revenue target and the AI line read better in board decks than the slowdown line did.

The 2026 layoff story is the cleanest example I've seen of a press release winning over a spreadsheet.

What companies are saying vs. what their CEOs admit

Andy Jassy was unusually honest on Amazon's Q3 2025 earnings call. Asked about the largest layoff in Amazon's 31-year history, he said the cuts "were not really financially driven, and it's not even really AI-driven, not right now at least. It's culture."

Three months later, Beth Galetti's formal layoff memo at Amazon talked about reducing layers, increasing ownership, and removing bureaucracy. AI was not mentioned once. By spring 2026, the continued cuts (now 30,000 corporate roles since October 2025) had been absorbed into the broader industry narrative of AI-driven efficiency.

The CEO of the company doing the largest cuts said publicly it wasn't AI. The press and the market treated it as AI anyway.

The script is consistent across announcements. Meta cut 8,000 in April 2026 to "offset the other investments we're making." Block cut 4,000 with Jack Dorsey citing intelligence tools paired with smaller and flatter teams. Snap cut 16% citing rapid advancements in AI. Salesforce cut customer support from 9,000 to 5,000 with Marc Benioff saying AI agents handle 50% of interactions. Microsoft offered buyouts to 8,750 US employees.

Through April 2026, AI has been cited as a factor in 49,135 announced job cuts, per Challenger, Gray & Christmas. The narrative is dominant. The math doesn't support it.

Andrew Ng named the mechanism directly in his May 2026 Batch letter: "Businesses have a strong incentive to talk about layoffs as if they were caused by AI. Talking about how they're using AI to be far more productive with fewer staff makes them look smart. This is a better message than admitting they overhired during the pandemic when capital was abundant due to low interest rates and a massive government financial stimulus."

That sentence describes most of the layoffs of 2026.

The three things driving 2026's layoffs

Strip away the AI narrative and three things are happening at once across the companies announcing the largest cuts.

COVID over-hiring is still being unwound

Amazon hired aggressively from 2019 to 2022, growing global headcount from 798,000 to 1.6 million. Meta doubled. Microsoft, Google, Salesforce all hired into pandemic-era demand assumptions that didn't survive 2023.

Block expanded headcount aggressively through 2021 to 2023, building parallel teams across Square and Cash App. The 40% cut Dorsey announced in February 2026 is mostly Block returning to roughly its 2020 size. The "AI-native, flatter teams" language is the public-facing wrapper around what is, structurally, a duplicate-org cleanup.

Marc Andreessen, hardly a layoff skeptic, attributed recent cuts to "higher interest rates and a complete loss of discipline in hiring during the pandemic. The hiring binge that companies went on in COVID was just wild." This is the same Marc Andreessen whose firm is one of the loudest voices on AI replacing work. Even he won't credit AI for the current wave.

"We over-hired" is a flat story. "AI made us more efficient" is a forward-looking transformation story. Same cuts, different press release.

Revenue is slowing and Chinese competition is squeezing margins

Some of the most aggressive layoffs aren't at hyperscalers building data centers. They're at companies losing market share or facing structural revenue pressure.

PayPal's cuts followed slowing revenue growth, stalled active-user counts, and competition from Stripe, Apple, Visa, and Mastercard. Coinbase rode the 2021 crypto boom, cut during the 2022 winter, rehired into the next cycle, then framed 2026 cuts around "AI-native teams." The underlying driver is the volatility of crypto demand, not a productivity unlock.

Chegg cut 45% of its workforce in October 2025 because students stopped using it. They use ChatGPT instead. That is a real AI-driven layoff, but in the inverse sense: AI killed the product, not the headcount of an "efficient" company.

The macro backdrop matters. US GDP grew just 0.5% in Q4 2025 before rebounding to 2.0% in Q1 2026. The Conference Board's Leading Economic Index declined 0.6% in March 2026. The Challenger, Gray & Christmas tracker tells the cleanest version of the story: the most-cited reason for 2026 layoffs is "market and economic conditions" at 53,058 cuts, more than double the AI count of 21,490 in the same period.

Then there's China. DeepSeek V4 Pro is priced at $1.74 / $3.48 per million input/output tokens. Claude Opus 4.7 sits at $5 / $25. GPT-5.5 at $5 / $30. RAND research puts Chinese model costs at one-sixth to one-fourth of comparable US systems. When the cost of your most strategic capability is being undercut 4 to 6 times by an open-source competitor, you cut headcount somewhere. You don't blame DeepSeek in your layoff memo. You say "AI efficiency."

AI capex is eating the room

This is the story most companies don't want to tell directly: they need to fund $700 billion of capex, and headcount is the easiest line to cut.

The four largest hyperscalers (Amazon, Microsoft, Alphabet, Meta) are projected to spend $725 billion on capex in 2026, up 77% year over year. Roughly 75% is AI-specific. Capital intensity at hyperscalers is now 45 to 57% of revenue, ratios that look like utility companies, not software companies.

Meta is the cleanest case. The company is planning $125 to $145 billion in 2026 capex, per the January 29 earnings call. The 8,000 layoffs free roughly $2.4 billion in annual run-rate operating expense. That is 1.7% of the capex bill. Even fully replacing the workforce with AI would save about $27 billion, a fraction of the $145 billion infrastructure spend.

Meta's Q1 2026 still printed $56.3 billion in revenue (up 33% year over year), 41% operating margins, and $10.44 EPS. This is not a company in distress. The cuts aren't about AI productivity. They're about creating room on the income statement for a capex bill growing roughly twice as fast as revenue.

Larry Page reportedly told colleagues: "I'm willing to go bankrupt rather than lose this race." That is the actual posture inside hyperscalers. The AI-framed layoffs are the public face of that posture.

There's a fourth incentive Ng called out that's worth reading directly. AI companies anchor their pricing to salaries rather than SaaS norms. A SaaS tool charges $100 to $1,000 per user per year. If an AI tool can replace a $100,000 employee or make them 50% more productive, charging $10,000 looks reasonable. By anchoring to salaries, AI vendors capture much more revenue than traditional SaaS pricing would allow. That commercial logic depends on the layoff narrative being true. The incentive to keep the narrative alive is direct and financial.

Is software engineering finished? History says cheaper tools grow employment

In 1865, British economist William Stanley Jevons noticed something counterintuitive about coal. As steam engines became more efficient, total coal consumption rose instead of falling. Cheaper coal per unit of output made coal-powered production viable in more industries, expanding total demand faster than efficiency reduced it. He called this the paradox of efficiency. Microsoft CEO Satya Nadella invoked it explicitly when DeepSeek's pricing hit the markets in early 2025.

The textbook case in employment economics is bank tellers and ATMs. From 1988 to 2004, ATMs cut the number of tellers needed per US bank branch from 20 to 13. The intuitive prediction was teller employment would collapse. It didn't. Cheaper branch operations let banks open 43% more branches in urban areas. Total teller employment rose. Economist James Bessen documented this for the IMF in 2015, and the pattern has become the standard reference for thinking about automation and jobs.

The same pattern shows up with spreadsheets, where the prediction was that VisiCalc would kill accountants. The reality: financial analyst jobs grew because cheaper analysis made more analysis worth doing. With compilers, where assembly programmers were supposed to be displaced. The reality: total developer count grew by orders of magnitude because cheaper code made more code worth writing. With electrification, where the same panic played out across factory work.

The mechanism is consistent. When a productive input gets cheaper, the supply of work that input can support expands faster than the input becomes redundant. People build things that weren't worth building when the input cost was higher.

The US Bureau of Labor Statistics, working from the assumption that AI will accelerate over the next decade, projects software developer employment to grow 15% from 2024 to 2034, against 3% for all US occupations. Their report names AI explicitly as a demand driver: "Demand for software developers, software quality assurance analysts, and testers is projected to be strong due to the continued expansion of software development for artificial intelligence, Internet of Things, robotics, and other automation applications." About 129,200 openings are projected per year over the decade.

There's a Jevons split inside the BLS data worth noticing. The narrow category "computer programmers" (repetitive coding work) is projected to decline 6%, with the explicit reason being "computer programming work continues to be automated." The broad category "software developers" (designing, integrating, shipping software) grows 15%. The narrow, repetitive task gets automated. The broader role expands. This is exactly the pattern Bessen described for tellers in 1988.

Andrew Ng's Batch letter argues the same point at a higher level. Software engineering is the sector most affected by AI tools. Hiring remains strong. US unemployment is 4.3%. His prediction is what he calls an "AI jobapalooza": more good AI engineering jobs, in companies that aren't traditionally software employers, with skill mixes that look different from 2018.

Why this time could still be different

This time might be different. Three reasons to take seriously.

First, speed. The ATM-to-teller transition played out over forty years. AI's transition into coding has taken about three years. Even if the long-run equilibrium is more developers, the transition is happening on a timeline that gives workers little room to retrain.

Second, completeness of automation. Bessen's bank teller story has a sequel most quotations miss. Teller employment did eventually decline, not from ATMs, but from mobile banking after 2010. When automation went from partial (ATMs handled some tasks) to nearly complete (mobile banking handled them all), the Jevons effect stopped protecting jobs. The question is whether AI's coding capability will graduate from partial automation (helps engineers be faster) to complete automation (does the job end-to-end). Today it's clearly partial. The question is for how long.

Third, the macro data isn't yet showing the productivity boom that would generate Jevons-style demand expansion. Torsten Slok, chief economist at Apollo, summarized this in a phrase that's now widely quoted: "AI is everywhere except in the incoming macroeconomic data." Stanford's "Canaries in the Coal Mine" study from November 2025 found employment declining for workers whose jobs may be affected by AI. The specific roles named were software developers and customer-service representatives. These are exactly the roles Jevons should be protecting.

So the long-run pattern says Jevons holds. The short-run data is mixed. Builders should adapt now rather than wait to find out which way the next five years go.

What this means for developers in 2026

Here is where most takes on these layoffs go wrong.

The instinct, especially for engineers, is to read the layoff memos at face value: "AI is taking our jobs. Better get good at AI fast." Half of that is wrong. Half is right.

Half is wrong. AI is not currently replacing software engineers at scale. The cuts aren't because AI engineers write 10x more code. They're because companies over-hired, growth is slowing, and someone needs to absorb $700 billion in capex.

Half is right. AI is making building cheaper. Not because it replaces engineers, but because it compresses the time from idea to working prototype. I can spin up a working React Native app with auth, theming, i18n, and Redux Toolkit using my own expo_boilerplate plus Claude Code in an afternoon. Two years ago that was a weekend. Five years ago it was a small team's first sprint.

The Jevons reading: cheaper building means more total building. That expands demand for the work AI can't yet do well: system design, integration, debugging, judgment calls, shipping, and getting users.

The bottleneck has moved. Building used to be the moat. The number of people who can ship a working product has exploded. The cost of building has collapsed. Distribution didn't get cheaper. Attention didn't get cheaper. Trust didn't get cheaper. The audience you spent five years building is still worth what it was worth in 2020. The newsletter with 10,000 engaged readers is still rare.

This is the inversion that matters more for your career than any layoff announcement. The work didn't get harder. It shifted. The skill stack that paid in 2018 (deep technical specialization) pays less now. The skill stack that pays in 2026 is technical work plus distribution work.

What to learn this week: AI tools and distribution

If I were starting over today as a senior engineer reading the layoff news, this is what I'd learn first, in this order.

Use AI as a builder, not a topic to study

Stop reading about AI and start using it. Pick one workflow you do every week and rebuild it with Claude Code or Cursor. Measure the time saved. Notice where it breaks. The point is not to become an "AI engineer." The point is to compound your existing skill stack with tools that make you 3 to 5 times faster on the boring parts.

Ship one real thing per month

Not a tutorial project. A real thing you put online with your name on it. The boilerplate I open-sourced on GitHub was a forcing function for me: every time I built a CasaInnov client project, I extracted the reusable parts and pushed them back. Two years of that is now a credible authority signal anyone can clone.

Pick one distribution channel and commit publicly

Newsletter, LinkedIn, Twitter, YouTube, Reddit, GitHub. Pick one. Get good at it. The cost of building a 5,000-person audience in your niche is one consistent post per week for two years. That sounds boring. It is boring. It also outperforms 95% of what your peers are doing.

Write what you wish someone had written for you

I started Code Meet AI because I kept losing days to integration problems nobody had documented well. Hermes failing on cold start after Expo SDK upgrades. Claude Code hallucinating React Native imports that don't exist. Generative UI patterns that work on web but break on mobile. The writing is now its own moat.

The combination of these four habits is, in my opinion, more resilient than any specific technical skill. Skills depreciate. A distribution channel and a track record of shipping compound.

If you want a head start, my expo_boilerplate is MIT-licensed and built for exactly this: TypeScript, auth, theming, i18n, Redux Toolkit, feature-first architecture, Cursor and Claude rules already wired in. Clone it, change three things, ship something this weekend.

The 2026 layoffs are not the signal most people are reading them as. The current cuts are about COVID over-hire correction, slowing growth, and AI capex pressure. The economics history says cheaper tools grow employment, not shrink it. Andrew Ng calls it an AI jobapalooza. The Bureau of Labor Statistics is projecting 15% growth.

The work shifted. Adapt to where it went.

FAQ

Will AI replace software engineers?

Probably not net replace, based on Bureau of Labor Statistics data and historical precedent. BLS projects 15% growth in software developer employment from 2024 to 2034, with AI explicitly named as a demand driver. The Jevons paradox, cheaper inputs expand total consumption, has held for two centuries across electrification, spreadsheets, and ATMs. The transition may displace specific narrow roles (BLS projects "computer programmers" to decline 6%) while expanding the broader category of software work.

What did Andrew Ng say about AI and jobs?

In his May 2026 Batch letter, Ng predicted there will be no AI jobpocalypse. His evidence: software engineering hiring remains strong despite being the sector most affected by AI tools, and US unemployment sits at 4.3%. He attributes the panic narrative to AI labs wanting to sound powerful, AI companies anchoring pricing to salaries rather than typical SaaS norms, and businesses preferring "AI efficiency" to admitting they over-hired during the pandemic stimulus era. He predicts an "AI jobapalooza" instead.

What is the Jevons paradox and why does it matter for developers?

Jevons paradox is the 1865 observation that when a resource gets used more efficiently, total consumption of that resource often rises rather than falls. Applied to software: AI making coding cheaper doesn't necessarily reduce demand for code. It expands what's worth building. The bank teller case is the canonical example. ATMs cut tellers per branch from 20 to 13, but banks opened 43% more branches, so total teller employment grew. The pattern holds until automation gets complete enough to handle the whole job, which AI hasn't yet for software.

Should I learn AI to avoid being laid off?

Yes, but not because AI is taking your job. Because AI tools make you 3 to 5 times faster on boring parts of the work, which is now table stakes for senior engineers. The bigger lever is distribution. AI commoditized building. Distribution didn't get cheaper. A small audience and a track record of shipping are now more durable than any specific technical specialization.

Where do I start this week?

Three concrete moves. Audit your AI tooling (set up Claude Code or Cursor with project rules and verification gates). Pick one distribution channel and schedule three posts. Ship one open-source artifact with your name on it. The combination compounds faster than any individual technical certification.

I write Code Meet AI, a weekly newsletter for engineers shipping AI features in production. No hype, no thought-leader cadence. Real builds, honest takes, what's working in mobile-AI right now.

The boilerplate is at

chohra-med / expo_boilerplate

AI-first React Native + Expo boilerplate. Feature-first architecture, TypeScript, auth, i18n, theming, Redux Toolkit — with Cursor/Claude rules included. Lite version of AI Mobile Launcher.

MobileLauncher — React Native Boilerplate

The React Native foundation I use on every production project — open-sourced.

Feature-first architecture, TypeScript strict, auth, i18n, theming, Redux Toolkit, and Expo SDK 54 with the New Architecture. Structured so Cursor, Claude Code, and Antigravity generate consistent code without hallucinating your patterns.

Want the full version? RevenueCat, Firebase, U-AMOS 2.0 memory bank, and AI Pro features are in the paid tier.
→ AI Mobile Launcher — aimobilelauncher.com

Why this boilerplate?

Most React Native starters give you a blank canvas. That's fine for a side project — it's a liability on production work or when you're using AI coding tools.

After 7 years of shipping React Native apps — enterprise clients, health tech, coaching platforms — I kept rebuilding the same foundation from scratch. Authentication, onboarding, theming, i18n, state management, folder structure, TypeScript config. Every time.

This is that foundation, extracted and open-sourced.

Three reasons…

View on GitHub

MIT-licensed. Clone, fork, ship.

How I wire Claude into my React Native workflow (skills, projects, Cowork)

Malik Chohra — Wed, 13 May 2026 08:01:35 +0000

Claude isn't a chat app anymore. It's a runtime. The interface is still text, but the architecture underneath is execution: load context, pick tools, call APIs, write files, schedule work. Most people are still typing at it like ChatGPT in 2023 and wondering why their workflow hasn't changed.

The shift happened quietly, across four primitives. Each one shipped without much fanfare. Together they're what "advanced" means in 2026: not a longer prompt, but a better-wired one.

This piece is the primer. The four things to understand before you can use Claude well.

The mental model

The outdated framing: Claude is good at writing, explaining, coding.

The 2026 framing: Claude is a runtime that loads skills, scopes memory in projects, calls external systems through MCP, and executes multi-step work in Cowork.

Same model file, completely different surface. The question used to be "what can Claude do?" The question now is "what can I wire into Claude?"

That reframe is the whole article. Everything below is the four primitives that make the reframe real.

1/ Skills (the tool layer)

A skill is a folder with a SKILL.md file. YAML frontmatter at the top with name and description. Markdown body underneath with the instructions Claude follows. That's the entire format.

The mechanism is the part most people miss. The description is what Claude sees in its skill list before responding. The body only loads when the skill triggers. So you can have 50 skills sitting available and pay context cost on only the one that fires.

This changes what you'd put in a skill. A skill isn't a system prompt by another name. It's a tool you teach Claude once and reach for whenever the task fits.

Things skills are good at:

Domain procedures: how your team does code review, how your brand voice works, what your component library calls things
Multi-step workflows: write article → format for Medium → cross-post to Dev.to → generate carousel
Technical conventions: your API's auth quirks, your codebase's folder structure, your testing harness

Two patterns I've seen work in production.

A context skill holds your domain knowledge once. Other skills reference it. Don't repeat your brand voice in every generator. Keep it in a *-context skill and have the generators read it.

A generator skill does one job. It writes a thing, or transforms a thing, or validates a thing. Single-purpose, composable, chains cleanly.

The mistake is making one giant skill that does everything. Anthropic's own open-source skills repo has separate pdf, docx, xlsx, and pptx skills, not one mega "documents" skill, for a reason. Generators that do too much fail in too many ways and get triggered by too many prompts.

The other thing nobody tells you: the description is the trigger. I spent two weeks getting one of my skills to fire when I asked for the right thing. The body was fine. The description was vague. Claude under-triggers skills by default, and Anthropic's own guidance is to be slightly pushy in descriptions. Specific verbs, specific phrases, specific contexts.

Custom skills are available on Pro, Max, Team, and Enterprise. You can create them directly in Claude.ai (Settings → Capabilities), via the API, or as folders in Claude Code.

2/ Projects (scoped memory)

A Project is a workspace with its own files, instructions, and memory. Memory accumulated in one project doesn't bleed into another. Same Claude account, effectively different "instances" of context.

Why it matters: chat memory was useful but contaminating. A single global memory pool meant Claude pulled context from a personal conversation into a work answer, or surfaced last week's product strategy when you asked about something unrelated. Project-scoped memory fixes that without forcing you to start cold every session.

What to use it for:

One project per product or work stream, to keep the contexts clean
Long-running threads where context compounds (research projects, ongoing client engagements, multi-week investigations)
Anywhere you want Claude to remember but not leak

The pattern: every project gets its own files (a PRD, a brand voice doc, a technical spec) and its own memory. The skills you've installed are still available across all projects, but the context is scoped.

A consequence worth noticing. If you're not using Projects, your default chat is becoming a leaky bucket. Memory accumulates. Some of it conflicts. After three months it's a soup. Projects are how you stop that.

3/ Connectors (the integration layer over MCP)

Connectors are Model Context Protocol-based integrations that let Claude read from and write to external services. Google Drive, Gmail, Notion, GitHub, Slack, Linear, Asana, Jira, Stripe, Figma, Canva, HubSpot, Apple Health. 50+ in the directory as of early 2026, with new ones added weekly.

Why they matter: pasting screenshots and copy-pasting JSON is the manual work AI was supposed to remove. Connectors remove it. Instead of "here's the email I got," it's "the email from Sarah yesterday." Claude pulls it. Instead of pasting an issue body, it's "the bug filed in expo_boilerplate." Claude pulls it.

When to use them:

Tools already in your daily workflow. Connectors only earn their place if they're already part of how you work.
Workflows that span tools (calendar + email + Slack = daily briefing)
Anywhere you find yourself screenshot-pasting more than twice in one session

The custom MCP escape hatch (Pro plan and above): if your tool isn't in the directory, you can add any MCP server URL via Settings → Connectors → Add custom connector. Notion's hosted MCP at https://mcp.notion.com/mcp is the canonical example. Anyone publishing an MCP server can be wired into Claude in 30 seconds.

The trap is over-connecting. Each connector adds surface area for Claude to get confused. Multiple integrations claiming to handle "messages" or "tasks" leads to wrong-tool-picked failures. The honest take: pick three to five that match your real flow. Connect more only when you hit a specific gap.

4/ Cowork (the agentic execution layer)

Cowork is the same agentic architecture as Claude Code, but for non-coding tasks, in the desktop app. (If you haven't installed Claude Code yet, the Claude Code for beginners guide on the Code Meet AI newsletter walks through the install and your first project.) It reads and writes local files, schedules recurring tasks, and uses connectors first, the browser second, and computer use (driving your screen) only as a last resort. Available on Pro, Max, Team, and Enterprise. Desktop only.

This is where Claude shifts from assistant to colleague. You give it a goal, walk away, come back to a result. The desktop has to be awake while it runs. That's the catch.

What Cowork is good at:

Repetitive multi-step work like file organization, daily briefings, weekly reviews
Tasks that span tools and need orchestration (calendar + email + Slack synthesis)
Work that's too boring to do reliably but too important to skip

What it's not for:

Time-sensitive tasks. Your desktop has to be open and awake.
Sensitive data (financial, health, anything regulated). Prompt injection risk is real, and Cowork activity isn't covered by ZDR.
Work where you want to think alongside Claude. That's chat. Cowork is delegation.

The realest test: if you'd skip the task because it's boring, Cowork is the right tool. If you'd want to watch Claude do it step by step, chat is.

The multiplier: Dispatch + Computer Use

Two extensions on Cowork worth knowing about, because together they're what makes the rest worth setting up.

Computer Use lets Claude drive your screen. Clicking, typing, navigating apps that don't have connectors. Slower than a connector. More fragile. But it works for the long tail of tools that haven't published an MCP server. Research preview on Pro and Max.

Dispatch lets you assign tasks from your mobile app to your desktop. You're on the train; you tell Claude on your phone to summarize three articles you drafted this week. By the time you're at your desk, the answer is in chat.

Both are research previews as of May 2026. Both work. Use sparingly until they harden, but understand they exist. They're the difference between Claude as a desktop tool and Claude as something you can hand work to from anywhere.

What this means for builders

For mobile builders specifically, the implications are sharper than they look from the outside. The web AI dev community has been on this trajectory longer (Cursor, Claude Code in CLI, MCP servers for every database, custom skills for every framework). Mobile dev has stayed a step behind partly because the canonical workflows assume backend or web context.

Skills, Projects, and Connectors don't care what stack you ship to. The runtime is platform-agnostic. The gain compounds the moment you treat Claude as something to wire, not something to type at.

The honest version: most "I'm not getting much out of AI" complaints I hear from devs in 2026 trace to one of three things. They're still on the chat surface. They haven't built a single skill. Or they're treating connectors like a novelty. None of those are model problems. They're setup problems.

Where to start

Pick one primitive, build something, ship it. Add the next one when the simpler setup hits a wall.

For most people, the order is:

One Project per major work stream. Stop polluting the default chat.
One custom skill for your domain context. Brand voice, codebase conventions, whatever your work depends on.
Three connectors. The ones already in your daily flow. Not ten.
One Cowork recurring task. A morning briefing is a good first one.

Stop there for a month. Notice what's still manual. Build the next thing for that.

The advanced version of Claude isn't a longer prompt. It's the four primitives, wired into how you really work. You're writing code now. It just happens to look like English.

If you're shipping mobile-AI

The four primitives apply to every stack, but the wiring for React Native and Expo is its own problem. Web AI dev has a year head start on patterns; mobile is still figuring out what a Claude Code memory bank looks like for a Metro bundler, what skills make sense for an Expo build pipeline, and which connectors actually plug into a mobile workflow.

That's the gap AI Mobile Launcher fills. It ships the U-AMOS memory system, RN-specific Claude Code rules, and the Skills folder structure pre-configured for Expo and the mobile stack, so you're not figuring out the wiring on a Tuesday night with a build failure on the line.

The Lite version is free on GitHub. The full system with the rule packs, generators, and U-AMOS 2.0 memory bank is in the Starter tier.

→ Get AI Mobile Launcher

Malik Chohra · AI-first mobile engineer · WireAI · AI Mobile Launcher · Code Meet AI newsletter

From React to React Native: what web devs get wrong on day one

Malik Chohra — Thu, 07 May 2026 19:46:01 +0000

I built three React Native apps before I really understood it.

The first took me three weeks to ship something that should have taken three days. The second, I shipped fast by ignoring half the platform constraints and paying for it later. The third was the boilerplate I wish I'd had on day one.

This was by 2019, when React Native was new, and I always thought that jumping from React Native to ReactJS for websites would be smooth. Actually, it was.

Since then, i saw so many Web developers, they jump into mobile apps, and it is not the same. So much dependency to manage, just to think about the performance, it is a whole new topic, or to manage packages. Here, we are not talking about Native integration or creating native code from scratch. There is so many mistakes when it comes to that, and i will try to simplify life for you.

If you're a React developer planning to build a mobile app, this is the piece I'd hand you on day zero. What actually transfers from the web? What absolutely doesn't. Where Expo fits in. What to learn first? What to skip. And, because most "React to React Native" guides are written like AI is still 2022, what shipping AI features inside a mobile app actually looks like.

"It's just React, right?"

Yes, it's JSX. Yes, it's hooks. Yes, your component model carries over. That's about a third of what makes up "shipping a working app."

The other things are layout, navigation, storage, build, debugging, and deployment, which are different enough that pretending they aren't is the single biggest reason web devs give up on RN in week two.

So let me split it cleanly.

What transfers from React (the good news)

If you've shipped React on the web, these all carry over more or less untouched:

JSX and the component model. Same mental model. <MyComponent prop={value} /> is <MyComponent prop={value} />.
Hooks. useState, useEffect, useMemo, useCallback, useReducer, useContext, custom hooks all work the same.
TypeScript. Same setup, same tsconfig.json (almost). Expo gives you a working TS template by default.
State management. Zustand, Redux, Jotai. All work in RN. TanStack Query works. (If you're choosing between them, I broke down the trade-offs in Redux vs Zustand vs MobX in React Native.)
Most utility libraries. zod, date-fns, lodash, dayjs, uuid, all fine. Anything with no DOM dependency.
Patterns. Composition, lifting state up, container/presentational, render props if you're into that. All the same.

That's the part that lulls you into thinking "this is going to be smooth."

What doesn't transfer (the painful part)

Here's where week two starts.

No DOM elements. <div> doesn't exist. Neither does <span>, <button>, or <input>. You get <View>, <Text>, <Pressable>, <TextInput>. And every piece of text on the screen has to be inside a <Text> putting a string, directly in a <View> crashes the app at runtime. And by the way, if you use lazy loading for screens, and you don't check that screen, the deployment will crash heavily, as the deployment pipeline is so different. Well, you can use Over The Air update (OTA), but…

No CSS. No stylesheets, no media queries, no cascading, no :hover (there's no hover on mobile). You write style objects in JS, or you use a Tailwind equivalent like NativeWind, which I strongly recommend keeping you on familiar ground.

No React Router. Use Expo Router. It's file-based, feels closest to Next.js's app router, and is now the default for new Expo projects.

No browser APIs. No localStorage, no window, no document. You'll use AsyncStorage (or MMKV for performance), and react-native-reanimated for anything animated. There's no <a href>. There's no scroll event the same way. There's no getElementById.

Forms work differently. <TextInput> doesn't auto-handle the keyboard. You manage focus, dismissal, keyboard-avoiding behavior, autocorrect, and autocapitalize. Keyboard handling on mobile is a small engineering problem in itself.

Images load asynchronously. You don't <img src=...> and forget. You think about caching, placeholders, error states, and image sizes. expo-image handles most of this.

Animations are different. CSS transitions don't exist. Reanimated library is the standard, and it runs animations on the UI thread (separate from your JS), which is actually better than the web, but you have to learn worklets. The idea is we have JS and UI threads in React Native. Animation should run on UI threads to keep the app performance. (For high-performance graphics specifically, RN Skia is worth knowing too.)

Build and deploy aren't Vercel. No git push and you're live. You use EAS Build for cloud builds, EAS Submit to push to the App Store and Play Store, and you wait for app review. EAS Update lets you ship JS-only patches over the air without going through review again. That's the closest thing to "deploy on push."

Debugging is different. Flipper is deprecated. React Native DevTools is the new standard, and it's actually decent now. But native crashes (the kind that surface as a stack trace from Java or Objective-C) require different muscle memory.

That's the surface area you didn't know you didn't know.

Expo vs bare React Native

This is the first real fork in the road.

Bare React Native means you have a native iOS project and a native Android project sitting next to your JS code. You can install any native module, customize anything, and you'll probably spend Saturday afternoons fighting CocoaPods, Gradle, and Xcode signing certificates.

Expo (managed) means you write JS only, install Expo-compatible native modules, and let EAS handle native builds in the cloud. You get OTA updates, a working dev client, and you're shipping to TestFlight in a day instead of a week.

If you're a web developer starting out: use Expo. Don't believe people who tell you it's "for prototypes." It's not 2020 anymore. Expo's ecosystem covers nearly everything you'll actually need (camera, notifications, biometrics, in-app purchases, deep linking, file system). The workflow management in Expo is the best for RN right now.

I tried the bare RN route on app two. I lost a weekend to an Xcode signing error that turned out to be a typo in app.json. I went back to Expo for app three and have not looked back.

What to learn first (the priority list)

If you have one week to come up to speed before starting, here's the order:

Expo Router. File-based routing, layouts, and dynamic routes. Read the Expo Router docs, they're short.
NativeWind. Tailwind for RN. Lets you keep your CSS muscle memory and skip writing StyleSheet.create({ ... }) for every component.
The core RN primitives. View, Text, Pressable, ScrollView, FlatList, TextInput, Image. Know what each is for and when to use which.
AsyncStorage (or MMKV). Your localStorage replacement. MMKV is faster but adds native code; AsyncStorage is fine for most cases.
Reanimated basics. useSharedValue, useAnimatedStyle, withTiming, withSpring. You don't need to master worklets on day one, but you do need this for any real interaction.
EAS Build and EAS Update. Your build and deploy story. Ten minutes of reading saves you hours.

That's enough to ship a real app. Everything else, learn when you need it.

What to avoid (the trap list)

These are the things that cost me time. Don't repeat them.

Don't try to make React Router work. Expo Router exists. Use it. I still use React Navigation for my projects, as I'm more familiar with. Expo Router now is king.
Don't write StyleSheet.create from scratch when NativeWind solves it for you. You'll be slower, your code will read worse, and you'll resist refactoring. You can have a design system library and use it. Faster and easier.
Don't disable Hermes. It's the default RN engine now: faster startup, smaller bundle, better debugging. You shouldn't need to touch this.
Don't use setInterval for animations. Use Reanimated. The frame drops will tell you why.
Don't ignore the keyboard. Test every screen with the keyboard open. KeyboardAvoidingView is the minimum; react-native-keyboard-controller is what I actually use in production now.
Don't ship without offline handling. Phones lose signal in elevators, on planes, on the subway. Check NetInfo and have a fallback. If you want a deeper pattern, I wrote about offline support and caching in Expo with custom queuing.
Don't assume iOS and Android behave the same. Safe-area insets, permissions UX, file system paths, system gestures, they diverge in places that matter. Test both.
Don't ship API keys in your app. This is the single biggest mistake I see web devs make moving over. Your .env ships in your bundle. Anyone can decompile it. You need a backend proxy for any third-party API call that requires a secret key. I wrote a longer piece on secure storage patterns in Expo that covers what to do with the secrets you do need on-device.

That last one matters more than ever now, because of the AI part.

The AI part nobody talks about

If you're building a mobile app today and there's no AI feature on your roadmap, you're either underestimating where the market is or you have a very specific reason. Most web devs come into RN with an LLM feature already on the spec.

Here's the honest version of what changes when you ship AI inside a mobile app.

Streaming LLM responses without dropping frames. On the web, you stream tokens into a <div> and let the browser paint. On mobile, your JS thread renders into a <Text>, and if you re-render too aggressively you drop frames. The pattern is to batch tokens before pushing them into React state, not to call setState for every chunk that comes off the stream.

API key management. I said it above and I'll say it again, because this is where most first-AI-mobile-app projects ship something insecure. You cannot put your OpenAI / Anthropic / whoever-else API key in your app. It will be extracted within minutes if anyone cares. You need a backend proxy, even a tiny one. A Cloudflare Worker or a Vercel function fronting the AI provider, with rate limiting per device, is the minimum.

Generative UI on mobile. This is the gap. On the web, Tambo and Vercel AI SDK UI let you have an LLM render React components on the fly. On mobile, there's nothing equivalent that's stable yet. (Aside: I'm building one, open source. More on that another time.)

On-device inference is possible, barely. llama.rn, Core ML, MLKit can run small models locally for specific use cases (transcription, classification, simple chat). But for anything resembling Claude or GPT-4 quality, you're still calling an API. Plan for that.

Here's a representative snippet, a streaming chat hook the way I'd write it for a mobile app, with the buffer pattern that keeps frames smooth:

// useStreamingChat.ts: pattern from the AI Mobile Launcher boilerplate
// Note: streaming fetch in RN needs expo/fetch (Expo SDK 52+) or a polyfill.
import { useState, useRef, useCallback } from 'react';
import { fetch as expoFetch } from 'expo/fetch';

type Message = { role: 'user' | 'assistant'; content: string };

export function useStreamingChat(apiUrl: string) {
  const [messages, setMessages] = useState<Message[]>([]);
  const bufferRef = useRef('');
  const flushTimerRef = useRef<NodeJS.Timeout | null>(null);

  const flush = useCallback(() => {
    if (!bufferRef.current) return;
    const chunk = bufferRef.current;
    bufferRef.current = '';
    setMessages((prev) => {
      const last = prev[prev.length - 1];
      if (last?.role !== 'assistant') return prev;
      return [
        ...prev.slice(0, -1),
        { ...last, content: last.content + chunk },
      ];
    });
  }, []);

  const send = useCallback(
    async (input: string) => {
      setMessages((prev) => [
        ...prev,
        { role: 'user', content: input },
        { role: 'assistant', content: '' },
      ]);

      // Hit your backend proxy. Never the AI API directly from the device.
      const res = await expoFetch(`${apiUrl}/chat`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ input }),
      });

      const reader = res.body!.getReader();
      const decoder = new TextDecoder();

      while (true) {
        const { value, done } = await reader.read();
        if (done) break;
        bufferRef.current += decoder.decode(value);
        // Batch UI updates at ~60fps instead of every token.
        if (!flushTimerRef.current) {
          flushTimerRef.current = setTimeout(() => {
            flush();
            flushTimerRef.current = null;
          }, 16);
        }
      }
      flush();
    },
    [apiUrl, flush]
  );

  return { messages, send };
}

That pattern alone, buffering tokens and flushing at ~60fps instead of on every chunk, fixes most of the dropped-frames issues new RN devs hit when they first try streaming.

The shortcut

If you're at day zero with React Native and you want to ship an AI-powered mobile app, here's the boring truth: the first two weeks are setup. Routing, styling system, secure API proxy, streaming UI, auth, EAS pipeline, build configs, app icons, splash screens. You'll do all of this before you write your first feature.

I built AI Mobile Launcher because I'd done that two-week setup three times in a row. It's an Expo + React Native boilerplate with:

React Navigation with auth screens scaffolded
Reanimated patterns ready
Backend proxy for OpenAI / Anthropic / OpenRouter (deploy to Cloudflare Workers in one command)
Streaming chat UI with the frame-safe pattern from the snippet above
EAS Build and EAS Update preconfigured
App icon, splash screen, and store metadata templated
Revenue Cat, Authentication, Onboarding skills, Design system with react native restyle, High Performance architecture, that is scalable, included with UAMOS system., read it here

I spent 6 months losing fights with AI in React Native. Then I built U-AMOS.

The memory system that cut hallucinations 93% and token costs 91% across my own projects — and why the broader ecosystem is converging on the same pattern.

codemeetai.substack.com

It's the boilerplate I'd hand my past self on day zero. If you're a web dev planning your first AI mobile app, it cuts the setup phase from two weeks to an afternoon.

Use it, fork it, ignore it. The goal is to not lose two weeks to plumbing.

One last thing

If you're a web dev planning to build a mobile app: stop reading the "React Native vs Flutter" arguments. The framework isn't your bottleneck. The surface area you don't know yet, keyboard handling, native builds, store submissions, AI key management, is.

Pick Expo. Ship something small. Hit a wall. Read the docs for that wall. Repeat.

That's the whole path.

How I stopped Claude Code from hallucinating 42% of my React Code

Malik Chohra — Wed, 06 May 2026 08:52:13 +0000

TL;DR

I tracked 6 months of my own AI coding sessions in React Native. In my logs, 42% of AI-generated diffs contained at least one hallucinated import, fake API, or duplicate component.
Token costs were the second tax. Re-loading project context every session cost roughly $135/month per developer at the model pricing I was using.
Better prompts didn’t fix either problem. The AI didn’t need smarter instructions : it needed memory and a map.
I built U-AMOS (Universal AI Memory Operating System): a 3-tier memory bank, a context map, a rule priority system that splits “what to do” from “how to do it,” a 7-point anti-hallucination checklist, and a plan/act workflow that runs before any code is generated.
After deploying U-AMOS across my own projects over a 3-month tracking period: hallucinations dropped from 42% to 3%. Token costs dropped from $180/month to $18/month. Feature velocity increased roughly 5x. These are my internal numbers: I’ll note where external research reports similar magnitudes.
The framework is open and documented. U-AMOS 2.0 also ships pre-configured inside AI Mobile Launcher for anyone who doesn’t want to build it from scratch.

A note on the numbers

Everything in this article that is quantified — the 42%, the $135/month, the 91% reduction — comes from 6 months of my own session logs across my React Native projects. I tracked hallucinations manually, counted tokens via API usage dashboards, and measured debugging time against my own estimates. These are not controlled experiments.

What I can say is that the direction of the results matches what external research is starting to report. Memory-system papers are showing 40–60% accuracy improvements and 60–90% token reductions when you introduce structured memory into LLM workflows. Mem0’s Claude Code integration reports roughly 90% lower token usage with persistent memory vs full-context prompting. The order of magnitude is consistent. The exact numbers are mine.

The moment I stopped pretending it was working

It was a Tuesday in October. I was building a functionality for my app. I asked Claude Code to add a Redux toolkit usage to manage user accounts. It generated something that looked correct. I committed it.

Twenty minutes later, the build failed.

The AI had been imported useRouter from next/router. In a React Native project. That hook doesn’t exist on mobile. It was a 30-second fix, but it wasn’t the first time. It was the fourth time that week.

I started keeping a log. Every wrong thing the AI generated, I wrote down. After a month, I had the data from my own sessions:

42% of AI-generated diffs had at least one hallucinated import, function, or component
25% of the components it created already existed in the codebase under a different name
I was spending roughly 4 hours a week debugging things the AI had invented
I was using Cursor much more than Claude that time, so with Cursor, I had analytics dashboard, an d confirm some of my thesis

The frustrating part was that I knew the AI wasn’t getting worse. I was paying for the best models. The prompts were detailed. The context windows were huge.

The problem wasn’t the model. The problem was that I was treating it like a senior developer when it was behaving like a junior with no memory of the project, and no map of the codebase.

I have played before by adding rules, memory bank,.. but there were always issues in grasping the whole context, and i need to remind him much more often.

The token tax nobody talks about

While I was tracking hallucinations, I also started tracking token usage. The numbers were uncomfortable.

Every session, I was loading the same context: project structure, architecture decisions, naming conventions, what components already existed. The AI had no memory between sessions, so I kept reexplaining everything. Worse, when I didn’t re-explain, the AI would explore : running directory listings, opening files at random, building up its own picture of the codebase by trial and error.

That exploration is where the worst of the token bleeding happens. Asking “where is the authentication logic?” can trigger 25,000 tokens of blind navigation through folders before the AI finds it.

The math, at the model pricing I was using at the time:

Session 1: Re-load + explore project structure → 50,000 tokens
Session 2: Re-load + explore project structure → 50,000 tokens
Session 3: Re-load + explore project structure → 50,000 tokens
Daily total: 150,000 tokens
Monthly cost: ~$135/month per developer

(based on ~$30 per million tokens, prompt + completion)

That’s the invisible tax. Even when the AI was generating correct code, I was paying to give it the same context every time, plus paying for it to wander around the repo finding things it should already know about.

I do remember creating one file, that has architecture.md, where i put this type of context that i give each time, and then i created review_best_practices.md, to have the rules for the mistakes that he was repeating.

Then it comes the Claude Code best practices usage, I tried the obvious approaches first. Longer CLAUDE.md files. More detailed system prompts. Better instructions on what to remember.

None of it worked sustainably. The AI would hold context for a session or two, then drift. Because the problem wasn’t the prompt. It was the architecture.

The reframe that changed everything

The shift came when I stopped thinking of AI as a developer and started thinking of it as a system that needed memory built for it, and a map handed to it. I do remember watching an intreview by Thomas Dohmke, and he asked one of the best practices is to look at it as a colleague, not a tool.

A junior dev with no memory of your project would also generate hallucinated imports. Would also recreate components that already existed. Would also waste hours wandering through unfamiliar code looking for the right file. The AI wasn’t broken. The relationship was broken. I was asking it to behave like it had context it didn’t have.

A lot of content I’ve seen treats this as a prompting problem. Write a better system prompt. Use a longer context window. Be more specific in your instructions.

My experience, and increasingly what I see from teams who’ve shipped real production AI-assisted codebases, is that prompts plateau. Durable context compounds. The teams getting consistent AI output aren’t writing better prompts : they’re building memory systems that load the right context at the right time and update automatically when something changes.

you can read this article about best prompt engineering approach here:

Essential guide of Prompt Engineering for Software Engineers
Malik CHOHRA · 17 November 2025
Read full story

That’s what I built. I called it U-AMOS.

What U-AMOS actually is

U-AMOS : Universal AI Memory Operating System, is a framework for managing AI-assisted development. It has five components, each solving a specific failure mode I’d logged.


┌──────────────────────┐
                  │     Memory Bank      │
                  │ (Cold / Warm / Hot)  │
                  └─────────┬────────────┘
                            ↓
                  ┌──────────────────────┐
                  │     Context Map      │
                  │   (Index / Lookup)   │
                  └─────────┬────────────┘
                            ↓
                  ┌──────────────────────┐
                  │     Plan Mode        │
                  │  (before execution)  │
                  └─────────┬────────────┘
                            ↓
                  ┌──────────────────────┐
                  │ Validation Layer     │
                  │ (7-point checklist)  │
                  └─────────┬────────────┘
                            ↓
                  ┌──────────────────────┐
                  │   Code Generation    │
                  └─────────┬────────────┘
                            ↓
                  ┌──────────────────────┐
                  │  Progress Logging    │
                  │   (.memory updates)  │
                  └─────────┬────────────┘
                            ↓
                  └──────→ FEEDBACK LOOP ──────┘

1. The Memory Bank — three tiers, loaded on demand

Not all context is equally important for every task. So I tiered it.

Cold tier (project identity — loads rarely, ~10% of sessions):

00-description.md — what we’re building, in 500 words
01-brief.md — non-negotiable constraints
10-product.md — feature specs

Warm tier (architecture — loads on demand, ~30% of sessions):

20-system.md — how the system works
30-tech.md — stack and dependencies
60-decisions.md — why we chose what we chose
70-knowledge.md — lessons learned

Hot tier (current state — loads every session, 100%):

40-active.md — what we’re working on right now (max 500 words)
50-progress.md — what shipped recently

The hot tier is small (~2,000 tokens) and always loads. The warm tier loads when the task touches architecture (~5,000 tokens). The cold tier almost never loads during development — it’s the onboarding layer. A new developer (or a new AI agent starting a session) reads the cold tier once and understands the project without hunting through the entire repo.

The result: 2,000–10,000 tokens per session instead of 50,000. That assumes you’re maintaining the files actively — see the hygiene section below.

2. The Context Map — the exploration killer

This is the piece that does the most work for the lowest cost.

context_map.md is a single 500-token lookup file at the root of the project. It indexes everything: every feature, every service, every core UI component, with the entry path next to each one.

# Context Map
## Features (14)
| Feature        | Entry Point                      | Purpose            |
|----------------|----------------------------------|--------------------|
| auth           | src/features/auth/index.ts       | Authentication     |
| onboarding     | src/features/onboarding/index.ts | User onboarding    |
| todos          | src/features/todos/index.ts      | Todo management    |

## Services (15)
| Service        | Path                             | Responsibility     |
|----------------|----------------------------------|--------------------|
| logger         | src/services/logging/logger.ts   | Centralized logs   |
| analytics      | src/services/analytics/...       | Firebase analytics |

## UI Components (40+)
| Category       | Components                       |
|----------------|----------------------------------|
| Buttons        | Button, IconButton, FAB          |
| Forms          | Input, ControlledInput, Switch   |

When the AI starts a session and needs to know “where does authentication live?”, it reads one 500-token file instead of running directory listings, opening five files to compare them, and burning 25,000 tokens building its own mental model of the repo.

In my own logs, this single file removed roughly 60% of the per-session token consumption that wasn’t already covered by the memory bank. The math: 500 tokens replaces 25,000. That’s a 50x reduction on the most expensive part of every session : discovery.

3. The Rule Priority System — three tiers, with generators separate from rules

The same logic applies to coding rules.

Critical rules (always load, ~4,000 tokens):

Meta-rules and session protocol
Anti-hallucination checklist
Common violations (no inline styles, no console.log, no hardcoded strings, no API keys)

Important rules (task-specific, ~2,000 tokens each):

Design system patterns: loads if working on UI
State management rules: loads if working on the state
i18n patterns : loads if adding translations
Navigation patterns: loads if adding routes

Recommended rules (load if relevant):

Performance optimizations
Testing patterns
Security and platform-specific privacy rules

The other architectural distinction that mattered: I separated generators from rules. They look similar but they solve different problems.

Generators answer what to do. Step-by-step implementation guides for recurring tasks: “add a new language,” “add a new screen,” “add a paywall.” They’re workflow documents — copy this template, register here, run this script.
This one i include in my Ai react native boilerplate:
https://aimobilelauncher.com/, and i explained them there, you can check the code about different generators.
Rules answer how to do it well. Code quality patterns and constraints: this is what good styling looks like; this is what the wrong import path looks like.

When you mix the two, when your “how to add a language” doc also tries to explain every i18n best practice, the AI gets overwhelmed and follows neither cleanly. Splitting them means the AI reads the generator to know the steps, then reads the matching rule pack to write the code correctly. Two clean reads. No drift.

4. Concrete examples beat abstract rules

This is a philosophical point but it’s the reason U-AMOS rules actually work.

Most rule documents read like this: “Use proper styling conventions. Avoid inline styles where possible.”

Rules in U-AMOS read like this:

## Styling

### ❌ WRONG — inline styles
<View style={{ marginTop: 20, padding: 16 }}>

### ✅ CORRECT — Restyle props
<Box marginTop="xl" padding="lg"/>

### Exception: unsupported properties
<Box marginTop="xl" style={{ opacity: 0.5 }}>
(opacity is not a Restyle prop, inline is acceptable here)

LLMs don’t generalize abstract principles well. They pattern-match. If you show them what wrong looks like next to what right looks like, they reliably produce the right pattern. If you tell them to “follow good practices,” they produce whatever the training data nudged them toward last time.

Every rule pack in U-AMOS is built this way. ❌ wrong → ✅ correct → exception (if any). No paragraphs of theory. No abstract guidelines. Just visual diffs. This is the single biggest determinant of whether a rule actually changes the AI’s output or gets ignored.

5. The 7-Point Anti-Hallucination Checklist

Before any code is generated, the AI verifies:

Does the file I’m editing exist?
Did I check the component inventory before creating something new?
Did I check the service registry?
Is the import path correct?
Does the function I’m calling actually exist in that file?
Am I using the project’s i18n pattern, not hardcoded strings?
Am I using the project’s logger, not console.log?

If any answer is no, the AI stops and verifies before continuing.

The first week I deployed this, my hallucination rate in my own sessions dropped from 42% to under 5%. Not because the model improved. Because I made verification mandatory before generation.

Each of these rules is manually crafted.

6. Plan/Act Mode — no code without a plan

This is the piece I added after the initial U-AMOS deployment, and it might be the highest-leverage addition.

Before touching more than one file, the AI must:

Read .memory/40-active.md (current focus)
Draft an implementation plan in plain markdown
Wait for my confirmation
Execute only after approval
Log what it actually shipped back into .memory/50-progress.md

This sounds slow. It’s actually faster because you catch architectural mistakes at the plan stage instead of the debugging stage. Tweag’s Agentic Coding Handbook and Lullabot’s memory bank guide both document the same pattern. It’s becoming standard practice in teams using agentic coding seriously.

What changed after U-AMOS

I tracked the same metrics for 3 months after deploying U-AMOS across my own projects.

Hallucinations (from my logs): 42% → 3% (93% reduction)
Tokens per session (average): 48,000 → 4,200 (91% reduction)
Token cost (at my model tier): ~$180/month → ~$18/month
Time debugging AI errors: 4 hours/week → 20 minutes/week
Duplicate components created: 23 in the 3 months before → 0 in the 3 months after
Feature velocity: roughly 5x faster on features I tracked end-to-end

I also started tracking which rule packs loaded most often and which hallucination types were still slipping through. That observability layer is what tells you where the system needs a new rule file vs where the AI needs better examples.

Memory hygiene: pruning, plus living rules

The mistake I see in most memory bank setups is treating the files as append-only. They’re not. They need pruning.

My current hygiene routine:

40-active.md updates at the start of every work session (what’s the actual focus today)
50-progress.md gets a new entry after every shipped feature : old entries archive monthly
70-knowledge.md gets pruned weekly : if a lesson is now in a rule file, it gets removed from the knowledge doc
20-system.md only updates when architecture actually changes
If the AI proposes changes to any memory file, it does it as a plan diff I review : it never writes to memory silently

There’s one more file that prevents documentation rot: updated_rules.md. It’s a changelog for rule exceptions.

When the team makes a real exception to a rule : for example, “we never use inline styles, EXCEPT for the opacity prop because Restyle doesn’t support it” : that exception goes in updated_rules.md with a date and a reason. Not into the main rule file.

# Updated Rules (Living Document)
## 2025-12-20 — Inline styles exception

**Original rule**: NO inline styles ever
**Updated rule**: NO inline styles EXCEPT for single properties not supported by Restyle (opacity)
**Why**: Restyle doesn’t support opacity prop
**Example**: ✅ <Box marginTop="xl" style={{ opacity: 0.5 }} />

Why this matters: rules become outdated quickly, and rewriting them every time creates drift. The living rules file lets the AI always check the latest guidance without losing the original logic. Exceptions are explicit and dated. Historical context is preserved. The main rule files stay clean.

The 2,000–10,000 token figure holds only if you maintain all of this. If you let the files grow unchecked, you’ll hit 50,000 tokens again within two months. The context window isn’t the bottleneck : your maintenance habits are.

What still doesn’t work, and what’s on the roadmap

This isn’t a finished system. Four things still fail or are incomplete:

Long sessions. Context degrades over multi-hour conversations. I re-attach memory bank files every 30–40 messages. A better solution is probably an MCP server that handles re-injection automatically, but I haven’t built it.

Performance edge cases. The AI generates working code that sometimes re-renders too aggressively. Architecture rules help, but don’t eliminate this. I m fixing this by creating performance rules for expo apps. i m using the official one from Expo, but it is not enough, and with the project architecture, it needs a lot of fixes and improvement.

Cross-project memory. U-AMOS handles per-project memory. The next layer — preferences and patterns that follow you across every project you touch — is what tools like Mem0’s MCP integration and Claude Code’s own auto-memory system are starting to solve. If you find yourself re-teaching the same conventions in every new repo, cross-project memory is the fix. I’m watching this space closely.

How to set up U-AMOS yourself

I have created a Prompt intialization for the system, i test it on some of my projects, and it was succefful. not so many rules though, but you can customize that part

You can check it here: link

Thanks for reading Code Meet AI: Stay relevant in the AI era! Subscribe for free to receive new posts and support my work.

Or, if you want it pre-configured

I built AI Mobile Launcher as the productized version of U-AMOS for React Native.

It ships with:

The full 9-file memory bank is pre-structured for a new project
A pre-built context map of every feature, service, and UI component
All critical, important, and recommended rule packs — written as visual diffs, not paragraphs
The split between generators (workflows) and rules (patterns) is already in place
Pre-built component and service inventories
Cursor and Claude Code entry points configured with plan/act mode
Generators for common features (onboarding, paywalls, i18n, design system)
The 7-point anti-hallucination checklist is embedded in every entry point
A starter updated_rules.md ready for your first exception

The Lite tier is free on GitHub. U-AMOS 2.0 ships fully configured in the Starter tier. If you’re starting a new React Native project and want the memory system running from day one without the setup work, that’s the fastest path. aimobilelauncher.com

If you’re adding U-AMOS to an existing project, the steps above are enough to get started. The framework isn’t magic — it’s the result of 6 months of failed sessions, logged and analyzed, until the AI stopped fighting me and started shipping with me.

What I want you to take from this

The content I see most often on AI coding frames is this as a prompting problem. Use a better system prompt. Be more specific. Add more examples to your instructions.

My experience over 6 months of tracking my own sessions is that prompts hit a ceiling. Once you’ve written a clear, specific prompt, the next 10 iterations give you marginal gains. Memory and structure compound differently . every lesson added to the memory bank improves every future session. Every entry in the context map saves another exploration loop. Every rule written as a visual diff prevents an entire category of hallucination permanently.

The AI isn’t a developer you prompt. It’s a system you build context for. Build the memory. Hand it the map. Show it what wrong looks like next to what right looks like. Stop paying to re-explain the same architecture every day.

U-AMOS is how I did it. The principles work without my specific files. The files work better with the principles. Either way: fix the memory and the map first, then build the product.

I write Code Meet AI weekly — AI in mobile development, real tradeoffs, what’s actually working in production. Next issue: agent-first mobile architecture and why most “AI features” in apps are just bolted-on chatbots pretending to be product. → https://codemeetai.substack.com/