Prompt Engineering for Code Generation: Inside RapidNative's LLM Prompt Architecture

Give a modern LLM a one-liner like "build me a fitness tracker in React Native" and it will happily produce something. That something usually doesn't run. It imports icons that don't exist. It uses CSS grid on a platform that doesn't render CSS grid. It reaches for a UI library that isn't installed. It quietly forgets that mobile screens need SafeAreaView edges configured for tab layouts.

This is the gap between "LLM writes code" and "LLM writes code that ships."

Closing that gap is the entire discipline of prompt engineering for code generation — and at RapidNative we spend a disproportionate amount of engineering effort on it. Not on model choice. Not on hyperparameters. On the exact structure, order, and phrasing of the instructions we hand the model before it writes a single line.

This post opens the hood. You'll see how our system prompts are built, why they're modular and priority-ordered, how we parse semantic signals from free-form model output, and how we inject context differently depending on whether the user is typing a prompt, uploading a screenshot, or clicking a specific line in the editor.

A production LLM pipeline for code generation is 20% model, 80% prompt architecture — Photo by Markus Spiske on Unsplash

Why Prompt Engineering Matters More Than Model Choice

A common assumption is that better models solve prompt problems. Newer Claude, newer GPT, newer Gemini — the numbers go up, the code gets better. This is partly true and mostly misleading.

We've A/B-tested the same generation task across Claude Sonnet 4.5, GPT-4o, GLM, Qwen 3 Coder, and Llama 3.3 with the same prompt. Output quality varies by ~20% across models. Then we swapped in a purpose-built system prompt with priority-ordered constraints — quality jumped by ~60% on the same models.

The prompt is the leverage point. This matches how we think about our 4-step LLM pipeline — the architecture around the model matters more than the model itself.

Mobile code generation makes this leverage even sharper because React Native has non-obvious constraints:

• No CSS grid. Yoga's flex model is stricter than the browser's.
• SafeAreaView must come from react-native-safe-area-context, not react-native.
• A ScrollView inside a flex column expands vertically to infinity unless you constrain it with max-h-*.
• Tab screens need edges={['top', 'left', 'right']} — omit bottom or the content sits behind the tab bar.

None of these live in a general-purpose model's training weights with any reliability. They live in the prompt.

The Modular, Priority-Ordered Prompt Architecture

Our system prompt isn't a single monolithic string. It's twelve independent sections, each with:

• A priority (higher runs first, sets the frame)
• A content block (the actual instructions)
• An overridable flag (can templates disable this section?)

Here's the priority stack in production:

The priority system exists because sections aren't equal. Role & Responsibilities frame everything below them; if you buried them at the bottom, the model would set its own frame from the first specific instruction it saw. Constraint blocklists (unsupported Tailwind) need to come before format examples because the model produces the format at the end of generation, but the constraints must already be internalized.

The overridable flag lets templates reshape the prompt. The fullstack template — which supports a live database, TanStack Query, and auth — extends the base role to be more ambitious ("You are an award-winning mobile product designer who writes code — the caliber of teams at Apple, Airbnb, Linear") and adds a whole new set of banned patterns (no Prisma, no hooks at module scope, read-only files listed by path).

The base architecture is a merge function. Here's the essence of buildSystemPrompt():

export function buildSystemPrompt(options: BuildPromptOptions = {}): string {
  const sections: string[] = [];

  // 1. Core prompts sorted by priority, highest first
  const corePrompts = getCorePrompts().sort((a, b) => b.priority - a.priority);

  // 2. Apply template overrides
  const templatePrompts = getTemplate(options.templateId).ai.getPrompts();

  // 3. Merge, filtering disabled sections
  for (const section of corePrompts) {
    const override = templatePrompts.find(t => t.name === section.name);
    if (override?.disabled) continue;
    sections.push(override?.content ?? section.content);
  }

  // 4. Inject dynamic context (design guidelines, conversation state, etc.)
  if (options.designGuidelines) sections.push(options.designGuidelines);
  if (options.conversationContext) sections.push(options.conversationContext);

  return sections.join('\n\n');
}

Every template starts from the same 12 pillars, then bends the ones it needs to.

Constraint Modeling: The Real Craft

Most of what makes a code-generation prompt work is what it forbids, not what it encourages. LLMs are pattern completers — give them room and they will pattern-complete their way into a broken app. The prompt's job is to shrink the space of legal completions until only working code fits.

We use three constraint techniques.

1. Explicit Blocklists

For unsupported Tailwind classes, we list them by name. Not "use flex instead of grid" — an actual denylist:

❌ NEVER use these Tailwind classes (unsupported in React Native):
- space-x-*, space-y-*  → use gap-* instead
- grid, grid-cols-*, grid-rows-*
- fixed, sticky
- max-w-min, max-w-fit, max-w-max
- w-auto, w-max, w-min, w-fit

