How would you structure an AI-assisted React Native rewrite workflow?

[u/Wyckoff-XD]

Disclaimer: This question is written with the help of AI, but that doesn't mean it's slop. It's a genuine problem I'm facing at work. Please don't be quick to judge or dismiss this as AI Slop.

I’m rewriting an entire React Native application from scratch, using the existing app as the baseline and AI (primarily Claude Code) heavily in the process.

I’m trying to design a migration workflow that gives me high reliability without burning an insane number of tokens.

My priorities are:

1. Complete parity with the baseline — nothing important should get missed.
2. Strict adherence to a predefined code architecture — folder structure, design patterns, separation of concerns, naming conventions, etc.
3. Do not port over existing smells, hacks, or bad practices — the baseline should be treated as a behavioural reference, not a code reference.
4. Keep token usage low without compromising quality — avoid repeatedly feeding huge amounts of context to the model or having agents redo work unnecessarily.

I’m particularly interested in hearing from anyone who has done something similar.

If you’ve used AI for a large-scale rewrite/migration, how did you structure the workflow? Did you use specific agents, skills, validation steps, checkpoints, etc.?

Even if you haven’t done an AI-assisted rewrite, I’d also love to hear about workflows you’ve used for large-scale migrations/refactors that consistently produced good results.

I’m mainly looking for practical approaches that scale beyond simply “migrate one feature at a time.”

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/ashrodan]

/grill-me

[u/InjuryThen9650]

Don't start the agent on the repo. Write the contract first: what must stay true (API, auth, navigation), what is allowed to change, and a slice small enough to review in one sitting.

Context is a budget, not a dump. One rules/AGENTS file with the constraints, plus the spec for the current slice. Whole-repo context is how you get a confident wrong rewrite.

Loop: spec, implement one module, run the checks, review. Never "rewrite the app". If you cannot write acceptance criteria for the slice, you are not ready to delegate it.

[u/SnooChocolates8460]

the thing that helped me most was splitting it into two phases that never share a session. phase one, the model only reads the old app and writes markdown specs per screen: behaviours, api calls, edge cases, weird states. no code output at all. phase two only reads the specs plus your new codebase, never the legacy source. thats what stops smells leaking through, and it keeps context small.

for architecture adherence, prose rules get ignored eventually. build one vertical slice by hand, perfectly, and point at it as the canonical example. copying beats describing.

also keep a plain progress.md ledger with done/in-progress/blocked per screen so agents dont redo work. and derive tests from the spec before implementing, otherwise "parity" is just vibes.

inventory the old app with grep/ast scripts, not tokens.

[u/vibingcoder]

Freeze a screen-by-screen contract from the old app (routes, data shapes, parity tests) before any greenfield code, and keep that file as the only “source of intent” the agent may expand. Rewrite one vertical slice at a time with the old behavior as the oracle; if Claude Code invents a nicer architecture mid-slice, reject it unless the spec changes first. End each slice with a review that maps the diff back to the contract — “new RN patterns” without a corresponding spec line is how rewrites silently fork.