AI Pair Programming: A Practical Guide for React Native

You're halfway through an Expo feature when the AI assistant confidently adds a package your app doesn't use, imports a nonexistent navigation type, and rewrites a working hook to solve a problem you never had. The screen looks polished in the editor. The pull request is another story.

That tension defines AI pair programming for React Native teams. An AI assistant can draft screens, handlers, tests, and repetitive state logic at remarkable speed, but it can also move effort into review, device testing, debugging, and merge coordination. After shipping three Expo apps with AI in production, I've found that the useful question isn't whether the model writes code quickly. It's whether the team ships a correct, maintainable feature with less total friction.

Table of Contents

• A Morning With an AI Pair Programmer
• What AI Pair Programming Actually Is
• The Tools React Native Teams Use in 2026
  • GitHub Copilot
  • Cursor
  • Claude Code and editor plugins
• Building a Real Expo Feature With AI Assistance
• How AI Pair Programming Fits Into an Opinionated Stack
  • Rules that encode engineering decisions
  • Context that matches the repository
  • Small tasks with known seams
• When AI Pair Programming Slows You Down
• Prompt Patterns That Work for React Native
  • Start with repository context
  • Put authorization in the prompt
  • Tell the model what not to decide
• Security, Privacy, and Metrics for a 30-Day Rollout
  • Guardrails first
  • Measure the whole workflow

A Morning With an AI Pair Programmer

At 9:05, Priya opens an Expo monorepo and points Cursor at an existing Supabase schema. The task looks ordinary: add a push-notification preferences screen to an app running Expo SDK 54, protect it behind the existing auth flow, and let users opt out of selected notification categories.

She starts with Claude Code rather than asking for a finished feature. The first prompt includes the relevant Expo Router segment, the notification table shape, the existing settings screen, and the team's conventions. Claude Code proposes the file layout, a screen component, a query hook, and a small preferences row component. Priya accepts the styled component after checking its imports and accessibility props.

The first miss appears immediately. The model imports a utility from a path that exists in another project but not this repository. A second suggestion uses an Expo Router type that doesn't match the app's route structure. Neither mistake is dramatic, but both are plausible enough to waste time if they reach review.

Next, Priya asks GitHub Copilot to write the patch for the opt-out API call. Copilot fills in the request body, adds a mutation, and suggests an optimistic update. The implementation is close, but the rollback path doesn't account for a failed network request after the local cache has already changed. Priya rewrites that part before opening the pull request.

The editor felt faster. The complete delivery loop was more measured. A controlled GitHub experiment, later published through Microsoft Research, found that developers using an AI pair programmer completed a JavaScript HTTP-server task 55.8% faster, with timing of 1 hour 11 minutes versus 2 hours 41 minutes for the control group, as documented in this summary of the GitHub Copilot productivity experiment. That result measured an end-to-end coding task, which made it more useful than a survey about how productive people felt.

The practical boundary: AI can accelerate typing and exploration, but the team still owns the code at the PR, device, and production boundaries.

Priya's morning ends with a manual review, a physical-device check, and a request to split the API and UI changes into separate commits. The turbo button worked, but only because a senior engineer kept steering.

What AI Pair Programming Actually Is

AI pair programming is a directed, iterative feedback loop between a developer and a model. The developer supplies context, constraints, and intent. The model proposes implementation, explains choices, runs or interprets checks when it can, and revises its work after feedback.

That's different from autocomplete. Autocomplete is closer to an autopilot offering the next line while the route is already set. AI pair programming is a copilot relationship. You're still steering the aircraft, deciding where it should go, and checking whether the instruments make sense. The model can draft a route, but it doesn't own the destination.

A reliable loop looks like this:

1. Provide context. Include the files, types, API contracts, framework version, and relevant constraints.
2. Ask for a plan. Let the model identify affected files and unresolved decisions before it edits code.
3. Generate a small change. Keep the task narrow enough that you can understand the entire diff.
4. Review the proposal. Check imports, data flow, security assumptions, platform behavior, and error paths.
5. Refine with evidence. Feed back compiler errors, test failures, screenshots, and observed runtime behavior.
6. Commit a comprehensible result. Don't commit code you can't explain.

A diagram outlining the six steps of AI pair programming as a collaborative software development workflow.

The loop excludes several responsibilities. Architecture, product judgment, security ownership, and correctness remain human decisions. An AI can suggest an RLS policy, but it shouldn't decide who may read another user's data. It can generate a navigation segment, but it can't know whether the product should expose that route to signed-out users.