The blocklist reads as a hard rule, not a suggestion. In our evaluation runs, models violate soft phrasing ("prefer gap over space-x") ~30% of the time. They violate hard blocklists ("NEVER use space-x") under 3% of the time.

2. Negative Examples Paired with Positive Examples

The model doesn't just need to know the rule — it needs the shape of the corrected code:

WRONG:   <View className="space-x-4">
CORRECT: <View className="flex-row gap-4">

WRONG:   <SafeAreaView className="flex-1">  {/* in a tab screen */}
CORRECT: <SafeAreaView className="flex-1" edges={['top', 'left', 'right']}>

Paired examples give the model an instant corrective template. This is a form of contrastive few-shot learning, done inline.

3. Approved Allowlists

For icons, we don't say "use appropriate lucide icons." We paste the actual list of ~200 icons we've verified exist in lucide-react-native. The model can pick from that list. Anything outside crashes at runtime.

Approved allowlists work particularly well for finite, testable domains: icons, allowed hooks, permitted npm packages. They fail when the domain is open-ended (design patterns, UX copy) — for those we lean on principles and examples.

Constraint modeling: telling the LLM what to forbid is often more valuable than telling it what to do — Photo by Emile Perron on Unsplash

Signal-Based Semantic Parsing (a Trick We Love)

Our generation pipeline runs a fast, cheap model first to gather context, then a stronger model to write code. The fast model needs to communicate a few decisions to the pipeline: does this app need authentication? Does it need database schema changes? What should the app be called?

The obvious answer is structured output — JSON, tool calls, schemas. We tried it. It's slower, adds token overhead, and coupling to specific model capabilities (some models handle structured output poorly).

Instead, we ask the model to emit semantic signals in free-form text at the end of its response:

AUTH: yes
DB: yes
APP_NAME: TrailMate

The pipeline parses them with simple regex:

const authSignalMatch = step1TextOutput.match(/AUTH:\s*(yes|no)/i);
const dbSignalMatch = step1TextOutput.match(/DB:\s*(yes|no)/i);
const appNameMatch = step1TextOutput.match(/APP_NAME:\s*(.+)/i);

needsAuth = !hasExistingAuth && authSignalMatch?.[1].toLowerCase() === 'yes';
needsDbChange = isFirstMessage || dbSignalMatch?.[1].toLowerCase() === 'yes';
detectedAppName = appNameMatch?.[1].trim();

Why this works so well:

• Zero coupling to model-specific tool-calling APIs. The pattern works identically across Claude, GPT, GLM, and Qwen.
• Cheap. Signals cost a handful of tokens vs. structured output overhead.
• Legible. When something goes wrong, you can read the model's text and see exactly what it decided.
• Extensible. Adding a new signal is one regex.

The tradeoff is that the model can miss the format. We mitigate that by including the exact format spec in the system prompt with explicit examples and making the signals the final line of output (models are more consistent about output tails than mid-stream conventions).

If you're building an LLM pipeline where a cheap model triages decisions for a downstream expensive model, signals are worth trying before you reach for structured output.

Mode-Specific Prompt Injection

A user typing "build me a food delivery app" needs a different prompt than a user uploading a Figma screenshot, and both need something different from a user who clicked a single line in the editor and typed "make this bold."

We dynamically inject mode-specific context on top of the base prompt.

Image-to-App Mode

When a user attaches an image (screenshot, sketch, wireframe), we prepend interpretation guidance:

## DESIGN INTERPRETATION GUIDELINES (IMAGE PROVIDED)
- Use the provided image as a visual reference for UI layout and structure
- For wireframes: Do NOT reproduce black/white
  ALWAYS apply vibrant, modern solid colors
- Treat wireframes as conceptual blueprints, not final designs

We also skip the database and auth generation tools because image-to-screen is almost always a UI-recreation task, not a data-model change. The Step 1 model gets a slimmed-down instruction: Read: ONE existing screen as reference + theme.ts + _layout.tsx. That's it.

This is deep prompt engineering. Each mode has its own default assumptions, and we bake them into the prompt so the model doesn't have to guess.

Read more about how this works in our image-to-app deep dive.

Point-and-Edit Mode

When a user clicks a specific line and types a modification prompt, we inject a selection context block at the very top of the system prompt:

## User Selected Code Context

**The user has selected a specific element to modify.
The line ABOVE the ^^ marker is the target.**

