# AI Can Make Deferred Work Worth Doing

> AI can change the economics of deferred system migrations. PeşinTaksit, Asana, Airbnb, and Uber show why scope, verification, and migration choices still matter.

I would not have set aside three to five days to simplify PeşinTaksit's infrastructure. It was a small side project that had been sitting in the background, and I was not paying much attention to it. As long as it worked, I was prepared to leave its old structure alone.

It still left me with four containers to manage: MariaDB, Redis, a Fastify backend, and a Nuxt frontend. Each was a reasonable choice in isolation. Together, they demanded more attention than I was willing to give the project. I wanted to clean it up, but not enough to spend several days on it.

When I [simplified it with AI](/ai-turned-a-refactor-i-wouldnt-do-into-a-one-hour-job), four containers became one Cloudflare Workers deployment. About an hour passed from the start of the work to taking the new setup live.

The one-hour figure is what actually happened. Three to five days was my estimate before I began. I did not repeat the same job without AI, so I cannot calculate a reliable speed multiplier from it.

But I do know what changed: I completed work I would not have spent several days on. PeşinTaksit did not suddenly become more important. The cleanup fit inside the amount of time I was prepared to give it.

## Deferring work is a decision too

We do not have to replace a working system simply because something newer exists. Even when maintenance is burdensome, leaving it alone can be the more sensible choice. If customer work is waiting, asking a team to spend several weeks removing an old library may be hard to justify.

That is why an item that has sat on a technical backlog for a long time is not necessarily forgotten. The team may know what needs to happen and see the benefit. It may simply be unwilling to pay the cost. That was my situation with PeşinTaksit.

When writing, transforming, and fixing the code takes less time, the calculation changes. If we leave the old estimate untouched and use AI only on new projects, we may miss the opportunity. Some work that was not worth doing before may now be worth finishing.

![A long-deferred technical task is reassessed by comparing its old heavy estimate with a bounded migration path that is feasible today](/images/inline-ai-deferred-work/deferred-work-deserves-reassessment.webp)

## Why Asana's five years matter

[OpenAI's Asana case study](https://openai.com/index/asana/) says that work expected to take five years was completed in two calendar weeks. It puts a roughly $6 million engineering estimate alongside $12,000 in model and infrastructure costs.

[Asana's own account](https://asana.com/inside-asana/migrating-off-enzyme-2-weeks) describes a more familiar situation. The team was already working to move away from the legacy test library Enzyme. At the team's then-current pace, the remaining work was estimated to take five years; it does not mean a team would work exclusively on it for five uninterrupted years.

The $6 million is also a rough labour estimate for doing the work manually. It includes not only changing the library, but additional test improvements and infrastructure cleanup. The $12,000 does not include human labour. We cannot subtract one figure from the other and call it savings. The account, published as part of the Asana–OpenAI partnership, is not a controlled comparison either.

Even so, one concrete result remains: a job that had been moving slowly was completed. PeşinTaksit and Asana are obviously very different in scale. What they share is that both teams finished work that would otherwise have continued at the old pace. Rather than treating another company's timeline as a promise for our project, it is more useful to reassess the case for our own deferred work.

## Someone still has to verify the code

Before a team makes time for cleanup, it needs more than an estimate of how quickly code can be written. How much time will it take to review the result? How will we notice if something is wrong? Which behaviours must continue to work when the migration is complete?

In its work migrating roughly 3,500 test files, [Airbnb built those questions into the process](https://airbnb.tech/infrastructure/accelerating-large-scale-test-migration-with-llms/). Files were validated step by step. Work did not proceed until checks passed; failures were fed back to the model. The team added relevant code and good examples, then engineers finished the files automation could not.

Airbnb reports completing the work in six weeks. This is the company's own case account, so its duration does not predict how long another project will take. It does show how the work was finished. The model wrote code, but the process caught errors and sent the work back for correction.

This matters especially when the work changes tests. In simplifying a test, we may make it unable to catch the defect it was meant to detect. The test will still pass. Seeing green on the screen is not the same as knowing that prior behaviour has been preserved. If we do not account for the work of review upfront, we are looking only at the fastest part of the job.

![An AI-assisted migration moves code cards through generation, human verification, correction, and a rollback loop that preserves the old version](/images/inline-ai-deferred-work/migration-needs-verification.webp)

## AI does not need to write every part

Uber tried using generative AI at scale for its [JUnit migration](https://www.uber.com/gb/en/blog/junit-migration/), and the attempt failed. The team used OpenRewrite, which changes code through defined rules, for the transformation itself. They used AI to examine test and build failures.

They first prepared the infrastructure that allowed the old and new tests to run together. During the migration, they also reverted files with failing tests to the old version. The outcome depended on not asking the model to do everything.

That should shape how teams revisit deferred work. If an existing tool can already make the repeated changes, use it. It can also be reasonable to fix the hard remaining files by hand. The point is not to demonstrate how much work we can assign to each tool. The point is to remove the old burden.

## Start small, but finish something

For PeşinTaksit, the end state was concrete: I stopped managing four separate containers and moved to a simpler structure. For teams, it helps to define the initial scope around a concrete outcome. Completely removing a module's old dependency or shutting down an unnecessary service is a more meaningful target than a file count.

That does not require changing the whole system at once. Start with a bounded part and see how long writing, reviewing, and correcting the code actually takes. Choosing only easy files will mislead us. Including a difficult case alongside the common ones makes the estimate for the remaining work more realistic.

Sometimes that experiment shows the job is still expensive. If no one fully understands what the old system does, fast code generation does not close that gap. First, the expected behaviour has to be made explicit. We can include that burden in the cost and continue to defer the work.

Someone must also own the production rollout. What will count as proof that it works? Who will stop it if something goes wrong, and how will the team roll back? If data is being moved, reopening the old application may not be enough. The team also needs to decide what happens to records created during the transition. When to shut down the old system and who will monitor the new one are not details to leave until the end.

What I gained with PeşinTaksit was not simply a few freed-up days. I finished work I would otherwise have left waiting. Teams may have backlog items that deserve the same reconsideration. A small experiment may be enough to start reassessing one of them.

## Further reading

- [The Pulse: We need to talk about migrations with AI](https://blog.pragmaticengineer.com/the-pulse-we-need-to-talk-about-migrations-with-ai/): This discussion prompted the article and considers Asana's time and cost estimates in the context of prioritization. The cases are not comparative evidence of speed; for Uber's limited use of AI, the primary account above should be the reference.

---

Language: English
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/ai-assisted-migrations-deferred-work