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.”

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.”

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.”

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.”

TL;DR: We’re 30% into a 150k–200k LOC React Native rewrite with 2 months left. We need very high agent usage. Should we go Claude, Codex, or both? Main concerns are usage limits, model quality, context windows, and whether moving our Claude-specific workflow to something like Hermes is worth the complexity.

I know this is a bit detailed, but please bear with me and read the full post if you’ve used both tools extensively. I’m specifically looking for real-world experience with large codebases.

We’ve completed ~30% of the rewrite and need to finish the remaining 70% within 2 months.
Previously, we used Claude Enterprise with API pricing. I personally spent around $400/day, while the other developers spent roughly $400/day combined.

Our current workflow is heavily built around Claude Code:
Fable designs the implementation plan and reviews the work for architectural adherence and code quality.
Opus handles almost everything else.
We also use skills, subagents, hooks, and a predefined workflow.

I’m now planning to buy 2×20x + 2×5x individual plans. My intended allocation is:
20x: Me — business logic migration
5x: Developer 1 — UI migration
5x: Developer 2 — UI migration
20x: Backup — used by whoever hits their usage limit

The questions I’m trying to answer:

How is Opus 5 actually performing for large migrations? I’ve seen mixed feedback recently.

Usage limits: We’ll be using agents extremely heavily, potentially round the clock. Does Codex actually provide significantly more usable capacity than Claude?
Model quality: Everyone talks about GPT-5.6 Sol, but how do the other Codex models compare to Opus-level models? Specifically, how does GPT-5.6 Terra compare to Opus 5?
Context: Claude has a 1M-token context window. Since rewrites are extremely context-heavy, are Codex’s lower context windows sufficient in practice for large migrations?
Usage economics: Given our previous ~$800/day combined API usage, can Max 20x / Pro 20x realistically handle comparable usage without constantly hitting limits?
Using both: Our workflow is currently Claude-specific. How difficult is it to make it genuinely cross-compatible? Is moving it to something like Hermes worth doing?
I’m not interested in using both simply for redundancy. I’d only accept the additional workflow complexity if using both produces a significant enough improvement in performance/capacity to more than justify that complexity.

For people who have actually used both extensively:
What would you choose in our situation—Claude, Codex, or both? And would you keep this allocation or structure the accounts differently?

Real-world experience with large migrations, sustained usage, context limitations, workflow compatibility, and code quality is much more useful to me than benchmark scores.

Edit:
Following is the migration workflow that I’ve created.

Skills and the subagents they invoke

migrate-feature

Runs the complete behavioral migration:

1. Recover behavior → feature-context-gatherer — traces the legacy baseline and writes the behavioral brief. (Opus, high)
2. Check the brief → brief-critic — independently finds missing rules, branches, APIs, and side effects. (Opus, high)
3. Resolve open questions with the user.
4. Design implementation → implementation-designer — produces the code-level architecture, file plan, data flow, and deviations. (Fable, xhigh)
5. Critique the design → design-critic — finds bad abstractions, unnecessary complexity, and unsafe behavioral changes. (Fable, xhigh)
6. Get user approval, then run scaffold-feature.
7. Build domain, data, application, and presentation layers.
8. Write tests throughout → test-author — creates branch-complete behavioral tests without weakening assertions. (Opus, xhigh)
9. Mid-build checkpoint → architecture-reviewer — catches correctness, dependency, and complexity problems early. (Fable, xhigh)
10. Audit parity → parity-auditor — compares every observable behavior against the baseline. (Opus, xhigh)
11. Run the external simplification skill.
12. Final review → architecture-reviewer. (Fable, xhigh)
13. Write docs via document-feature → feature-doc-writer — documents the final architecture, data flow, and public API. (Sonnet, medium)
14. Consistency sweep → consistency-auditor — detects duplicated concepts, pattern drift, and unnecessary cross-module complexity. (Opus, high)

Multi-pass features run this per pass, followed by full-feature parity and architecture audits during finalize.

plan-feature-passes

Prepares a large feature for incremental migration:

1. Create the master brief → feature-context-gatherer — recovers the complete baseline behavior. (Opus, high)
2. Check completeness → brief-critic — identifies anything the brief missed. (Opus, high)
3. Split into passes → feature-decomposer — creates ordered, non-overlapping passes with complete coverage. (Opus, medium)
4. User reviews and approves the manifest.

migrate-screen-ui

Migrates one screen’s presentation without changing business logic:

1. Select Figma or baseline code as the source.
2. Code mode only → ui-scout — creates a salvage sheet covering states, behavior, reusable UI, and open questions. (Opus, xhigh)
3. Write the UI wiring and design-system plan.
4. Build required primitives through ds-primitive.
5. Write screen tests → test-author — tests states, interactions, and application-layer wiring. (Opus, xhigh)
6. Run the user visual checkpoint.
7. Verify → ui-verifier — checks visual/behavioral parity and presentation architecture in one audit. (Opus, high)
8. Write the screen documentation.

finalize invokes ui-verifier again for cross-screen transitions, consistency, and coverage.

plan-ui-passes

Plans a complete multi-screen UI migration:

1. Trace screens, states, overlays, and navigation.
2. Split into passes → ui-decomposer — creates an ordered UI manifest with complete surface coverage. (Opus, medium)
3. Collect required Figma links.
4. User reviews and approves the manifest.

ds-primitive

The controlled design-system write workflow:

1. Read the Figma or baseline source.
2. Write and approve the primitive specification.
3. New design system → ds-engineer — builds the approved primitive, variants, tests, stories, exports, and registry entry. (Opus, high)
4. Legacy design system → ds-salvager — consolidates scattered legacy UI into a reusable tokenized primitive. (Opus, xhigh)
5. Test and verify.
6. Review → architecture-reviewer — checks the primitive’s correctness, boundaries, and complexity. (Fable, xhigh)

scaffold-feature

Creates the empty layered structure, exports, query keys, test placeholders, and debt ledger. No subagent is invoked.

document-feature

Invokes feature-doc-writer — reads the completed implementation and writes concise architecture, data-flow, navigation, and public-surface documentation.
(Sonnet, medium)

new-adr

Creates the next numbered architecture decision record from the standard template. No subagent is invoked.