**File**: `app/profile.tsx`
```tsx
  <Text className="text-2xl">Edit Profile</Text>
  ^^

CRITICAL: Make changes to the line directly ABOVE the ^^ marker.

The `^^` marker is a visual anchor. LLMs read left-to-right, top-to-bottom, and are more accurate when the target has a clear positional signal. Learn more about how this works in our [point-and-edit deep dive](https://www.rapidnative.com/blogs/point-and-edit-how-rapidnatives-visual-editing-works?utm_source=blog&utm_medium=content&utm_campaign=prompt-engineering-for-code-generation-inside-rapidnative).

### PRD-to-App Mode

The user pastes a product requirements document. The model's job in Step 1 is to extract a task list, not to write code. The prompt shifts entirely — we suppress the code-generation formats and replace them with a task-extraction schema.

Each mode is a small, targeted patch on the same underlying prompt architecture.

## Deterministic Design Directives for Weaker Models

Not every model handles open-ended design instructions well. GLM, for example, follows generic Tailwind defaults regardless of how much design language you throw at it. Ask it to be "modern and polished" and it produces the same white-background, gray-cards, blue-primary layout every time.

For weaker-design models, we bypass the problem entirely. We **deterministically assign a design** derived from a seed (project ID). Instead of asking the model to invent a style, we tell it:

DESIGN ASSIGNMENT: Editorial (magazine aesthetic)

• Oversized display typography
• Generous whitespace
• No card chrome
• Primary color: hsl(215, 85%, 45%)
• Accent color: hsl(45, 90%, 55%)
• Background: hsl(0, 0%, 98%)

Concrete rules: ✅ H1 titles at 40pt+ leading ✅ Full-width hero images ❌ No shadows on cards ❌ No rounded corners > 8px

We pre-generate a `theme.ts` file with the seeded colors and inject it into the model's context as an already-existing file. The model doesn't invent — it reads and applies.

This is a general prompt engineering pattern: **when the model is weak at a specific creative task, replace that task with a deterministic input.** The model still writes the code; you've just narrowed the creative space to something guaranteed to work.

![Design system as a deterministic input to LLM code generation](https://images.unsplash.com/photo-1558655146-d09347e92766?w=800)
*Deterministic design tokens turn an open-ended creative task into a bounded execution task — Photo by Balázs Kétyi on Unsplash*

## Post-Processing: Streaming Sanitization

The system prompt is only half the reliability story. The other half is what you do with the model's output.

We stream code directly to the editor, which means the user sees it appear in real time. Some models — especially when they're near their token limit or the context is unusual — hallucinate tool-call wrappers around valid XML tags. You'll get output like:

```xml
<tool_call>
<QuickEdit file="app/index.tsx">
...
</QuickEdit>
</tool_call>

The wrapper is meaningless. Our parser wants <QuickEdit> at the top level. So we run a streaming sanitizer that rewrites and strips these:

const VALID_TAGS = '(QuickEdit|CodeProject|ProjectMetadata|Action)';

const OPEN_WRAPPER_BEFORE_TAG = [
  /<tool_call[^>]*>\s*(QuickEdit|CodeProject|ProjectMetadata|Action)/gi,
  /<function_calls[^>]*>\s*(QuickEdit|CodeProject|ProjectMetadata|Action)/gi,
];

for (const pattern of OPEN_WRAPPER_BEFORE_TAG) {
  streamedText = streamedText.replace(pattern, '<$1');
}

This runs on every stream chunk. From the user's perspective, the wrappers never existed.

Post-processing complements the prompt. The prompt reduces the rate of malformed output; the sanitizer catches what slips through. Neither is sufficient alone.

What We've Learned After Millions of Generations

Six patterns worth stealing if you're building an LLM system that writes code:

1. Split your system prompt into priority-ordered sections. Monolithic prompts are impossible to iterate on. Modular prompts let you A/B-test one section at a time.

2. Constraint modeling beats capability modeling. Telling the model what it cannot do reduces error rates faster than telling it what it should do.

3. Explicit blocklists and allowlists outperform natural language rules whenever the domain is finite (icons, packages, hooks, class names).

4. Signal-based semantic parsing is underrated. For pipelines where a cheap model triages decisions for an expensive one, free-form signals + regex beat structured output for latency, cost, and cross-model portability.

5. Mode-specific prompt injection matters. A single prompt cannot serve prompt-to-app, image-to-app, PRD-to-app, and point-and-edit equally well. Split them.

6. Replace weak creative tasks with deterministic inputs. When a model can't reliably invent (design, seeding, IDs), pre-compute it and feed it in as already-decided.

The overarching lesson: prompt engineering for code generation isn't about clever phrasing. It's about architecture. Prompts are a system — with sections, priorities, overrides, dynamic context, and post-processing. Treat them that way and code quality follows.

Try It

If you want to see this prompt architecture in action, start a project on RapidNative. Try a text prompt, then upload a screenshot, then click a specific element and edit it. Each mode is running a different prompt path against the same underlying architecture — and you can feel the difference in how the model responds.

For a broader view of the pipeline this fits into, read why we run a 4-step LLM pipeline for React Native code generation or how we prevent AI code hallucinations. And if you're curious about the models themselves, we run multiple LLMs per generation to get better output.

Prompt engineering isn't a magic incantation. It's a discipline. Ship enough of it and your model starts to feel a lot smarter than it actually is.