OpenAI published on August 18, 2026 a case study dedicated to removing Enzyme from Asana's codebase using Codex. The case study reports about two calendar weeks, a week and a half of engineering effort, and $12,000 in model and infrastructure costs. These figures are impressive, but they should be read as a vendor case, not as a promise applicable to every migration.
1. What the Asana case asserts
According to the feedback published by OpenAI regarding Asana, the team removed Enzyme, a testing system that had become a significant liability, in about two calendar weeks. Direct human work would have accounted for a week and a half, while the cost of models and infrastructure would be around $12,000.
The article compares this result to a previous plan that Asana estimated at at least five years and around 6 million dollars in personnel. This comparison comes from the organization itself and depends on the chosen estimation method. It should not be converted into a generic productivity ratio or into a fully audited cost comparison.
The most useful information is operational: starting from an initial five-sentence prompt, up to four agents worked in parallel in separate copies of the codebase. An engineer checked the progress twice a day, and every proposed change was reviewed.
2. Why this migration was suitable for the agents
Replacing a testing system is a vast but often repetitive problem. The transformations can follow patterns: modifying imports, adapting helpers, replacing selectors, rewriting assertions, and fixing tests.
The expected result is highly verifiable. A test must compile, run, and maintain behavior. This loop provides the agent with objective feedback, unlike a business redesign whose quality depends on poorly documented intentions.
Migration can also be split by files, folders, or components. Independent batches limit conflicts and allow multiple agents to run in parallel.
These characteristics constitute a useful framework: repetitiveness, verifiability, partitioning, and low business ambiguity. The more a project brings them together, the more suitable it is for agentic experimentation. This framework is a methodological reading of Partitech; the OpenAI case study does not detail these transformations one by one.
3. The decisive role of cutting
Giving an agent 'removes all technical debt' rarely produces an actionable result. You need to build an inventory: uses of the dependency, variants, exceptions, test coverage, and migration order.
The repository can then be divided into comparable units. Each batch receives a concise instruction, constraints, a test order, and a definition of done. Atypical cases are isolated instead of polluting all the prompts.
The Asana feedback indicates that simpler instructions worked better. This finding is consistent with an engineering practice: moving stable rules to scripts, tests, and linters, rather than explaining the entire project in a gigantic prompt.
4. Controlled parallelism
Several agents can speed up processing if their scopes are independent. Separate copies of the repository prevent them from modifying the same workspace at the same time.
It is nevertheless necessary to manage dependencies. An agent can create a common helper that others would need. A team must decide which structural changes are integrated first and which batches can remain independent.
Parallelism also increases the review volume. Four agents producing changes faster than the team can check them create a new queue. The optimal number therefore depends on the capacity of CI and human oversight, not just on the available licenses.
5. Why tests remain the real accelerator
The OpenAI page documents neither the test commands, nor the CI, nor the functional coverage of the migration. The practices described in this section therefore constitute our method of securing an agentic project, and not a measured result in the Asana case.
An agent can modify a lot of code; tests allow one to quickly know if the change is acceptable. Without a reliable suite, the team must read every line and reconstruct the expected behavior, which negates much of the gain.
Before the migration, stabilize the test commands, reduce non-deterministic cases, and add targeted controls. A test that fails once in ten times disrupts an agent as much as a human.
The CI must produce actionable messages and allow partial executions. The agent can correct more effectively when it receives precise feedback on the file, the assertion, or the type in question.
6. Human review has not disappeared
The published case specifies that each proposal was reviewed and approved by a human. The engineer checked the work twice a day and guided the agents when the strategy needed to change.
The review should focus on behavior, not just style. Check for coverage omissions, weakened assertions, type workarounds, snapshots accepted too easily, and global configuration changes.
A good agent can propose a solution that passes the CI by removing the problematic test. The acceptance criteria must explicitly forbid this type of shortcut.
7. What the cost figure does not say
The announced $12,000 covers the models and infrastructure, but the page does not provide a breakdown showing how the preparation of the repository, the development of internal tools, review time, existing infrastructure, subsequent fixes, or team capitalization are accounted for.
Conversely, the comparison with a plan of at least five years and about 6 million dollars in personnel is based on an estimate from Asana that may never have been undertaken in this form. The two figures are not directly comparable without a detailed methodology.
For your project, calculate the total cost: models, CI, storage, engineering, review, incidents, and script maintenance. Compare it to a realistic human scenario over the same scope and with the same level of quality.
8. A reproducible method for your project
Start with a static analysis and a verifiable inventory. Then choose a pilot batch of 20 to 50 representative transformations. Write a short instruction, a test command, and a list of prohibitions.
Have the batch executed by an agent in an isolated branch. Measure the acceptance rate without rework, the review time, functional errors, and cost. Correct the tools before increasing the volume.
Once the pilot is stable, partition the rest of the site, limit the number of agents to the review capacity, and integrate gradually. Keep a dashboard: processed files, tests added, failures, conflicts, and remaining debt.
This method complements our approach to measurement and prioritization of technical debt and the safeguards presented in Development agents in 2026.
9. Migrations to avoid first
Do not use an untested redesign, undocumented business logic, or an irreversible data migration as the first pilot. Agents do not make up for the lack of definition of the expected result.
Also avoid a project where every file depends on a moving architecture. The conflict between agents, branches, and human decisions can outweigh the generation gain.
The Asana case does not prove that an agent replaces a team. It shows, according to the feedback published by OpenAI, that a well-equipped team can turn a repetitive project into a parallel migration pipeline. The key skill remains work system engineering.
Partitech supports AI-assisted technical migrations: inventory, batch design, prompts and scripts, test reinforcement, Codex orchestration, and quality control.