Asana turned a five-year migration into two weeks with Codex

Asana says it removed an outdated frontend testing system in about two weeks with Codex, work it had expected to take five years. The OpenAI case study says the project used up to four coding agents in parallel, cost about $12,000 in model and infrastructure spend, and remained under engineer review. The result is a reported company case, not proof that every long-running migration can be compressed the same way.

Definition: Asana used Codex as a supervised implementation system for a large codebase migration, with parallel agents making proposed changes and engineers reviewing them.

Example: Asana gave Codex a five-sentence prompt, ran up to four agents in separate codebase copies, and had an engineer check progress twice a day.

Key takeaway: The reported speed came from combining parallel Codex work with a bounded migration and continuous human review.

Business impact: Asana says a migration estimated at roughly $6 million under its previous staffing plan used about $12,000 in model and infrastructure costs instead.

What did Asana change with Codex?

Asana used Codex to remove Enzyme, an outdated testing system that had fallen out of active maintenance and was making Asana's frontend stack harder to modernize. The specific engineering target matters because Codex was not asked to invent a product or replace an entire engineering organization; Codex was applied to a defined migration with a clear end state. For teams evaluating coding agents, the practical lesson is to start with a repository change whose completion can be checked directly.

Asana says Enzyme had become a blocker because its testing approach no longer fit the direction of the frontend stack. Removing it gave Asana a concrete modernization objective: finish the migration, eliminate the obsolete dependency, and leave the codebase ready for further testing and performance work. The AI agent explainer on Yowox describes the broader distinction between a system that only answers and one that carries out a multi-step task with tools and verification.

How did Asana organize the Codex work?

Asana started the Enzyme migration from a five-sentence prompt and ran up to four Codex coding agents in parallel. Each Codex agent worked in a separate copy of the codebase, which let Asana divide implementation effort without having every agent edit the same working tree. The operational takeaway is that parallel Codex execution is most useful when the work can be separated into changes that engineers can later reconcile and review.

Asana kept the Codex process supervised rather than treating the agents as unreviewed committers. An engineer checked progress twice a day and reviewed every proposed change. That review cadence gave Asana a way to catch incorrect assumptions while the migration was underway, and it preserved a human decision point before proposed code became accepted code.

Asana also says simpler instructions worked better than a more elaborate setup. That observation is narrower than a general prompt-engineering rule: it describes this migration's experience, where the target and constraints were clear enough for a short request to guide multiple agents. The practical step for an engineering team is to test whether a concise specification gives Codex enough context before adding orchestration that makes the workflow harder to inspect.

How long did the Codex migration take?

Asana says Enzyme was fully removed after 1.5 weeks of engineering effort spread across two calendar weeks. The company had expected the work to take at least five years under its previous plan, so the reported comparison is between a multi-year staffing estimate and a short, concentrated agent-assisted migration. The result is meaningful as a case study because Asana names the work, the elapsed time, and the process used to complete it.

The two time measures should not be confused. “Two calendar weeks” describes the elapsed window, while “1.5 weeks of engineering effort” describes the work Asana says was spread across that window. A team assessing its own Codex project should track both elapsed time and human review effort, along with rework and the quality of the final migration, rather than reporting only the fastest clock measurement.

What did Asana say the Codex project cost?

Asana says model and infrastructure costs for the migration totaled about $12,000. The company compared that amount with a roughly $6 million estimate for the previous staffing plan, producing a large difference between the reported agent-run cost and the expected cost of the earlier approach. The LLM coding productivity analysis on Yowox explains why implementation speed still needs to be evaluated alongside design, review, testing, and maintenance.

The comparison is useful but bounded. Asana's $12,000 figure covers model and infrastructure costs reported for this project, while the $6 million figure is an estimate for the previous staffing plan; the source does not present a controlled study of total cost across identical teams and timelines. Businesses should therefore treat the numbers as Asana's project economics, then measure their own Codex usage, engineer time, defect correction, and release effort before making a budget assumption.

What does the Asana result change for engineering teams?

Asana says the migration changed which long-running software projects it considers practical to attempt. That is the strategic result of the Codex project: once removing Enzyme appeared feasible within two weeks, Asana could consider applying agents to other migrations, rewrites, and performance problems it had previously assumed would take years. The concrete takeaway is to use a successful migration to expand the backlog of candidate work, not to remove the need for engineering prioritization.

Codex did not remove human ownership from Asana's process. Engineers supplied the prompt, checked progress twice a day, and reviewed every proposed change, while Codex supplied parallel implementation capacity. For an engineering leader, that division points toward a supervised operating model: give Codex a precise target, isolate concurrent work, define acceptance checks, and keep people responsible for deciding whether the resulting changes are correct.

What remains uncertain about Codex's five-year comparison?

Asana's result does not show that every years-long software project can be finished in weeks. The source gives one migration, one company, one reported cost comparison, and one supervised Codex workflow. It does not provide a general benchmark across repositories, migration types, defect rates, or the maintenance cost of the resulting code. Readers should preserve that boundary when quoting the five-year and two-week figures.

Asana's CTO also makes the limitation explicit: “Not every years-long project will collapse into weeks.” The more defensible conclusion is narrower. Codex gave Asana enough parallel implementation capacity to make one previously unattractive frontend migration worth attempting, while engineers remained in the loop to inspect the work. That is a credible signal about the changing economics of selected codebase projects, not a guarantee of universal engineering acceleration.

The immediate question for another team is therefore not whether Codex can erase five years from its roadmap. It is whether one well-scoped migration has a clear completion condition, enough repository context, separable work, and review capacity to test the approach safely. Asana's case suggests that those conditions can turn neglected engineering work into a practical experiment.