This is why I treat AI pair programming as a development discipline, not a feature checkbox. Test-driven development uses tools, but the framework isn't the discipline. The discipline is writing an executable expectation, implementing against it, and responding to evidence. AI pair programming works the same way. The model is useful when the engineer creates a tight feedback loop.

Tool choice affects how much context you can provide and how easily you can review changes. If you're evaluating products rather than adopting the first familiar extension, this hands-on guide to compare AI coding tools 2026 is a useful reference point.

The Tools React Native Teams Use in 2026

React Native teams usually evaluate four practical categories: GitHub Copilot, Cursor, Claude Code, and editor plugins such as Continue or Cody. The right choice depends less on abstract model rankings than on where the developer works, how much repository context the tool can inspect, and whether the team needs inline suggestions or multi-file changes.

GitHub Copilot

Copilot fits teams already standardized on GitHub, VS Code, JetBrains, pull requests, and Microsoft administration. It works well for repetitive hooks, test scaffolding, type transformations, and localized fixes. It's also a sensible organizational default when developers need a consistent experience instead of each engineer selecting a separate agent.

GitHub and Accenture reported that Copilot helped developers code up to 55% faster, while 85% of developers felt more confident in code quality, in their 2024 enterprise update. A separate GitHub summary reported that 88% of surveyed developers felt more productive and 96% felt faster on repetitive tasks, as described in the GitHub and Accenture enterprise research. These are meaningful signals, but they still don't remove the need to inspect the resulting PR.

Cursor

Cursor is my default for day-to-day Expo work because its multi-file indexing makes it easier to trace a feature through route files, hooks, schemas, and shared components. That matters in an Expo monorepo where a screen may depend on a package several directories away. Its main cost is workflow fragmentation if the team relies heavily on JetBrains or doesn't want another editor in the toolchain.

Teams exploring structured editor workspaces can also look at this AI-ready interface dev experience for ideas about how context and workspace conventions can be presented.

Claude Code and editor plugins

Claude Code is particularly useful for larger refactors, codebase archaeology, and tasks that require reasoning across an AppLighter-style structure. I use it to inspect a feature boundary, propose a migration sequence, and identify tests before making edits. The terminal workflow also makes it natural to run project commands and feed actual failures back into the conversation.

Continue and Cody-style plugins make sense when privacy, model choice, or self-hosted inference matters more than a polished default workflow. They can be powerful, but the team owns more configuration, provider management, indexing behavior, and prompt maintenance.

For teams starting from a prepared mobile foundation, AI code generation tools provides useful context on how these assistants fit into a broader app-building workflow. My recommendation is simple: start with one tool, measure the complete PR workflow for a month, then add a second tool only when it solves a clearly observed bottleneck.

Building a Real Expo Feature With AI Assistance

Consider an auth-gated profile screen that reads a Supabase profile row and calls a Hono edge route to follow another user. The mobile layer uses Expo Router, TanStack Query, React Hook Form, and Zod. The AI can draft most of the connective tissue, but the engineer must define authorization and failure behavior first.

I'd begin with a prompt like this:

“Inspect the existing Expo Router auth layout, Supabase client, and TanStack Query conventions. Propose the files needed for an authenticated profile screen. Don't edit code yet. Identify the RLS assumptions, route protection, offline behavior, and loading states.”

Once the plan is sound, I'd ask Cursor to scaffold the route segment and Claude Code to implement the server handler. A simplified Hono route might look like this:

import { Hono } from "hono";
import { z } from "zod";
import { createClient } from "@supabase/supabase-js";

const followSchema = z.object({
  userId: z.string().uuid(),
});

const app = new Hono();

app.post("/follow", async (c) => {
  const authHeader = c.req.header("Authorization");
  const token = authHeader?.replace("Bearer ", "");

  if (!token) {
    return c.json({ error: "Unauthorized" }, 401);
  }

  const supabase = createClient(
    c.env.SUPABASE_URL,
    c.env.SUPABASE_ANON_KEY,
    { global: { headers: { Authorization: `Bearer ${token}` } } }
  );

  const parsed = followSchema.safeParse(await c.req.json());

  if (!parsed.success) {
    return c.json({ error: "Invalid request" }, 400);
  }

  const { data: user } = await supabase.auth.getUser(token);

  if (!user.user) {
    return c.json({ error: "Unauthorized" }, 401);
  }

  const { error } = await supabase.from("follows").insert({
    follower_id: user.user.id,
    following_id: parsed.data.userId,
  });

  if (error) {
    return c.json({ error: "Unable to follow user" }, 500);
  }

  return c.json({ ok: true });
});

