DEV Community: Malik Chohra

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/

Claude Code for beginners: what it is, how to set it up, and why people won’t shut up about it

Malik Chohra — Fri, 20 Mar 2026 10:48:42 +0000

TL;DR

Claude Code is Anthropic’s AI coding agent that runs in your terminal, reads your whole project, edits files, and loops until the task is done
It reached $1B in six months, partly because non-technical users started using it for SEO, file organization, marketing automation, and yes, literally monitoring tomato plants
Setup takes under 10 minutes: install, authenticate, run claude in your project folder
CLAUDE.md is the most important thing to set up — it gives Claude permanent memory about your codebase
Plan Mode makes Claude think and propose a plan before touching anything — essential before any task that spans multiple files
Claude Skills are installable, reusable workflows — over 25,000 exist on GitHub right now

Before we start, a word:

I started working on an AI native Boilerplate for Mobile Development. A solution that has a scalable and clean architecture, with the best approaches to have a great app performance. Adding more AI context and rules, to make the AI hallucinate less, and keep the clean code. You can use it either with Cursor, Antigravity, Claude Code,… and it gives the amazing results as expected. Also, it has most important features that help you launch your app fast

I m now in the Beta version, where i need people to test it, and gather feedback, you will get access to the code base for free, and i m looking for feedbacks.

Check it here: https://aimobilelauncher.com/

Also, I m working on a newsletter for Tech and non tech people, on how to use AI tools for App development: https://aimeetcode.substack.com/. Subscribe here: https://aimeetcode.substack.com/

If you need custom solution, or a mobile development, contact us in :https://casainnov.com/

Introduction:

Lately, I start to see something cool: Product manager, Designer, CS teams,… and non technical roles have started to use Terminal. I was surprised to see that now most of the people have a terminal open, which at some point was only for tech people who really understand what is going on. Now, the terminal in computers has become the norm

It is highly attributed that all of them started using Claude Code to run their project and to assist them in their work, with custom skills for their specific role / organisation. The trend is getting more and more

I don’t want to talk about combining it with OpenClaw, which took the internet by storm.

Why is everyone suddenly talking about this

I started using it at first when it was announced: as a tech person, Anthropic models are the best at coding, and I use most of their models < depends on the tasks in hand, of course>. And I wasn’t that surprised with Claude Code. It has skills and rules, but I kept the same AI architecture for coding < rules, context, memory bank, indexing…>

I have been using this approach for my aimobilelauncher.com to launch my AI native boilerplate. The plan mode was really helpful, and including skills for it is my roadmap for later

Then Anthropic confirmed $1 billion in annualized revenue in six months, and Fortune ran the story. I read it expecting the usual: 10x engineer productivity, enterprise contracts, vibe coding demos.

The use cases they listed were: booking theatre tickets. Filing taxes. Monitoring tomato plants. Combing through museum archives. Automating Slack messages.

That’s not a developer story. Something else was happening.

Netflix, Spotify, Uber, and Salesforce had all adopted it. Accenture announced they’re training 30,000 staff on the platform. Not 30,000 engineers. 30,000 staff. Anthropic’s own non-technical marketing team runs it to automate Google Ads creative, App Store metadata, email workflows, and SEO.

The reason it spread outside engineering is simpler than most people explain: Claude Code doesn’t need you to know how to code. It needs you to know what you want done. The terminal is just a text box. Files are organized information. Claude Code is an agent that can read, edit, and act on both. Also, the community adopted it very fast, and they started creating solutions on top of it: Open source skills is an example.

## What Claude Code actually is

Claude Code is a terminal-native AI agent from Anthropic. Not a plugin. Not autocomplete. It runs in your terminal with access to your actual files and your actual command line.

Give it a task, and it runs this loop:

Reads your files, searches directories, checks configs
Proposes a plan
Edits files, runs commands
Reads the output — test results, build logs, errors
Fixes what broke and runs again

Step five is what most AI coding tools skip. Copilot writes a suggestion and stops. Cursor helps you write code per session and stops. Claude Code stays in the loop until the job is done — or until it runs into something it genuinely can’t figure out and asks you.

How to install it

You need one of these to start:

