Six months on architecture, two hours on the AI redesign

By Malik Chohra

If you came for the "AI is so fast now" take, this is not it. A fast AI code refactor is real, but it is not magic. We migrated a whole React Native boilerplate to a new design system in two hours with Claude Code, and it worked because of the six months of architecture work that came first. The thesis: a two-hour AI redesign needs three preconditions, good AI indexing of the codebase, good architecture, and low tech debt. Strip any one out and the same AI run produces hallucinated imports, broken navigation, and a worse codebase by Sunday night. This is software architecture for AI, written from the agency side.

The steel-man we want to refute

To be fair to the take: models in 2026 have long context, agentic loops, and decent code synthesis. Point one at any codebase and you get a redesign in an afternoon. Devs post that screenshot every week. We have run that experiment dozens of times across our own repos and client codebases.

It works cleanly about one time in six. The other five it produces a good-looking patch that fails on render, or compiles but breaks navigation flows the AI never opened, or rewrites a Redux slice in a style that does not match the rest of the code. Impressive in a tweet, unusable in a product. The pattern is not "AI is unreliable." AI is exactly as reliable as the codebase it is reading.

What are the three preconditions for a fast AI redesign?

When the two-hour redesign actually works, three things are true at once.

1. AI indexing: the codebase is legible to the model

The boilerplate carries an architecture index, a tiered memory bank, and Claude Code skills that wrap the right context around each task. When we say "redesign onboarding to match the new tokens," the model does not scan four hundred files to find onboarding. It reads the architecture doc, the onboarding feature folder, and the theme tokens. Three files, not forty. This is the load-bearing precondition. Without it the model spends most of its context getting oriented and runs out of attention before the edit.

2. Architecture: predictable patterns and feature-first folders

Every feature folder has the same shape: api/, hooks/, screens/, components/, store/, typed utils. The naming is boring on purpose. use-onboarding.ts, not useOnboardingMagicFlow. The model does not need novel patterns, it needs the same pattern repeated so it can copy the shape with confidence. When every feature looks different, it guesses, and a large share of those guesses hallucinate.

3. Low tech debt: clean enough that AI can refactor without lying

This is the one we underestimated. A codebase can be well-indexed and well-structured and still produce bad AI output if it carries "we will fix this later" debt underneath. Dead components, two versions of the same util, a renamed feature whose old folder still exists. The model reads all of it and cannot tell which file is canonical. It will sometimes import the dead version. Low tech debt is not aesthetic, it is the difference between AI as a refactor partner and AI as a hallucination machine. We spent the last six weeks of the six months mostly deleting things. The two-hour redesign was unlocked by the deletions, not the additions.

What did the two-hour run actually look like?

The task: migrate the boilerplate from the original theme to a new design system. Roughly 60 components, new spacing scale, new typography, across 47 screens and 13 features. About 380 component touchpoints.

1. Loaded the design-system spec into plan mode.
2. Asked Claude Code for a migration plan against the design-system doc.
3. Reviewed it and pushed back on the two steps where it had misread the spacing scale.
4. Ran the plan one feature at a time, scoping each batch with a skill.
5. Ran typecheck and tests after each feature. Three failures, all caught and fixed in the next iteration.

Two hours, 380 touchpoints, three caught regressions, zero production hallucinations. The run is not impressive in isolation. It is impressive because of what was underneath it.

Why most "AI redesigned my app in an hour" posts ship worse code

The mechanic is simple. The poster runs AI against a codebase that has not had the six months of work done. The model produces something that looks correct. The poster lacks the test coverage, the type discipline, and the structural memory to catch what broke. The screenshot ships, the repo collapses three weeks later. We have run this on two client codebases that asked us to "just run Claude on it and see." Both produced roughly 40% hallucinated changes. Skipping the architecture work feels like saving time. It costs more time later.

What still does not work, even with all three

Honesty section. The two-hour run was structurally a rename-plus-restyle task, which is the shape AI wins on right now. These still cost real engineering hours:

• Cross-feature refactors with implicit dependencies. If feature A subscribes to a slice feature B mutates, AI often misses one side.
• Animation logic tied to layout measurements. AI invents effect chains around onLayout that look right and run wrong. We do these by hand.
• Hermes-specific quirks. Streaming, polyfills, MMKV edge cases. Thin training data, confident guesses, silent breakage.
• Real payment entitlement wiring. Dashboard IDs versus code strings is a bug AI cannot see, because it cannot read the dashboard.

The honest takeaway

The pitch we see most is "use AI, ship faster." It does not survive contact with a production React Native codebase. The pitch that holds: AI is a multiplier on architecture you already paid for. Good architecture, AI compounds it. Bad architecture, AI accelerates the decay. This is what our AI Mobile Launcher boilerplate ships with, the indexing, the architecture, and the debt hygiene already in. You can build all three yourself. You can also start from a base where they are wired in. The free tier is on aimobilelauncher.com if you want to read the structure first.

FAQ

Why does AI fail on most React Native codebases?

The failures cluster around three missing preconditions: codebase indexing, predictable architecture, and low tech debt. Most repos miss at least one. The model produces confident-looking patches that break in non-obvious places because it cannot tell which file is canonical, which pattern is current, and which dependency is dead. The fix is not a better model, it is the codebase.

Is "AI redesigned my app in an hour" real?

Sometimes. The runs that work are the ones where the codebase was already structured for AI before the prompt ran. The runs that do not work get screenshotted, posted, then quietly abandoned when the diff hits review. Selection bias favors the wins.

What is software architecture for AI?

It is structuring a codebase so a model can read it cheaply and edit it safely: an architecture index the model can load, feature-first folders with repeated patterns, and low tech debt so there is one canonical version of everything. Those three together are what turn AI from a hallucination source into a refactor partner.

Can I add the three preconditions to an existing codebase?

Yes, but it is unglamorous. Audit dead code, standardize feature folder shapes, write the architecture index, install the skills. It took us six months on a codebase we knew well. On one we did not write, expect longer. That work is exactly what we do on client engagements, see our React Native and Expo development service.

Is this just a pitch for a boilerplate?

The thesis stands without it: AI leverage needs architecture, indexing, and clean code as preconditions. You can build all three yourself or start from a base where they are wired in. We make the preconditions explicit so the next "I redesigned my app in two hours" post does not mislead the next dev who tries it cold.