Asana Says Codex Completed Five Years of Engineering Work in Two Weeks: What Does This Mean for Software Development?

Short Answer

Asana says it used OpenAI Codex to replace an outdated internal testing system in approximately two weeks — work the company had estimated could take around five years and roughly $6 million in staffing. OpenAI reports approximately $12,000 in model and infrastructure cost for the effort.

The headline invites the wrong conclusion. This is not evidence that AI replaces software engineers. It is evidence that AI coding agents have become capable enough to absorb a specific category of work engineering teams have always deferred: large, mechanical, well-tested, low-creativity migration work.

That category is bigger than most organisations admit, and it is where the near-term return sits.

What Actually Happened

According to OpenAI's published customer case study, Asana used Codex to replace an outdated testing system. The reported outcome:

• Roughly 2 weeks of elapsed engineering work
• Against an internal estimate of approximately 5 years
• Approximately $12K in model and infrastructure cost
• Compared against a ~$6M staffing estimate

Two caveats deserve equal billing with the numbers. First, these are Asana's reported figures for one project in one codebase — not a benchmark you should expect to reproduce. Second, the five-year figure is an estimate of work the company had *chosen not to do*. Comparing "two weeks of agent time" against "a project nobody was ever going to fund" flatters the ratio. The real signal is that the work became feasible at all.

Why This Is Different From Autocomplete

Most AI coding tools in use today operate on a short loop:

`Developer asks → AI generates a suggestion → Developer reviews and accepts`

An agentic loop is structurally different because the agent, not the human, drives iteration:

`Agent inspects repository → maps dependencies → edits multiple files → runs tests → reads failures → corrects → repeats → opens a pull request for human review`

The important change is not code generation quality. It is that the agent has a feedback signal — the test suite — and can act on it hundreds of times without getting bored. That is exactly why test migration was such a good first target: correctness was machine-checkable at every step.

This is the practical rule we now apply when scoping agent work: *the value of an AI coding agent is roughly proportional to the quality of the automated verification you can point it at.* Strong test coverage turns an agent into a tireless engineer. Weak coverage turns it into a fast source of plausible bugs.

A Concrete Example

Suppose a legacy application has 5,000 automated tests written against a framework that has not been maintained for six years.

The traditional path looks like this:

`Engineer understands the framework → designs the target state → migrates tests in batches → fixes failures → repeats for months`

The agentic path looks like this:

`Agent inspects the repository → identifies migration patterns → rewrites tests in batches → executes the suite → analyses failures → fixes → repeats → human reviews the diff`

The engineer's role does not disappear. It moves upstream: choosing the target framework, defining the migration contract, deciding what "equivalent behaviour" means, and reviewing patterns rather than individual lines. That is a genuinely more senior job, and not every engineer enjoys the shift.

Where AI Coding Agents Earn Their Keep Today

The pattern across the projects we have seen is consistent — agents perform best where the work is high-volume, pattern-heavy and verifiable:

• Legacy modernisation and framework migration
• Test migration and test generation for uncovered code
• Dependency and API version upgrades
• Mechanical refactoring across many files
• Documentation of undocumented systems
• Code search and architectural archaeology
• Narrow, well-reproduced bug fixes
• Internal tooling and developer onboarding scripts

They perform worst on greenfield architecture, ambiguous requirements, cross-team API design and anything where "correct" is a judgement call rather than a test result.

Where Humans Still Decide

AI-generated code fails in ways that look different from human failure modes. It is rarely syntactically wrong and frequently *contextually* wrong. In review we consistently find:

• Security regressions — authorisation checks quietly dropped during a refactor
• Confidently incorrect assumptions about business rules
• Tests rewritten to pass rather than to assert the original intent
• Performance regressions from naive query or loop patterns
• Architectural drift when the agent optimises locally
• Compliance-relevant logging removed as "unused"

So the production pipeline must remain:

`Agent generation → automated validation → human review → controlled deployment`

Never `agent generation → production`. The organisations getting hurt by agentic coding are not the ones using it. They are the ones using it without the middle two steps.

