You can read more about the whole journey here

Unfortunately, I didn't get to see the whole site go live. The exercise taught me that businesses no longer have to put up with poorly functioning legacy codebases that teams are too scared to touch. A complete rewrite does not have to shut down your business.

We could take the analysis from the first set of agents, and with a carefully crafted set of rules, recreate whole pages with @claudeai and easily test that it worked in the same way as the old site.

As we weren't changing any functionality, and used the same backend, we could work on any page we liked - using the old site and existing data. Being able to work on pages without relying on others being created first unlocked parallel velocity

The data design approach was to work backwards from the API calls made on submitting actions then use the same types generated from heyapi as local state.

The stack I chose used @bunjavascript, @vite_js, @tan_stack query, router, and form, @UntitledUI over shadcn, and heyapi created by @mrlubos. Open API codegen saved us a tonne of time.

I set the project up as a client side only React app. We already had multiple backend servers, and the last thing we wanted was another one. I’ve also found limited benefit in using SSR given how amazing the @tan_stack client side tools are.

The better approach was to have Claude analyze the code, then describe the functionality and content of the old site textually. It described components and what they did rather than how they looked. Claude then made better choices when creating new pages.

My first approach was to use Playwright MCP to click around to recreate the experience. This worked “ok”, but when I tried using the using screenshots to prompt Claude to create a version in React, it was hard to prevent it from recreating the old UI pixel by pixel.

A lot of knowledge is stored in legacy code bases – years of small adjustments that evolve the product. It sounds easy, but properly replicating functionality is hard in a rewrite.

This is how @DrizzleORM describes itself in the docs "Drizzle is a good friend who’s there for you when necessary and doesn’t bother when you need some space."

This is a great addition. Before this I was creating specialised agents (like a Tanstack Form specialist) as rules became too long. Skills will replace that. Awesome work @adocomplete

Bun is a beautiful piece of engineering. On top of that, @jarredsumner and the team properly listen to the community and target what’s important. It’s going to get bigger and bigger over the coming years

The next stage would be to fully analyse the current app page by page and scaffold the new one.

Success would be defined as: ✅ Every bit of functionality from the old app was in the new ✅ The new code was clean, lightweight, and performant ✅ Having extensive storybook and test coverage

The plan was: - Split the new app from Express. Keep using it for auth - Use the latest API given it had an OpenAPI spec - don't change the backend - Recreate the whole app with a modern component library - Leverage AI as much as we possibly could to build it.

The frontend itself was split into 5 apps - a mix of Angular and Vue.js. If a refactor takes too long, business pressures get in the way. It was clear that if we were going to succeed, we had to keep the project short, defined, with clear outcomes.

However, there were 3 versions of API - the oldest of which talked to a “second backend” on the express server itself.

Looking at the codebase it was a tale of broken dreams - all working together in beautiful harmony. 😇 At the heart of it was an Express server that: - “Served” the frontend - Handled auth - Proxy’d API calls to the backend 👇

Finally