export default app;

The schema itself stays explicit:

const followSchema = z.object({
  userId: z.string().uuid(),
});

On the client, I'd ask the assistant to use the project's existing token utility rather than inventing a new auth abstraction. If the app uses Secure Store, the read might be:

import * as SecureStore from "expo-secure-store";

export async function readAccessToken() {
  return SecureStore.getItemAsync("access_token");
}

I'd keep the service-role key out of the mobile app and out of prompts. I'd also decide manually whether an offline-first action should queue, fail visibly, or remain disabled. The AI can implement that decision, but it shouldn't make it.

For the screen, I'd ask for a TanStack Query mutation with an optimistic update, then review the cache key and rollback behavior line by line. The assistant produced a usable first pass in my workflow, but it missed a loading state and introduced an optimistic update race condition. Those issues appeared during PR review, not during code generation.

For adjacent patterns such as streamed server responses, this guide to streaming AI responses in React Native is a useful implementation reference.

Screenshot from https://applighter.dev/img/ai-pair-programming-expo-feature.png

The final workflow is deliberately unglamorous: run type checks, exercise the route with an expired token, test the screen on iOS and Android, inspect the network behavior, and review the diff as if another engineer wrote it. AI assistance ends when the change becomes understandable and verifiable.

How AI Pair Programming Fits Into an Opinionated Stack

A blank repository forces the developer and the AI to solve too many unrelated problems at once. Before the model can implement a profile feature, it has to infer routing conventions, authentication boundaries, database access patterns, environment handling, styling rules, and build commands. Every missing decision becomes an opportunity for plausible but incompatible code.

An opinionated starter stack reduces that setup tax by making the repository legible. In an AppLighter-style Expo project, I'd want three layers of guidance.

Rules that encode engineering decisions

Claude Code rules files can state the Expo and React Native conventions the team has already chosen. That includes the New Architecture posture, EAS Build profiles, OTA update rules, folder boundaries, error handling, and commands for linting and testing. Cursor workspace instructions can reinforce the same expectations where developers edit files.

These rules shouldn't become a huge encyclopedia. They should answer the questions the assistant repeatedly gets wrong. If the app uses a pinned Expo SDK, the rules should state that clearly and tell the agent to inspect the existing package versions before suggesting an upgrade.

Context that matches the repository

Plugins and workspace configuration can point the assistant toward the files that matter. A route handler should live where the project expects route handlers to live. A Supabase query should follow an existing typed client pattern. A new provider should use the established state-management boundary rather than creating a second store.

Pre-wired auth through Supabase, Hono, and Expo Router gives the model examples to imitate. It doesn't guarantee correct output, but it replaces guesswork with local evidence.

A diagram illustrating how AI pair programming integrates into an opinionated software development stack to improve outcomes.

Small tasks with known seams

The biggest benefit comes from boundaries. If authentication, navigation, API calls, and UI state each follow a recognizable pattern, the engineer can ask the AI to extend one seam at a time. That makes review faster because the expected change is narrow.

AppLighter is one option for teams that want an Expo and React Native foundation with preconfigured authentication, navigation, state management, Hono and Supabase integration, plus Claude Code rules and Cursor-oriented tooling. The value for AI pair programming isn't that it removes engineering judgment. It gives the assistant a structured codebase in which that judgment can be applied consistently.

When AI Pair Programming Slows You Down

The most misleading productivity metric is the time between opening a file and accepting a suggestion. A model can produce a component quickly while increasing the work required to understand, test, and merge it.

The learning trade-off deserves attention. A controlled 2026 study of 22 participants found that developers performed better with GitHub Copilot than with a human teammate, but the AI-assisted condition also showed lower retest performance and more negative learning signals, according to the controlled study of AI pair programming and developer learning. For junior engineers, copying a working answer can conceal the reasoning they need to retain.

End-to-end delivery can also reverse the apparent gain. Research summarized in a 2025 to 2026 reality check reported one study where tasks took 19% longer overall, while another found AI-assisted developers implemented issues in 19% more time and experienced slower review and merge steps, as discussed in this analysis of AI coding assistant delivery friction.

React Native adds its own traps. AI-generated native changes need real device testing. Hermes and JSC differences can expose runtime assumptions that static analysis misses. A large PR full of generated boilerplate may pass type checks while making the reviewer reconstruct an architecture the author never intended.