What Enterprises Need in Place First

If you cannot tick at least the first four, start there. Agent enablement without these controls is not acceleration, it is unmanaged change.

Tooling: Open Source and Commercial

Open source. Continue, OpenHands, Aider, Cline and SWE-agent take meaningfully different approaches to agentic development, from IDE-embedded assistance to autonomous repository-level task execution. They suit teams that want to run agents against private code inside their own infrastructure.

Commercial. OpenAI Codex, GitHub Copilot (including agent modes), Claude Code and Google Gemini Code Assist offer stronger model quality, integration and support.

Selection criteria that actually matter in practice: how well the tool handles repository-scale context, whether code leaves your boundary, whether execution is sandboxed, how cleanly it integrates with your existing review and CI workflow, and cost predictability at team scale. Model leaderboard position is the least useful of these.

How to Start Without Betting the Roadmap

A staged approach that survives a security review:

1. Pick a verifiable target. A test migration, a dependency upgrade or a documentation backlog — something where success is machine-checkable.
2. Measure the baseline. Record current effort, cycle time, escaped defect rate and coverage before the agent touches anything.
3. Sandbox the agent. Read-only credentials, isolated runner, no production access, no secrets in context.
4. Cap the blast radius. One repository, one branch pattern, one reviewer group.
5. Review patterns, not lines. Have a senior engineer approve the migration approach once, then spot-check batches.
6. Instrument the outcome. Compare against the baseline honestly, including review time — which usually grows.
7. Expand by category. Only after one category is genuinely working.

Note step six. Total engineering time rarely drops as much as generation time does, because review load shifts. Teams that plan for that shift keep the gains; teams that do not end up with a review bottleneck and a frustrated staff engineer.

The Larger Opportunity

The business story here is not tool procurement. Tools are cheap and increasingly commoditised. The scarce capability is knowing *which* parts of a software estate can safely be accelerated, and building the verification scaffolding that makes acceleration safe.

That is what our [digital engineering services](/services) work looks like in practice: audit the legacy estate, rank the highest-cost repetitive engineering work, build the test and CI scaffolding first, introduce agents against a bounded target, add security and licence scanning, then measure delivery throughput against a real baseline. The [decision frameworks](/frameworks) we use for build-versus-buy apply almost unchanged here.

Conclusion

The Asana example matters because it marks the transition from AI as autocomplete to AI as a participant in multi-step engineering work. But the question worth taking to your own leadership team is not "can AI write code?" — that is settled.

It is: which parts of our software lifecycle can AI safely accelerate, and what verification do we need before it can?

For nearly every enterprise, the honest answer starts with legacy modernisation, test coverage and repetitive migration work — and it starts with tests, not with agents.

Frequently Asked Questions

Did Asana really compress five years of work into two weeks?

Asana reports replacing an outdated testing system in roughly two weeks against an internal five-year estimate, with about $12K in model and infrastructure cost. These are one company's figures for one project, and the five-year estimate described work that had not been funded.

Do AI coding agents replace software engineers?

No. They shift engineering effort from writing mechanical code to defining intent, reviewing patterns and owning architecture. Review and accountability load typically increases even as generation effort falls.

What work should an AI coding agent be given first?

Work with a machine-checkable correctness signal: test migration, dependency upgrades, mechanical refactoring and documentation. Avoid ambiguous greenfield architecture as a first project.

What are the main risks of agentic coding in production?

Dropped authorisation checks, tests rewritten to pass rather than to assert intent, performance regressions, architectural drift and vulnerable dependencies. Sandboxed execution, automated validation and mandatory human review mitigate all four.

How much does agentic coding cost to run?

Model and infrastructure cost is usually small relative to engineering salaries, as in the reported $12K figure. The cost that surprises teams is human review time, which should be budgeted explicitly.

Do we need good test coverage before using coding agents?

Yes, and it is the single strongest predictor of success. Agents iterate against verification signals, so weak coverage produces fast, confident, unverifiable change.