AI Coding Agents Made the Rewrite Cheaper. Tests Made It Safe.
Maestro Brief · Published by Maestro Mojo
Editorial identity incomplete
2026-09-12
Maestro’s take.
Coding agents may be changing an old engineering rule.
A rewrite used to mean years of duplicate work, missed edge cases, and a heroic launch day nobody wanted. Now an agent can translate a working system into a new language or platform much faster.
That does not make rewrites safe.
It makes the code cheaper. The proof is still expensive.
TL;DR
Shopify says coding agents helped it rebuild the Shop app from React Native into separate Swift and Kotlin apps in 12 weeks. Checkly says Claude Code rewrote a 92-million-message-a-day Node.js service in Go.
Both projects worked for the same reason: the teams did not ask an agent to “rewrite everything” and hope.
They built tight loops. Small pieces. Real tests. Human review. Slow rollouts.
The useful lesson is not “rewrite your stack.” It is this: agents can make a rewrite affordable when your tests can clearly prove the new system behaves like the old one.
What changed
Shopify moved its mobile apps to React Native in 2020 partly because building the same feature twice—once for iOS and once for Android—was expensive.
That assumption changed. Shopify says agents can now use one platform as a reference while implementing the other. The company rebuilt the Shop app as fully native software and released it after a 12-week project. Its much larger Shopify app, with more than 300 screens, is next.
Checkly tested the same idea on backend infrastructure. It gave Claude Code a working Node.js service and asked for a Go replacement. The new service was about 13,000 lines, processed roughly 92 million messages per day, and shipped with no customer-facing incidents, according to Checkly.
The reported result used fewer pods and reduced average active database sessions by 60%. But the model was not magic. Checkly’s earlier Opus attempt missed the bar and was thrown away. The successful Fable run worked inside a strict test harness and still needed human corrections.
These are company-written case studies. They are not controlled benchmarks. They do show two real teams independently arriving at the same operating pattern.
The pattern is more important than the model
| Team | What the agent changed | What kept it honest |
|---|---|---|
| Shopify | React Native screens into Swift and Kotlin | Small checkpoints, automated tests, visual checks, two adversarial reviews, human approval |
| Checkly | Node.js service into Go | Black-box tests, production-shaped inputs, failure testing, feature flags, staged rollout |
Shopify explicitly says a one-shot rewrite produced unmaintainable code. Its Helix system breaks one screen into small checkpoints. Each checkpoint must pass tests, match the running app visually, survive adversarial review, and receive human approval before the next begins.
Checkly built its test harness before the agent wrote the replacement. It replayed realistic inputs through both implementations and compared the outputs. When the test environment modeled only three queues while production used 18, the rewrite failed during the internal rollout. The team fixed the harness, not just the symptom.
That is the important part. An agent optimizes for the world you describe. If your tests describe a toy world, it will confidently build a toy answer.
What this means for your next project
Do
- Write the acceptance tests first. Capture what the old system does before generating the new one.
- Cut the rewrite into small pieces. One endpoint, screen, or workflow at a time.
- Test against real boundaries. Use production-shaped queues, databases, permissions, failures, and data.
- Run old and new side by side. Compare outputs before moving traffic.
- Roll out with a kill switch. Feature flags and small cohorts make mistakes reversible.
Do not
- Ask an agent to rewrite the whole repository in one prompt.
- Treat passing unit tests as proof that production behavior matches.
- Assume the newest or most expensive model will win. Checkly says its first Opus attempt did not.
- Delete the old system before the new one survives real traffic.
Why Maestro users should care
Agents lower the cost of typing code. That lets teams reconsider decisions that once felt permanent: framework choices, legacy languages, duplicated clients, and fragile services.
But the cheapest model is not the one with the lowest token bill. It is the one that reaches a verified result with the fewest correction loops.
In a multi-agent workflow, give one agent the implementation and another the job of attacking the assumptions. Make tests and rollout evidence the shared contract. The orchestrator should track checkpoints, not celebrate line count.
One thing to try
Pick one small legacy workflow.
Record five real inputs and their expected outputs. Include one failure case. Ask an agent to reimplement only that slice. Then run both versions side by side.
If you cannot define what “same behavior” means, you are not ready to automate the rewrite.
The reality
AI did not make rewrites safe.
It made writing the replacement less expensive.
The teams that benefit will spend the saved time proving the replacement is correct.