Measure PR cycle time, defect escape rate, and junior learning velocity, not keystrokes. The question is whether AI produces a measurably better shipped product for this team.

Prompt Patterns That Work for React Native

Pasting a component into a chat and asking for “production-ready code” produces generic code. React Native projects need constraints that distinguish a working web-style answer from a change that respects Expo, navigation, native runtime, and backend security.

Start with repository context

Name the Expo SDK version, package manager, route file, existing imports, and the component or hook to extend. Ask the model to inspect neighboring implementations before it creates a new abstraction.

“Use the existing Expo SDK and package versions. Modify app/(protected)/profile/[id].tsx. Reuse the current Supabase client and query-key factory. Don't introduce a new state library or dependency. Show the plan before editing.”

Call out platform behavior explicitly. Mention Platform.OS branching, FlatList key extraction, keyboard handling, safe areas, and Reanimated worklets when those details matter. A model may know these APIs, but it won't know which constraints your app has unless you state them.

Put authorization in the prompt

For a Hono route, ask for JWT validation, input validation, and an authorization path that preserves Supabase RLS:

“Implement a Hono edge route for following a user. Validate the Supabase JWT from the bearer token, parse the body with Zod, use the caller's identity for follower_id, and never use a service-role key in client code. Return explicit responses for missing auth, invalid input, and database failure.”

For a TanStack Query mutation, specify the cache behavior:

“Create a mutation for following a user. Snapshot the prior follow state, apply an optimistic update, roll back on failure, invalidate the related profile query after settlement, and prevent duplicate submissions while pending.”

Tell the model what not to decide

A short exclusion list prevents dangerous improvisation:

• No secret handling: Don't paste service-role keys, signing secrets, or private environment values into the prompt.
• No native shims: Don't replace a missing native module with a guessed JavaScript fallback.
• No build changes: Don't alter EAS profiles, OTA configuration, entitlements, or permissions without a separate review.
• No policy invention: Don't create RLS policies without describing who may read and write each row.

For forms, provide the expected contract:

“Build a reusable React Hook Form component using the existing Zod schema. Preserve server-side error messages, disable submission while pending, expose accessible labels, and match the neighboring form's styling and keyboard behavior.”

The iteration loop is short: review, reject, refine, then accept. Ask for a diff, inspect it, run the checks, and make the final merge decision yourself.

Security, Privacy, and Metrics for a 30-Day Rollout

Adopting AI pair programming safely requires guardrails before enthusiasm. Start by deciding what code and data may enter the provider, then make the assistant operate inside the same review and CI controls as every other contributor.

Guardrails first

• Protect source code: Review provider retention and telemetry settings, disable optional telemetry where policy requires it, and audit shared chat history.
• Keep secrets out: Never paste Supabase service-role keys, JWT signing secrets, production tokens, or customer records into prompts. Rotate any credential that was exposed.
• Control dependency drift: Ask the assistant to inspect the lockfile and installed Expo versions before suggesting packages. Review every native dependency because a seemingly small addition can affect builds and permissions.
• Separate sensitive workloads: If the app handles health or financial data, confirm contractual privacy terms, enterprise controls, and applicable obligations before enabling AI access to the repository.
• Document the boundary: Your team's user data protection guidance should cover prompts, logs, crash reports, and generated code, not just the mobile database.

A practical security review can also include DevArmor's discussion of agentic development safety, especially when an agent can read files, execute commands, or open pull requests.

Measure the whole workflow

Record a baseline before enabling the assistant. The baseline doesn't need fabricated targets. It needs the team's actual current behavior and a clear comparison point.

Use the first half of the rollout to configure rules, permissions, secret handling, dependency policies, and review expectations. Use the second half to compare delivery outcomes and interview reviewers. GitHub's survey evidence shows that developers often report productivity and speed improvements, while the controlled learning and delivery findings above explain why subjective confidence shouldn't be your only decision signal.

Ship the approach into a second measurement period if PR cycle time improves while defect rates hold and juniors can still explain their changes. Pause and redesign the workflow if generated code increases merge friction or junior engineers stop learning the underlying patterns.

---

AppLighter gives Expo teams a prepared foundation with authentication, navigation, state management, Supabase and Hono integration, plus AI-oriented rules and tooling that make repository context easier to use. If you want to apply the workflow without starting from a blank mobile codebase, visit AppLighter and evaluate it against your next production feature.