Every engineering organisation has a list of migrations it has been planning to get to for years. A framework two major versions behind. A test library the vendor abandoned. A deprecated internal API that forty services still call. Everyone agrees it should be dealt with. It never moves up the roadmap, because it cannot compete with features for people. What has quietly changed the arithmetic is AI code migration: pointing coding agents at the tedious, mechanical part of the job.
Then Asana removed Enzyme, an abandoned test framework that had been blocking upgrades across its front end, and migrated to React Testing Library in two calendar weeks. Model and infrastructure costs came to roughly twelve thousand dollars. The OpenAI write-up puts the previous plan at around six million dollars and at least five years. The method was almost dismissive: a five-sentence prompt, up to four coding agents working in parallel on separate copies of the codebase, and one human engineer checking progress about twice a day and reviewing every change before it merged.
The baseline is probably inflated. It does not matter.
Gergely Orosz was sceptical, and reasonably so. The idea that four engineers would have spent five years on an Enzyme-to-RTL migration reads like a number someone produced to end a planning conversation rather than a real estimate. He is probably right. Perhaps a competent team could have done this in a year with two people.
The economics still flip. A year of two engineers is a real commitment with a real, double opportunity cost: they could work on people-focused change, and the blocker remains blocking. Two weeks of one engineer supervising agents, plus a five-figure model bill, is a rounding error. The category of work has changed even if the specific headline is exaggerated.
Why these projects never moved
This kind of work is rarely postponed because it is hard. Most large migrations are mechanically simple and tedious: the same transformation applied ten thousand times, with a long tail of special cases. The blocker is that it requires pulling people off features for months to produce nothing a customer could see, and that is the easiest thing in the world to defer for one more quarter.
So it sits at the bottom of the backlog, labelled important and not urgent, quietly making every other change slower and more expensive. The interest on that debt is paid in small increments by every engineer who has to work around the old framework, but it never shows up as a line item.
What changes when the mechanical backlog clears
If a two-to-four-week supervised agent run can clear one of these, the “too expensive to justify” tier of the backlog stops being a permanent resident. Framework upgrades that unblock security patches. Dead code removal that speeds up every build. API consolidations that make the next feature cheaper. None of these have to win a headcount argument any more, because they are no longer a headcount ask.
Framework upgrades are the clearest case. A runtime two major versions behind blocks a security patch, which blocks a compliance sign-off, which turns a technical chore into a business risk that gets escalated once a quarter and actioned never. If the upgrade itself is now a supervised fortnight rather than a staffed project, the escalation stops being theatre.
There is a compounding effect too. Each migration you finish makes your dependency graph cleaner, which makes the next migration smaller, which makes it cheaper again. Teams that have been accumulating this debt for a decade have the most to gain and the furthest to climb.
The one cost that does not shrink is review. A human still has to read and approve every change, and a migration that touches ten thousand files produces ten thousand diffs to sign off. Asana handled this with one engineer checking in twice a day, which works when the change is mechanical and the pattern is consistent. The moment the changes stop being uniform, review time climbs back up, and it becomes the real limit on how fast you can clear the backlog.
Where the pattern stops
Migrations suit this because they have two properties: a clear target state, and a mechanical definition of done. You know what “off Enzyme” means and you can check it. Point an agent at that and supervision is cheap.
Most deferred work does not look like that. A re-architecture where the target is still an argument. A performance problem nobody has diagnosed. A data model change that touches product decisions. Those are not mechanical, and pointing agents at them produces confident output you then have to unpick. The right lesson is narrow: AI has made the mechanical backlog clearable, not the whole backlog.
That is still a large prize. Most engineering organisations are carrying years of mechanical debt they had written off as unfixable.
A question for your next planning cycle
Go and look at the list of migrations your teams have been deferring. For each one, ask a different question than you asked last year. Not “can we find a team for this,” but “does this have a clear target and a mechanical done, and if so, why is it still on the list.”
The migration you keep postponing is not waiting for a better quarter. It is waiting for you to notice it costs a fortnight now.
Leave a Reply