How RapidNative Generates Production-Ready TypeScript Code

Most "AI TypeScript code generator" demos look great in a screen recording and fall apart the moment you open the export. Missing imports, any everywhere, invented library APIs, layout that only renders on a Pixel 6, one giant App.tsx you're supposed to refactor yourself. The result compiles for the demo, then quietly rots on your machine.

RapidNative treats "production-ready" as a pipeline problem, not a prompt problem. Turning a natural-language request into TypeScript React Native code that actually ships means model selection, context gathering, template scoping, streaming, and post-processing all doing their job — the LLM is only one of the six or seven things that have to go right.

This post walks through how the pipeline actually works: the two-model split, the skill files that ground the model, the tools it's allowed to call, how code streams into your editor without dropping halfway through, and the post-processor that catches what the model still gets wrong.

Production-ready code is a pipeline problem, not a prompt problem — Photo by Luca Bravo on Unsplash

What "production-ready TypeScript" actually means

Before pipelines, definitions. When RapidNative says the generated code is production-ready, we mean seven concrete things:

1. Type-safe — no any in generated component props, no untyped route params, strict compiles clean.
2. Framework-correct — imports from the right packages (react-native-safe-area-context, not react-native), hooks used inside components, no server-only APIs in client files.
3. Runtime-correct on mobile — no CSS grid, no space-x-* Tailwind classes (web-only), SafeAreaView edges configured per screen.
4. Structured for Expo Router — screens land under app/, layouts under _layout.tsx, dynamic routes get real folders, not TODO comments.
5. Design-consistent — colors, spacing, and typography come from the project's theme tokens, not hex codes invented by the model.
6. Compilable — Babel parses it, the Metro bundler links it, the preview renders without an error overlay.
7. Exportable — you can download the ZIP, run npx expo start, and it launches on a physical iPhone.

Every stage of the pipeline below exists to guarantee at least one of those properties.

The two-model pipeline: cheap context, expensive code

The most important architectural decision in /src/app/api/user/ai/generate-v2/route.ts is that generation is not a single LLM call. It's four steps, and only one of them uses the expensive model.

Step 1 — Context gathering (cheap model, tools on). A fast, inexpensive model (Claude Haiku-class) reads your prompt and calls tools to gather context: get_files_content to read the files that matter, batch_grep to find symbols, glob for path patterns, search_skills and read_skills to load the right prompt fragments, get_images_by_keywords to pull relevant assets. Capped at ~8,000 output tokens and 10 steps, with a processedToolCalls set to deduplicate repeat calls. It's allowed to explore; it's not allowed to write code.

Step 2 — Gates and classification. The output is parsed for signals like NEW_SCREEN: yes|no. On the free plan, if a new screen would push the project past the five-screen limit, generation short-circuits with a billing gate instead of eating tokens on code the user can't save.

Step 3 — Deterministic tools. Some things shouldn't be left to an LLM. Database schema updates and auth scaffolds are generated by CLI-style tools with fixed outputs. Deterministic where determinism is possible.

Step 4 — Code generation (main model, tools off). The expensive model — Claude Opus- or GPT-4-class — gets the assembled context as structured text and produces code. Zero tools. This is the counterintuitive part: giving a strong code model access to tools during generation is usually worse, not better, because it tends to burn tokens re-reading files it already has in context, or worse, gets stuck in a tool loop and forgets to output code. Cutting tools off at step 4 forces pure synthesis.

Two models, two roles: the cheap one is a librarian, the expensive one is a writer. The librarian never writes code. The writer never fetches files.

Two models, two roles: one gathers context, one writes code — Photo by Alexandre Debiève on Unsplash

Grounding the model with skills

An LLM told to "write React Native code" will write React Native code the way an average GitHub sample writes it, which is not the way a shipping app writes it. Grounding means giving the model rules that are so specific the correct output is the path of least resistance.

RapidNative stores those rules as skills — markdown files under /tools/project-templates/fullstack/ai/skills/ compiled at build time into skills-compiled.ts. Each skill has a registry entry with an id, name, description, and an autoLoad flag so the pipeline knows which ones to inject on the first message vs. follow-ups.

First-message skills (~15K tokens total):

• first-message.md — output structure and formatting rules
• react-native-patterns.md — import rules, hook usage, native constraints
• layout-docs.md — the design system: spacing scale, typography scale, radius tokens
• theme-docs.md — the color system and how to reference it
• design-patterns.md — canonical component and layout patterns
• image-rules.md — how to reference asset URLs safely
• data-patterns.md — the "no inline data" rule (fetched or seeded, never literal in JSX)
• tanstack-query.md — the required syntax for data fetching
• vibecode-db.md — the project's database client API
• pre-output-checklist.md — final validation the model runs on itself

Follow-up skills are a smaller subset (~6K tokens) because the base system prompt already covers the critical database and pattern rules for turn two and beyond.

The reason this works: rules that live in the system prompt compete with the user's request for attention. Skills that load conditionally — only when relevant — keep the effective context tight and let each rule carry weight.