A paid Claude subscription (Pro at $20/month minimum)
Or a Claude Console account with active API billing

No free tier. That’s the only real gate.

`// macOS / Linux:
curl -fsSL https://claude.ai/install.sh | bash

// Via npm (still works, but deprecated by Anthropic):

npm install -g @anthropic-ai/claude-code`

After installing:

cd your-project-folder claude

First run asks you to authenticate with a link. It sends a verification code back to the terminal. About 60 seconds total. Then you’re in.

## Set up your workflow: CLAUDE.md

CLAUDE.md is a Markdown file you create at the root of your project. Claude Code reads it at the start of every session.

Without it, every session starts from scratch. Claude doesn’t know your stack, your folder structure, your naming conventions, or the three things you told it never to do two sessions ago. It just scans what it can see and makes assumptions.

That leads to weird architecture suggestions, wrong import paths, and Claude confidently using a pattern that your codebase specifically avoids.

CLAUDE.md fixes this. You write down the things Claude should always know, and it reads them every time.

Here’s a real example for a React Native / Expo project:

`# Project: My App

Stack

React Native with Expo SDK 54
TypeScript (strict mode)
NativeWind for styling
Redux for state management
Supabase for backend

Coding conventions

Functional components only — no class components
TypeScript with explicit return types
Named exports, not default exports
Folder structure: screens/, components/, hooks/, utils/, services/

What never to do

Do not install new libraries without asking first
Do not modify .env files
Do not refactor code unless explicitly asked

Git

Always create a branch before making changes
Conventional commits: feat(), fix(), refactor()

Expo

always using 'npx expo install

You can ask Claude to generate a first draft for you:

Read the project structure and generate a CLAUDE.md file for this codebase.

Plan Mode — think before you touch anything

Most people find out about Plan Mode by watching it not be on and regretting it.

Plan Mode makes Claude read files and ask questions, but it cannot write, edit, or run anything while in this state. It has to think, plan, and explain what it intends to do before execution starts. Then you approve, modify, or cancel.

To activate: press Shift + Tab twice. The mode indicator in the bottom left of the terminal changes.

The practical difference is clearest with an example.

Without Plan Mode, you say:

“Add authentication to this React Native app”

Claude starts writing immediately. It picks an auth library, picks a navigation approach, picks a token storage strategy. By the time you see the output, it’s made four foundational decisions you might disagree with and they’re already in the files.

With Plan Mode:

“Add authentication to this React Native app”

Claude asks: “Which auth provider? How is your navigation structured? Where do you store tokens today? Do you want biometric support?” You answer. Claude writes a plan: specific components, a sequence, the libraries it wants to use. You read it. You push back on anything wrong. You approve. Then it executes with a clear, agreed-upon approach.

I use Plan Mode for anything that touches more than two or three files. It’s not slower — the time you spend reviewing the plan is time you’d spend fixing wrong assumptions later.

For non-technical users: Plan Mode is honestly the feature that makes this feel safe. Nothing happens without you seeing it first.

— -

Commands worth knowing

These come up in almost every session:

A note on /clear: in long sessions, Claude starts to lose track of earlier instructions. Not always

/clear and paste a quick summary of where you are. Claude gets back on track fast. Use /compact if you want to keep a condensed memory of the session.

I usually do the 10 prompt rules: after 10 prompts, compact.

## Claude Skills

This is the part most people skip when they start. That’s usually where the frustration comes from.

A Claude Skill is a Markdown-defined workflow packaged as a ZIP or a GitHub repo. It tells Claude exactly how to execute a specific, repeatable task, step by step, with the rules and output format written in.

Every time you want a repeatable task done without a Skill, you explain the whole process from the start. Every session. Skills replace that. Install once, type one command, and Claude runs the full process the same way every time.

Think about any process you’ve explained to someone more than twice. A Skill is that explanation written down properly, so Claude follows it without you having to be there for every run.

There are over 25,000 community-built Skills on GitHub:

awesome-claude-skills: https://github.com/travisvn/awesome-claude-skills

skills.sh: https://skills.sh/

browsable marketplace: https://github.com/anthropics/skills

Skills cover SEO audits, React Native performance checks, documentation generation, DevOps automation, security reviews, data analysis, and a lot more. The ecosystem is growing fast, and most of it is free.

Anthropic also shipped organization-level Skills deployment in December 2025. Admins can now push Skills workspace-wide with automatic updates. Teams can standardize processes the same way they standardize code.

How a Skill actually works

Each Skill has a SKILL.md file. YAML frontmatter at the top tells Claude when and how to invoke it. The Markdown below is what Claude follows when it runs.

— -
name: rn-performance-audit
description: Audits a React Native screen for performance issues.
Use when reviewing a screen component or when the user asks
about performance, re-renders, or slow UI.
— -
When auditing a React Native screen for performance:

Check for unnecessary re-renders (missing useMemo, useCallback)
Identify heavy computations inside render
Check FlatList vs ScrollView usage
Look for images without proper caching or resizing
Flag synchronous operations on the main thread

Output: a prioritized list of issues with code-level fix suggestions.

Once installed, Claude auto-loads this Skill when you ask about performance, or you invoke it directly with /rn-performance-audit.

— -

Example of A skill that I use: Claude SEO skill

I have started lately using seo skill: https://github.com/AgriciDaniel/claude-seo. It is really helpful for website SEo audit, and then adding fixes

Check how to install it there, and then you do / to call it, and do /seo so it gives you the whole report

I like after that to ask to create a fix plan, using Plan mode for that. and then i ask it to implement it

Things that will catch you off guard

I learned these the hard way, so you don’t have to.

Commit before every Claude session:

Claude can introduce regressions. It fixes one thing and occasionally breaks something in a different file. Not often, but enough. A clean Git commit before you start means rollback is one command. I’ve needed it more than once.

Auto-accept is a trap.

*There’s a — dangerously-skip-permissions flag that lets Claude apply all changes without asking. Don’t use it until you’ve run a task type several times and understand its output well. I let it “tidy up some type definitions” once and got 40 renamed interfaces back. All of them logical. None of them what I wanted. I rolled back with Git and never used that flag on unfamiliar tasks again.

Token costs sneak up on you:

Long sessions, large repos, parallel agents — these burn tokens faster than a focused single-task session. Run /cost inside any session to check where you are. Monitor the Anthropic console when you’re starting out. You want to know what a typical session costs before you schedule one as a weekly routine.

Messy codebases produce messy results:

Claude Code’s ability to understand your project depends entirely on how coherent that project is. Scattered configs, inconsistent patterns, no CLAUDE.md — it still runs, but the suggestions start to drift in weird directions. The architecture discipline makes it more useful. Chaos amplifies chaos.

Rate limits reset on a rolling 5-hour window, not daily:

If you hit your limit at 2 pm, you get a fresh allocation around 7 pm. Once I understood this, I stopped fighting the limits and started working in focused sessions instead. Honestly, a better habit anyway.

FAQ

Do I need to know how to code to use Claude Code?
No. The VS Code extension and Claude Desktop both work without the terminal. You describe what you want in plain language and Claude Code executes. Non-technical users are currently using it for SEO, marketing workflows, file management, and data processing.

What is CLAUDE.md and why does it matter?
It’s a Markdown file in your project root that Claude Code reads at the start of every session. It stores your stack, coding conventions, and what Claude should never do. Without it, every session starts from scratch. It’s the single biggest difference between a good and a bad Claude Code experience.

What is Plan Mode?
A state where Claude can read files and ask questions, but cannot write or run anything. It proposes a full plan first. You review and approve before a single file is touched. Activate with Shift + Tab twice.

What are Claude Skills?
Reusable workflow instructions packaged as Markdown files in a ZIP or GitHub repo. Install once, run on demand. Claude follows the workflow consistently every time without re-explanation.

Where do I find Skills?

awesome-claude-skills on GitHub: https://github.com/travisvn/awesome-claude-skills

How much does Claude Code cost?
It requires a paid Anthropic subscription. Pro is $20/month with roughly 45 messages per 5-hour window. Max 5x is $100/month. No free tier access.

Can I use this for React Native development?
Yes. Claude Code works with any file-based project. For React Native and Expo, the main thing is setting up CLAUDE.md with your stack details and conventions. Once that’s in place, Claude can refactor screens, add features, debug issues, and run Expo CLI commands the same way it does for any other project.

Optimizing animations for 60 FPS with React Native Reanimated

Malik Chohra — Thu, 19 Mar 2026 07:47:09 +0000

Before we start, a word:

Check it here: https://aimobilelauncher.com/

Also, I m working on a newsletter for Tech and non tech people, on how to use AI tools for App development: https://aimeetcode.substack.com/. Subscribe here: https://aimeetcode.substack.com/
If you need custom solution, or a mobile development, contact us in :https://casainnov.com/

Introduction

Smooth animations aren't a "nice-to-have." When users say "this app feels slow," they almost always mean animations are dropping frames - even if they'd never describe it that way.
After shipping features on apps with millions of active users, I've learned that animation performance is one of the first things that breaks at scale and one of the hardest to debug if you haven't seen the failure modes before. Here's what actually holds up in production.

Speaking of scale: in Mobile apps, I mean by scale is a bigger team, a lot of users who each person have a different devices, operating system, slow and old devices, or different sizes. In this part, you need to architect your app way better before

TL;DR

60 FPS means keeping animations off the JS thread
Use shared values, not React state
Animate transform + opacity; avoid layout properties
Batch animations and keep logic simple
Test on real devices, not simulators

Why it matters

Dropped frames make an app feel slow. Janky gestures make it feel cheap. And inconsistent motion is hard to explain to a product manager but immediately obvious to users. Beyond UX, smoother animations also mean better battery life, better behavior on low-end devices, and less competition with your business logic.
The one rule that matters most

If your animation depends on the JS thread, you've already lost.
Reanimated runs animations on the UI thread, independent from JS. Everything else in this article is just ways to not break that.

1. Animate only what the native driver supports

Safe: transform, opacity. Slow: width, height, backgroundColor, anything layout-driven.
`
// Good
const style = useAnimatedStyle(() => ({
opacity: opacity.value,
transform: [{ translateY: y.value }, { scale: scale.value }],
}));

