We migrated off Enzyme in 2 weeks. It should have taken five years.
We recently used AI to complete years of engineering work in about one sprint. Here's how, and why it's changed how we think about what's possible.
The five-year problem
Back in 2022, we set out to migrate Asana's frontend test suite off Enzyme, our aging testing library, and onto React Testing Library (RTL). Enzyme had lost community support, didn't play well with newer versions of React, and encouraged tests that were tightly coupled to implementation details rather than what users actually see and do. RTL pushed us toward a better model: test behavior, not internals.
The migration made steady progress for years. Several multi-engineer-year projects were staffed against it. Product teams chipped away at the corners they owned. All of that work mattered. But at the rate we were going, we were still roughly five years from finishing.
So we set an intentionally unreasonable goal: what if we finished the whole migration in one week.
We came close. It took about a week and a half of engineering time. Enzyme is now gone from the codebase entirely.
How it actually went
The approach was almost embarrassingly simple. We used OpenAI's Codex with frontier models on extra-high reasoning, running up to four agents at a time, each pointed at a different directory. We kept the machine from sleeping, let the agents run through the day and overnight, and checked in each morning and evening to review progress and open pull requests.
Here's the entire prompt:
/goal We want to migrate the repo from Enzyme tests to React Testing Library style tests. Follow existing norms and best practices in the codebase. Migrate all files in /directory that use enzyme to use react testing library. Test your changes with [test command]. Generally bias for migrating easy-to-convert files first.
Five sentences. That was it.
We also tried fancier setups, too: breaking the work into tracked tickets, having the agent keep a running notes file, asking it to spawn sub-agents to parallelize further, writing a much more detailed prompt on RTL conventions. Almost all of it made things worse. Simplicity won.
Why a five-sentence prompt was enough
This is the part that matters most, and it's the same idea OpenAI wrote about recently in Harness engineering: the quality of an agent's output depends heavily on the quality of the environment you hand it.
Our codebase had years of good taste already baked in — the original decision to adopt RTL, well-designed test helpers, clear conventions, real examples to draw from. The model didn't need us to explain any of that; it was already there to be read. We just supplied the goal and let the agent run.
The task itself also had the right shape for this to work: a clean, verifiable definition of done (no more Enzyme), and fast feedback loops — typechecking, linting, tests, CI — that could catch mistakes immediately. Good harness, well-defined problem, minimal hand-holding required.
What got in the way
Most of the friction wasn't the model's fault — it was ours:
Some recently written internal docs and agent guidance still pointed toward Enzyme as the preferred pattern, actively steering the agent in the wrong direction. Stale documentation isn't just a minor annoyance anymore; it's misleading training material for every agent that reads it.
Slow, flaky tooling (a lint step that occasionally took ten-plus minutes, mismatches between CI and local checks) was where we found we needed to intervene the most. The agent was rarely the bottleneck — our own infrastructure was.
The harness is the product now
One of the clearer lessons from this project: AI doesn't remove the need for engineering taste, it amplifies it. Clean examples and clear conventions in the codebase produced clean, well-shaped output. Awkward patterns got copied too. The same was true of our docs — stale guidance became a liability in a way it never quite was when only humans were reading it.
The encouraging flip side is that this compounds in the other direction as well. Good examples spread. Clear docs steer agents correctly. Investing in the "harness" — the docs, conventions, and feedback loops surrounding the code — pays off across every future migration, not just this one.
What's next
We are bullish on what this means for Asana, and know it can feel unsettling too — a lot of engineering identity is tied up in writing code by hand. My hope is that it frees us to care more about craft, not less, and to be more ambitious about the backlog of long-running migrations, rewrites, and performance problems we've quietly assumed will always take years.
Not every one of those problems will collapse from years to a week. But some will. The question worth asking isn't just "are we using AI here?" It's "have we actually tried pointing an agent at this over a weekend and looked at what came back on Monday?"
A few extra details, for the curious:
The whole migration took about a week and a half of engineering time, spread over two calendar weeks.
Total cost was roughly $11K in model usage and $1K in infrastructure — a small fraction of the years of engineering time the old pace would have required.
To put that $12K in perspective (back of the napkin math): had we stuck to the original five-year timeline with a dedicated team of three engineers, a back-of-envelope estimate — using a fully-loaded cost of roughly $350K–$450K per senior engineer in the Bay Area (salary, bonus, equity, benefits, and overhead, based on current public benchmarks) — puts that path at somewhere around $5M–$7M, call it ~$6M in engineering cost. That's before counting the opportunity cost of those three engineers not building product instead. Against $12K, that's the gap an unreasonable one-week goal can open up.
We found a few drive-by wins along the way, including cleaning up an even older, pre-Enzyme testing framework we'd forgotten was still lurking in parts of the codebase.
This post is part of an ongoing collaboration and partnership between Asana and OpenAI exploring how Codex can take on larger, more ambitious engineering work.