The system prompt itself, assembled in /src/modules/api/services/ai/prompts/system-prompts.ts, is organized as prioritized sections. ROLE_SECTION (priority 100), RESPONSIBILITIES_SECTION (95), MOBILE_NATIVE_SECTION (90), UNSUPPORTED_TAILWIND_SECTION (85). The mobile-native section is where the interesting knowledge lives — it explicitly bans space-x-* and space-y-* (web-only Tailwind utilities), enforces SafeAreaView from react-native-safe-area-context rather than the deprecated react-native export, and specifies edges={['top', 'left', 'right']} for tabbed screens to prevent double bottom padding. Every one of those rules exists because we watched a model get it wrong.

Templates: making the whole codebase legible

Different app types have different scaffolds. A vibecoded consumer app doesn't need the same setup as an internal admin dashboard. RapidNative solves this with templates, registered in /src/modules/api/services/ai/config/templates.ts. The current lineup:

• nativewind-themed — Expo + NativeWind + theme system (the default for RapidNative)
• fullstack — full-stack with API routes
• admin-dashboard — web-based admin UI (the FlyDash target)

Each template ships with four things: paths (root dir, app folder, API folder, import aliases), config (component base, Tailwind version), files (compiled scaffold code as JSON), and ai (its own prompts, contexts, tools, and skills).

The template determines everything the model needs to reason about: where a screen file goes, what the button component is called, whether Tailwind 3 or Tailwind 4 syntax applies, what shape a database call takes. Switching templates is the closest thing to switching entire coding conventions without touching model configuration.

The tools the model is actually allowed to call

Step 1's context-gathering model has a curated toolset defined in /src/modules/api/services/ai/providers/ToolsProvider.ts, exposed to the model via the Vercel AI SDK's tool() helper. Each tool is a typed function backed by the project's virtual file system, which lives in the Supabase files table (columns: project_id, file_path, content, file_type, mime_type).

The set:

• get_files_content — read 1–10 files, optionally with line ranges
• list_dir — list all project files
• glob — pattern match, e.g. **/*.tsx
• batch_grep — regex-search file contents
• get_images_by_keywords — fetch curated asset URLs
• list_skills / search_skills / read_skills — discover and load prompt fragments
• write_file — only invoked by the deterministic write step, not by the model directly during step 4

That last point matters. Because step 4 has tools disabled, the code the model outputs is the code that gets written. There's no drift between "what the model said" and "what ended up in the file."

Streaming code, resiliently

Nobody wants to stare at a spinner while an LLM generates 800 lines of TypeScript. RapidNative streams the output character-by-character into the editor. That's the easy part.

The hard part is what happens when your Wi-Fi flickers three minutes into a generation. Standard SSE (Server-Sent Events) dies with the connection, and you get a half-written file with no way to recover.

/src/lib/resilient-sse-instance.ts fixes this with createResilientSSE from the persistent-request-response package. The lifecycle:

1. resilientSSE.createStream()
   → { stream, enqueue, close, streamId }

2. enqueue(emitSSE('start', { projectId, model }))
   → buffered to Redis (Vercel KV / Upstash), TTL 600s

3. for await (chunk of step4.fullStream) {
     enqueue(emitSSE('text', { content: chunk.textDelta }))
   }
   → each event stored with a monotonic ID

4. If client disconnects:
   POST /api/user/ai/generate-v2 with { streamId, lastEventId }
   → server calls resilientSSE.resume(streamId, lastEventId)
   → Redis replays buffered events from lastEventId forward

Two consequences worth naming. First, the generation runs detached from the HTTP response. You can close the tab, come back, and the file finishes writing. Second, cost. If a generation costs $0.30 in tokens and a naive stream drops it 60% of the way through, that money is gone. Buffering to Redis for ten minutes turns a network blip into a retry, not a bill.

The whole flow is documented per event: start, text, tool_call, tool_result, screen_limit_exceeded, done.

Streaming resilience means one dropped Wi-Fi packet doesn't cost you a generation — Photo by Thomas Jensen on Unsplash

Post-processing: the safety net

The model is good. It is not perfect. Between the raw token stream and what lands in your project files, RapidNative runs a post-processing pass.

/src/shared/utils/postProcessor.ts exposes three entry points — postProcessFile(), postProcessFileStreaming(), and postProcessRawContent() — that handle the common failure modes: JSX imports pointing at packages that aren't installed, hook detection missing an import, package.json needing to be merged rather than replaced when new dependencies show up.

Structural validation lives in /src/shared/utils/codeValidator.ts and schemaValidator.ts, backed by the Acorn parser for TypeScript syntax checking and Zod for data-model schemas. Broken code doesn't get committed to the project files table.

When code still fails at runtime, /src/modules/file/bundler-error-parser.ts catches the Metro bundler's output, extracts the error message, file path, and line number, hashes the message for deduplication, and maps it back to the source file for inline display in the editor. If we've covered how errors are handled in more depth elsewhere, see how we handle errors in AI-generated React Native code.

The tech stack under the pipeline

The pipeline is glued together with a specific stack. From package.json:

LLM layer — ai@^4.3.19 (Vercel AI SDK) as the unified interface, with @ai-sdk/anthropic, @ai-sdk/amazon-bedrock, @ai-sdk/google-vertex, @ai-sdk/azure, and @openrouter/ai-sdk-provider as providers. Model choice per purpose (MAIN_GENERATION, VISION, CONTEXT_GATHERING) is stored in Supabase and cached for five minutes — you can rotate models without a deploy.

Streaming — persistent-request-response@^0.1.2 for resilient SSE, @upstash/redis@^1.37.0 and @vercel/kv@^3.0.0 for the event buffer.

Code processing — @babel/parser@^7.27.5 and acorn@^8.16.0 for parsing, @babel/standalone@^7.27.6 for in-browser transformation, prettier@^3.5.3 lazy-loaded for formatting on export.

Runtime target — react@^18.2.0, expo, react-native, react-native-safe-area-context@^5.6.2, react-native-svg@^15.15.1, lucide-react-native@^0.510.0, tailwindcss@^4 with nativewind.

State and data — @reduxjs/toolkit@^2.8.2 for editor state (see Redux, Context, and beyond), @supabase/supabase-js@^2.57.4 for the file store, inngest@^4.2.4 for async jobs.

This stack is deliberate. The Vercel AI SDK gives us provider-agnostic streaming with strong TypeScript types. Supabase-backed files make collaboration and version history a first-class concept. Redis-backed SSE turns fragile connections into recoverable ones. None of it is exotic; all of it is production-boring in the right way.

The output: what actually ends up in your project

The Expo Router shape the pipeline produces:

app/
  (tabs)/
    index.tsx           # route: /
    profile.tsx         # route: /profile
  [id]/
    details.tsx         # route: /:id/details
  _layout.tsx           # navigation stack
components/
  Button.tsx
  Card.tsx
lib/
  colors.ts             # theme tokens
  spacing.ts            # design system
hooks/
  useApp.ts             # database client
app.json                # Expo config
package.json            # dependencies

Screens go under {appPrefix}/{filename}.tsx (default: app/), components under {componentsPrefix}/{filename}.tsx (default: components/). Both prefixes are configurable per template through rapidnative.json. Dynamic routes get resolved for preview using dynamicRouteDefaults — a /courses/[id] file is rendered as /courses/1 in the editor so you're not staring at a "route not matched" error while iterating.

Every generated file uses TypeScript. Every component is typed. Imports resolve. Theme tokens come from lib/. When you click "Export," you download a ZIP you can npx expo start and run on a real device via QR code — no fixup pass required.

People Also Ask

Can AI actually generate production-ready TypeScript code, or does it just write scaffolds?

Modern LLMs paired with the right pipeline can generate TypeScript that ships. The bottleneck is rarely the model — it's context (does the model know the project's conventions?), constraints (are the framework-specific rules encoded?), and validation (is broken code caught before it's committed?). RapidNative's four-step pipeline exists to answer all three yes. The result is code that compiles, respects the project's design system, and runs on a physical device.

Why use two LLM models instead of one?

Cost and quality both improve. The cheap context-gathering model is good enough to read files, grep for symbols, and figure out what's relevant. Using an expensive model for that would burn tokens on retrieval instead of synthesis. The expensive main model is then handed a clean, focused context and can spend its entire budget writing code. Turning off tools during that step prevents tool loops where the model re-reads files it already has.

How does streaming code generation avoid corrupting files on disconnect?

RapidNative streams via SSE but buffers every event to Redis with a monotonic ID and a ten-minute TTL. If the client disconnects, the generation continues on the server. On reconnect, the client sends the last event ID it saw and the server replays from there. Nothing writes to the project file table until a chunk is confirmed complete.

The takeaway

"AI TypeScript code generator" is a category full of tools that produce plausible code and stop there. Making that code production-ready is the actual engineering problem, and it doesn't live in the model — it lives in the pipeline around the model: the routing between a cheap context model and an expensive code model, the skill files that turn rules into instincts, the templates that scope conventions, the resilient stream that survives network drops, and the post-processor that catches the last mile of mistakes.

If you want to see the output side of that pipeline, start a project on RapidNative — type an idea in plain English and watch the TypeScript stream in. The scaffold you get is the scaffold you can ship.

For the browser-based editor that consumes this pipeline, see inside the RapidNative editor. For how layouts get rendered mobile-correct, how RapidNative generates responsive React Native layouts. For pricing on higher-tier generations, see the plans.

External references worth reading if you're building anything similar: the Vercel AI SDK docs for the streaming primitives, Expo Router for the routing convention we compile to, and React Native Best Practices for AI Agents from Callstack for a broader look at what "correct" React Native code looks like when a machine writes it.