// Bad
const style = useAnimatedStyle(() => ({
width: width.value,
height: height.value,
}));`

If you feel like you need to animate the layout, stop and rethink the design. The animation is probably covering for a structural problem.

2. One shared value, not five

I still see this in senior-level code:

// Too many values const opacity = useSharedValue(0); const scale = useSharedValue(0); const translateY = useSharedValue(0); Collapse them: const progress = useSharedValue(0); const style = useAnimatedStyle(() => ({ opacity: progress.value, transform: [ { scale: progress.value }, { translateY: (1 - progress.value) * 20 }, ], }));

One value, fewer calculations, smoother frames. The math is trivial on the UI thread.

3. Batch your animations

Starting animations at different times means the thread is doing more work than it needs to. A single withTiming can drive opacity, scale, and translation at once:

useEffect(() => { progress.value = withTiming(1, { duration: 300 }); }, []);

Obvious in hindsight, but easy to miss when you're wiring up components quickly.

4. Springs for gestures

Timing functions work fine for entrances and exits. For gestures, springs are better - they feel more physical, and they put less pressure on the frame budget:

translateX.value = withSpring(0, { damping: 15, stiffness: 150, });

This matters most for drag, swipe, and scroll interactions, where any stiffness or lag is immediately noticeable.

5. Keep gesture handlers dumb

No conditionals. No calculations. No JS calls inside gesture handlers.

onActive: (event) => { x.value = event.translationX; y.value = event.translationY; }

The UI thread moves pixel. Anything else belongs else where.

6. Clean up animations

Animations that outlive their components create memory pressure. Easy to overlook, adds up on apps with deep navigation:

useEffect(() => { return () => { progress.value = 0; }; }, []);

7. How to test

Simulators will lie to you. A simulator doesn't have thermal throttling, doesn't run on 3GB of RAM, and doesn't have fifteen background apps fighting for CPU. Test on low-end Android, older iPhones, and devices that have been warm for a while.
If it holds up there, you're fine.

Always go with an old device,

What I actually see in code reviews

Animating every component entry - motion should mean something; overuse kills that
Animations tied to React state - state updates and animation updates are not the same thing
Durations over 500ms - they feel slow and block frames; tighten them
Elaborate easing curves - usually not worth it; keep it consistent

Before you ship

Ask yourself: Is this running on the UI thread? Can one shared value drive it? Did I test it on real hardware? If yes across the board, you're done.

FAQ

Does Reanimated always guarantee 60 FPS?
No. It gives you the right architecture. You still have to use it correctly.

Should I use Reanimated for every animation?
Not necessarily. Simple layout animations are fine with LayoutAnimation. Reanimated earns its complexity with gestures and anything UI-thread-sensitive.

Are springs always better than timing?
For interactions, yes. For entrances and exits, timing is usually fine and easier to control.

Is performance worse with Expo?
No. Expo and Reanimated together are production-proven

Example from the AI Mobile Launcher

Integrate DeepSeek AI into React Native app: Full guide for Generative AI in React Native

Malik Chohra — Sat, 08 Mar 2025 10:06:35 +0000

Integrate DeepSeek AI into React Native appIntegrate DeepSeek AI into React Native app: Full guide for Generative AI in React Native

Introduction

React Native has revolutionized mobile app development by enabling developers to build native applications using JavaScript and React. Since its introduction by Facebook (now Meta) in 2015, it has become one of the most popular frameworks for cross-platform mobile development, powering thousands of apps across iOS and Android platforms.

We've witnessed an unprecedented race in generative AI development in the last year. While OpenAI's GPT series and Anthropic's Claude have dominated headlines, open-source alternatives like Meta's Llama and DeepSeek are rapidly gaining traction. These open-source models are particularly interesting because they offer comparable performance while providing more flexibility and control over deployment.

Companies are racing to create an AGI that can solve all the humans problems, although the road is still far for that in my opinion, but we are getting closer each time, and billions of dollars are spent on that. For example the 500 billions projects in USA and the 50 billions AI investment from UAE in France.

DeepSeek, in particular, has shown impressive results in recent benchmarks. According to their technical report, DeepSeek has demonstrated superior performance in coding tasks and mathematical reasoning compared to other open-source models. Their 67B parameter model has achieved competitive results against GPT-4 in several benchmarks, making it an attractive option for developers looking for powerful AI capabilities in their applications.

DeepSeek's impressive performance in benchmarks suggests a promising future for open-source AI models. As these models continue to improve, developers will have more options for implementing AI capabilities in their applications without being locked into proprietary solutions.
The ability to self-host these models or use them through APIs provides flexibility in deployment options, which is particularly important for applications with specific privacy or regulatory requirements.

In this article, I will explain to you how to use it inside a React and React Native app, although the funny part is that they use Open ai SDK package to integrate their solution, which is a clever move from the company to make the switch easy, as the price/performance quote is much better if you use Deepseek that using Open AI models

Integrating DeepSeek AI in React Native

Let's walk through the process of integrating DeepSeek AI into a React Native application to create an AI chat interface.
1. Setting Up the Project

First, ensure you have the necessary dependencies installed:
context

npm install react-native-gifted-chat axios react-native-paper react-native-safe-area-context // or if you are using Yarn yarn install react-native-gifted-chat axios react-native-paper react-native-safe-area-context

2. Creating the Chat Interface

The implementation uses react-native-gifted-chat, a popular library for building chat interfaces in React Native. Here's how to structure your component:

import React, {useState, useCallback, useEffect} from 'react'; import {GiftedChat, IMessage} from 'react-native-gifted-chat'; import axios from 'axios';

3. Configuration

Set up your DeepSeek API credentials:

const DEEPSEEK_API_URL = 'https://api.deepseek.com/v1/chat/completions'; const DEEPSEEK_API_KEY = 'Your_API_Key_Here';

4. Implementing the Chat Logic

The core functionality revolves around two main parts:
Message Management

const [messages, setMessages] = useState<IMessage[]>([]);
const [loading, setIsLoading] = useState(false);

// Initialize with a welcome message
useEffect(() => {
  setMessages([
    {
      _id: 0,
      text: 'Type your question or share what's on your mind…',
      createdAt: new Date(),
      user: {
        _id: 0,
        name: 'DeepSeek',
        // url for deepseek logo
        avatar: 'https://cdn.deepseek.com/platform/favicon.png', 
      },
    },
  ]);
}, []);

6. API Integration

const sendMessageToDeepSeek = async (userMessage: IMessage) => {
  setIsLoading(true);
  try {
    const response = await axios.post(
      DEEPSEEK_API_URL,
      {
        model: 'deepseek-chat',
        messages: [{role: 'user', content: userMessage}],
      },
      {
        headers: {
          Authorization: `Bearer ${DEEPSEEK_API_KEY}`,
          'Content-Type': 'application/json',
        },
      },
    );
    // Process response and update chat
  } catch (error) {
    console.error('DeepSeek API Error:', error);
  } finally {
    setIsLoading(false);
  }

7. UI Customization

const renderInputToolbar = (props: InputToolbarProps<IMessage>) => (
  <InputToolbar {...props} containerStyle={{backgroundColor: '#f0f0f0'}} />
);

const renderSend = (props: SendProps<IMessage>) => (
  <Send {...props}>
    <View style={styles.sendButton}>
      <Icon source="send" color="blue" size={30} />
    </View>
  </Send>
);

return (
<GiftedChat
        messages={messages}
        onSend={messages => onSend(messages)}
        onInputTextChanged={setText}
        bottomOffset={insets.bottom}
        renderSend={renderSend}
        renderInputToolbar={renderInputToolbar}
        renderChatFooter={renderFooter}
        scrollToBottomComponent={renderScrollToBottom}
        user={{
          _id: '1',
          name: 'Malik',
          avatar: PROFILE_IMAGE,
        }}
      />
)

The interface can be customized using custom renderers:

Check the full projects and code here: https://reactnativetemplates.com/screensCode/19

React Native Template

React Native Template, contains beaultifully designed, expert crafted React Native components and screens. To Help you…r

https://reactnativetemplates.com/ react native links

Best Practices and Considerations

API Key Security: Never expose your API key in the client-side code. Use environment variables or a backend service to secure your credentials.
Error Handling: Implement robust error handling for API calls and network issues.
Loading States: Provide visual feedback during API calls using loading indicators.
Message Persistence: Consider implementing local storage to persist chat history.

Conclusion

Integrating DeepSeek AI into a React Native application is straightforward and opens up possibilities for creating sophisticated AI-powered chat interfaces. As the AI landscape continues to evolve, having knowledge of implementing these integrations becomes increasingly valuable for modern mobile developers.
- -
This article provides a comprehensive overview of integrating DeepSeek AI with React Native, from the technical implementation details to the broader industry context. You may want to add specific benchmark numbers and more recent comparisons as they become available, as well as any additional implementation details specific to your use case.

Get the Best React Native Templates in 2025: Community work

Jumpstart your app development with high-quality React Native templates! Discover a variety of pre-designed screens and code examples at React Native Templates:

https://reactnativetemplates.com/.

Want to contribute and showcase your React Native expertise? You can easily add your own templates to share with the community and gain valuable exposure. Browse our diverse collection of React Native screens to find the ideal foundation for your next project.
If you need to integrate Advanced functionalities in your Mobile app, create one from scratch, or need consulting in react native. Visit the casainnov.com, and check their mobile app page, and contact them there.

I share insights about React Native, React, and Typescript. Follow me on Linkedin or Medium.

ReactNative #WebSockets #RealTime #MobileDevelopment #AppDevelopment #TechInnovation #Coding #JavaScript #MobileApps #DevCommunity #SocketProgramming #RealTimeCommunication #TechNavy #TurboModule #nativeModule

Use Generative AI in React Native: Create Mistral AI Mobile app

Malik Chohra — Sat, 23 Nov 2024 12:32:03 +0000

Introduction

Generative AI tools have been leading the headlines for quite some time now, with each new release promising to reshape the way we live, work, and interact with technology. These emerging tools have plainly caused a spark of innovation from automating creative processes to enabling human-like conversations. Every few months, we hear about a new generative AI tool that claims to be a game-changer, fueling the hype and setting expectations sky-high.

While much of this development has centered around the web, recent advancements have started to shift attention to the desktop. Tools are now incorporating AI features directly into operating systems or productivity software, increasing convenience and functionality for users on the desktop. Still, one major market remains under-served: mobile applications.

Mobile applications are at the heart of our lifestyles today and hold a host of opportunities for integrating generative AI into them. The global mobile application market size was valued at USD 252.89 billion in 2023 and is projected to grow at a compound annual growth rate (CAGR) of 14.3%

From 2024 to 2030 From AI-powered chatbots that can be embedded in messaging applications, and personalized content creators used through social media platforms, to productivity applications that can compose emails or summarize documents on the go, the potential of mobile applications to deploy generative AI is immense; a space where very few tools have dared to venture.
**
Read full article here: https://casainnov.com/use-generative-ai-in-react-native-create-mistral-ai-mobile-app
**
Generative AI Tools: A Snapshot
Generative AI is not a vertically oriented market. Several big names lead the charge in this crowded field. Quick overview:

ChatGPT, courtesy of OpenAI, perhaps is the most well-known. It has become synonymous with generative AI. From casual conversations to deep problem-solving, it is in wide usage. By leading the charge, it has smoothened the way for developers to integrate AI into their web apps via APIs.: https://openai.com/

Gemini by Google DeepMind: This exciting new entrant in the generative AI space introduces multimodal capabilities to handle both text and image processing. Positioning itself firmly as a hard competitor to ChatGPT on both performance and versatility.: https://gemini.google.com/

Claude by Anthropic: Designed for safety and reliability, Claude aims at helpful and less biased outputs. It’s gaining traction for applications where quality of content and ethics in AI use are a priority.: https://claude.ai/

Mistral AI: A European player, Mistral AI offers high-performance and scalable, developer-friendly tools. It might not have the same brand recognition in the market today as ChatGPT or Claude, but its underlying APIs have much potential in certain use cases.: https://mistral.ai/

Ai Tools comparaison
Mistral AI: Lagging Behind in Adoption
Despite the fact that Mistral AI has all the makings of a promising player in the generative AI ecosystem, it is still struggling to break into the mainstream. Unlike OpenAI, which enjoys great publicity and overall exposure in every big platform, Mistral AI is still carving its niche. Contributing reasons include:

Insufficient Marketing: Mistral AI has failed to enjoy the buzz in marketing like its other competitors, especially in non-European markets.

Developer-Centric: While this makes Mistral AI an excellent choice for more technical users, the wide consumer market has yet to be captured.

Neglecting Mobile: Similar to many generative AI tools out there, Mistral AI has placed most of its efforts into web-based solutions, leaving a large gap in its mobile integration and adoption.

This, however, is an exciting gap. The idea is to bring Mistral AI into the mobile domain, not only realizing its potential but also showcasing the generative AI capabilities beyond traditional markets. This is what I tried to achieve in my project: using Mistral AI’s generative API within a React Native app, showing how such generative AI could add value to mobile apps and expand the effect of generative AI into everyday mobile experiences

React native and Generative AI tools

The best part about React Native is the usage of Typescript, which includes the usage of Typescript API tools, the same that is used in React for example. most of the apps that have a Web presence, can be integrated into a Mobile app to offer the same service.

Also, it will generate an app that works for both Android and iOS, which makes it easier to attract more users. and with the latest performance updates ( the new architecture), businesses are shipping a native feeling Apps in React native, with half the time of development and half the effort.

Of course, there is a difference when it comes to that, but usually the same approach.

Step by step to implement Generative AI API in React Native
In this tutorial, I create a Mistral AI Mobile app in React native, I will walk you through the tutorial step by step in order to do that:

The GitHub link: https://github.com/chohra-med/mistralAIRN

*The app contains the following,
*
— The app was developed using My boilerplate: https://blog.stackademic.com/architect-your-react-native-app-to-handle-millions-of-users-and-large-development-teams-cfc566ea8bf0

Dark and Light Mode: https://medium.com/@malikchohra/build-for-scale-use-a-design-system-in-your-react-native-app-0224797da39b
Hide keys in React native using the config: https://casainnov.com/securing-sensitive-keys-in-react-native-with-react-native-config
Internalization: https://medium.com/@malikchohra/build-for-scale-use-internalization-for-react-native-6fb9f5c06dd2
Redux for state management and API calls: https://casainnov.com/build-for-scale-infinite-scroll-using-react-query-with-redux-toolkit-in-react-and-react-native
E2e and Unit testing: https://medium.com/@malikchohra/guide-to-testing-in-react-native-end-to-end-test-using-detox-f29fd1344180
Animation Handling: https://casainnov.com/learn-animation-in-react-native-using-reanimated-library
Fastlane for CI-CD: https://medium.com/@malikchohra/ci-cd-pipeline-for-react-native-apps-use-fastlane-and-github-actions-40f9ad2036d0
React Navigation: https://medium.com/@malikchohra/build-for-scale-best-approach-on-how-to-use-react-navigation-in-react-native-d3eb7362c80e
It uses Gifted Chat: https://github.com/FaridSafi/react-native-gifted-chat

Integrating Mistral AI

**step 1: Do as any Developer: Read the documentation
**If you want to learn more about the API calls that they offer and how you can use them, read this first: https://docs.mistral.ai/getting-started/quickstart/

**step 2: Get An API Key and put it inside your config file
**To use Mistral Ai in your app, you need to get an API key from them, just go to their portal and it is easy to get one.
add that to your .env file, as explained in this article : https://casainnov.com/securing-sensitive-keys-in-react-native-with-react-native-config

//.env MISTRAL_API_KEY=your_api_key_here MISTRAL_API_URL=https://api.mistral.ai/v1/chat/completions

step 3: do the API call and integrate that to Redux
As explained in the Redux article, create your API call to get the answers from Mistral AI, add that to redux and create your store and reducer

step 4: create your UI
we are using Gifted Chat to display answers. read more here in their package: https://github.com/FaridSafi/react-native-gifted-chat/

**step 5: Create Custom Input component
**For this tutorial, to include the custom theme, and add functionalities, I created a custom Input, check the code here: https://github.com/chohra-med/mistralAIRN/blob/main/src/screens/HomeScreen/components/CustomizedInputProps.tsx

**Step 6: finalize and test
**Do the following:

Add your navigation
add your color theme
add container for dark mode handling
add different languages that you use
add your tests: Unit and E2E
add your Fastlane for CI CD
The output of the app:

Mistral ai app usig React Native
**What can be added:
**You can add the following to make the app even better:

Persist conversation to save them for later
Add Lazy Loading for the screens
Debounce Input: Prevent rapid API calls by debouncing user inputs
Error Handling: Provide user-friendly error messages for failed API calls.

Conclusion

Generative AI is going to change the way we interact with technology. The integration of this into mobile applications opens the world for endless possibilities. A lot of tools, like ChatGPT, Gemini, and Claude, are reigning supreme on the web and desktop spaces, but there is an untapped opportunity to bring this powerhouse into our pocket. This article demonstrated how one can harness the power of Mistral AI in a React Native app by showing exactly how to merge bleeding-edge technology with mobile platforms.

By walking through a practical use case — from defining the purpose to implementing API calls and building an intuitive UI — we’ve shown that integrating generative AI into mobile apps is not only achievable but also a step toward shaping the next generation of mobile experiences. Mistral AI, despite its lower adoption compared to its competitors, provides developers with robust tools that can redefine mobile app functionality.

As generative AI continues to evolve, developers have the chance to drive this technology beyond hype and into practical, everyday solutions. Whether it’s crafting personalized experiences, automating workflows, or building smarter apps, the possibilities are endless. Now, it’s your turn to experiment and innovate — because the future of AI is mobile, and it’s waiting to be built.

If you need to integrate Advanced functionalities in your Mobile app, create one from scratch, or need consulting in react native. Visit the casainnov.com, and check their mobile app page, and contact them there.

I share insights about React Native, React, and Typescript. Follow me on Linkedin or Medium.

ReactNative #WebSockets #RealTime #MobileDevelopment #AppDevelopment #TechInnovation #Coding #JavaScript #MobileApps #DevCommunity #SocketProgramming #RealTimeCommunication #TechNavy #generativeAI #mistralAI