After Opus 4.5 came out, I migrated my 180k LoC project (generating real revenue from real customers) from a one-Postgres-schema-per-tenant to a shared-schema data topography and architecture where everything is under public and scoped by tenant_id. As one can imagine, this was a massive undertaking and required:
- a complex series of data migrations for 150+ tenant tables, grouped into levels, with each level ordered based on interdependencies
- post-migration data integrity checks and testing (make sure counts match, FKs match, etc. etc.)
- post-migration performance benchmarking scripts
- rewriting all the context modules and their queries to take and use
tenant_idinstead of a stringtenantprefix - modifying the controller contracts
- essentially rewriting the test suite, including factories and mocks
- a huge amount of manual testing
The migration also required changing integer PKs/FKs to uuids. The reason this had to be done was because we were previously using IDs as user-facing display numbers (e.g. Invoice #3829), and in the new system these had to be preserved. So the work also involved adding new tenant-scoped display_number columns that would contain the old schema-scoped integer IDs, making sure they auto-increment correctly moving forward, and rewiring everything accordingly.
The final diff was +50k -18k. You read that correctly: one branch, fifty thousand lines added, eighteen thousand removed or changed. About 15k of the new lines were documentation, plans and Ecto migration files. The rest were new code and new tests.
Without AI, this would have taken me multiple months and there’s a good chance the sheer scale and tediousness of it (as well as the risks) would have burned me out. I also would not have been able to add new features easily. Especially because I have a full-time job.
With Opus 4.5, it took two and a half weeks (mostly evenings and weekends). I read every line of documentation/plan it wrote, every line of code change that it made and tested everything thoroughly, both manually and also using ancillary AI chat sessions where I intentionally kept context limited. Then I deployed the branch to staging and had several users do UAT using their own (migrated) data. They found:
- Two bugs related to the data migration itself (I had some
{:array, :integer}columns where the integers were FKs and the AI didn’t catch that, and neither did I because I had completely forgotten about them) - Some cosmetic issues where the UI was still showing
id(now uuids) instead ofdisplay_numbers - Four HTTP 500 errors in some rarely used features, caused by modified API contracts where the FE was still calling the endpoint with the original payload shape. Easy fix.
So yeah. An eight year old medium-sized Elixir project went through a titanic architecture change in a short timespan. AI planned out the entire thing, wrote all the code for it, wrote all the post-migration data integrity checks and performance benchmarking scripts, rewrote most of the test suite, and modified the FE to match the updated API contracts. It also wrote the operational step-by-step for the rollout. We deployed it in a “big bang” fashion and it has been fully stable.
Here’s the fun bit: I actually got a few quotes for this project, and they ranged from $100k to $175k, and estimated timelines ranged from four to six months. In contrast, my total AI spend during the 2.5 weeks was less than $2k. Make of that what you will.
