Rewriting a Live Web App from Angular to React in 7 Weeks With AI Agents

Introduction

In April we froze our Angular app. About seven weeks later the whole product was running on React and Vite. The people using the product never saw a maintenance window, and they were spread across 24 languages the entire time.

This is a build log, not a sales page. I am going to show you what we actually did and where it got hard, with the real numbers. I am writing it because most rewrite stories skip the messy parts, and the messy parts are the useful parts.

What you'll learn:

• Why we moved off Angular and what we moved to
• How we rewrote the app while real users kept using it
• How a team of AI coding agents let a small team move this fast
• The guardrails we added, and the mistakes that caused each one

---

Where we started

We had a web app built on Angular. It worked, and it had years of features in it. The problem was speed. Every change took longer than it should have, and the framework was the reason. We could not build the kind of product we wanted on it.

The app was not small. It was a large, mature web app, built up over seven years and shipped in 24 languages, with years of features and only limited test coverage. Some parts of it had grown very large and hard to change. This is the kind of app that is slow to change and risky to rewrite, which is the whole reason the next part matters.

We decided to rewrite it on React 19 and Vite. React is a library for building user interfaces. Vite is the tool that builds the code and serves it during development. We also chose a clear structure for the new app:

• We group code by feature, so everything for one part of the product lives together.
• We use TanStack Query to handle data that comes from the server.
• We use Tailwind for styling.
• We use React Router to handle pages.

If you want the deeper version of how we think about structuring this kind of system, I wrote about it in production-ready AI agent architecture.

Staying live the whole time

The usual risk with a rewrite is that you stop shipping while you do it. Teams go quiet for months, and the business suffers. We did not want that.

So we kept the old Angular app running in production the whole time. We built the new React app next to it, and we moved people over piece by piece. Real users kept working in the product every day while we rebuilt it underneath them. The old app served production traffic until the new one was ready to take over.

This is the part I am most proud of. There was no big switch day where everything could break at once. There was a slow handover instead.

The part that made it fast

Here is the honest reason we could move at this pace. I gave my AI coding setup a full engineering team.

I use Claude Code, which is a coding agent you run in your terminal. Most people use it as a single helper. I set it up as a group of agents that work together instead.

There is one lead agent that I talk to. Under it there are 16 specialist agents, and each one has a single job. A few examples:

• One plans the work before any code is written.
• One reviews the code after it is written.
• One writes the tests.
• One checks for security problems.

No code gets written until the planning agents agree on a plan. After the code is written, it has to pass review and tests before it can become a pull request. If you want to understand the general idea behind running many agents together, I covered it in AI agent orchestration and multi-agent systems. I also wrote about the skills that make each agent good at one job in Claude Skills and new AI agent capabilities.

You can see the result in the commit history. For the first three months of the year we averaged about 80 commits a month on the app. In April that jumped to over 1,600. In May it was about 1,100. In one week we merged 197 pull requests.

The rules we added after mistakes

Speed without structure is dangerous, so I added hard rules that the agents have to follow. Each rule came from a real mistake.

One example. Early on, a script with a secret written into it got committed by accident. That is a serious problem, because a secret in your code history can be used by anyone who finds it. After that, I added a rule that blocks any credential from ever being committed, and the agents check for it every time.

There is a second kind of rule about process. At one point some code reached a pull request without going through review first. So now the pipeline will not create a pull request until the review step and the test step have both passed. The rule is simple, and it removes the chance of a tired human skipping a step.

I think this is the real lesson. AI agents will move as fast as you let them. The value is not the speed on its own. The value is the speed plus the rules that keep it safe.

What I would tell you if you are about to do this

• A rewrite does not have to mean a pause. You can run the old app and the new app at the same time and move people over slowly.
• Pick your structure before you write feature code. We set up the structure and the rules before any feature work, and that saved us later.
• If you use AI agents, give them one job each and a pipeline to move through. A single agent doing everything is harder to trust than a small team of focused ones.
• Write down a rule every time something goes wrong. Over a few months those rules become the thing that lets you go fast without fear.

Conclusion

The rewrite is finished, and the way we build now is not the way we built at the start of the year. The agent setup and the written rules are not a side experiment. They are how the code gets written.

Further Reading

• From prompts to an AI engineering team
• Production-ready AI agent architecture
• Designing a product AI agents can use
• Context engineering versus prompt engineering