The Asana Codex case is a story about one engineer's judgment.

Asana cleared five years of engineering work in two weeks with Codex, for about $12K against $6M of work, and this week OpenAI and Asana both published it. Everyone ran with the cost math. The thing that collapsed five years into two weeks was one senior engineer running five parallel agents and personally approving every change twice a day. The model did the typing. The engineer did the only part that was ever hard, which is telling code that is good apart from code that is useful. Copy the agents, skip that person, and you ship five years of tech debt in two weeks.

I keep seeing founders and eng leaders read the $12K figure as a signal to reallocate headcount. That figure prices the tokens. It hides the one human who made the tokens worth anything. Before anyone points Codex at a backlog, they should understand what that engineer actually did, because that is the part you cannot buy in seats.

The scarce input was the engineer, not the seats

The seats are cheap. Codex is cheap. What was scarce in the Asana case was a person who understood the codebase well enough to look at a batch of AI changes and approve or reject it in minutes, twice a day, for two weeks straight. That is senior judgment applied at high cadence, and it does not get cheaper when you buy more seats.

Think about the cadence for a second. Two check-ins a day, ten working days, twenty review gates. Behind each gate, five agents generating in parallel. He held the line at every one of those twenty gates and did it fast enough that the agents never sat idle waiting on him. That is the whole engine. The $12K prices the compute. It says nothing about the person clearing twenty batches with enough context to know which changes belonged.

Buy ten more Codex seats and you do not get faster here. You get more generation waiting on the same one person to look at it. The reviewer is the constraint, and the reviewer is expensive.

Good code is now the floor, not the win

Every coding agent writes good code now. Clean, tested, plausible code is what they ship by default, including the weak ones. I have watched shitty agents produce a passing test suite and a tidy diff that looks completely reasonable. That output is cheap and it is everywhere.

So the model's output was never the hard part in the Asana case. The hard part was someone who could read a passing test suite and still say this compiles, it works, and it is the wrong change, before it landed in the codebase. A green checkmark tells you the code runs. It tells you nothing about whether the code should exist.

I genuinely believe this is where most teams are about to get burned. They will look at agent output, see the tests pass, and merge. Six weeks later a migration is half in the old pattern and half in the new one, nobody can hold the whole thing in their head, and the cleanup costs more than the work saved.

What the engineer did was tell good apart from useful

Good code passes tests. Useful code passes tests and belongs in this system, matches how the rest of the migration is going, and will not become debt in six months. A machine can verify the first. Only someone who owns the migration can judge the second.

He judged the second twice a day for two weeks. Look at what that takes. You have to hold the target state of the whole migration in your head, remember which patterns you already committed to, and catch the agent when it solves a local problem in a way that fights the global one. The agent optimizes the diff in front of it. The owner optimizes the system the diff lands in. That is the difference between a change that ships and a change that should never have been written.

This is the AI-native pattern sitting inside one person. The model does the work, the senior owner supplies the judgment, and one human owns the whole migration end to end. Same tool in a room with no owner produces the opposite result. The difference is entirely who is holding the review gate.

Throughput is capped by the reviewer, not the agent count

Five agents can generate faster than one person can verify. So the win here scaled with how fast that one person could clear a batch, and stopped scaling the second the agents outran his review. The bottleneck was the human end of the loop the whole time, because the useful was always coming from the human end of the loop.

This flips the buying logic that most teams are about to apply. Two agents behind a sharp senior owner beat ten agents behind nobody, every time. More agents behind an empty gate just ships plausible debt faster. If you are sizing this project by seats, you are counting the cheap input and ignoring the expensive one.

At Nyyon we build these systems for clients, and this is the shape of every one that works: the model does volume, a named human owns the output, and the whole thing has one throat to choke when reality gets its hands on it. The org that reads Asana as buy Codex, cut the eng budget has removed the one part that created the value.

Answering the fair objections

The obvious pushback is that the model clearly did most of the work, so this is a model story. Fair. It did the typing and that matters. But the model has been capable of generating this volume of code for a year, and nobody cleared a five-year backlog in two weeks until someone paired it with parallel execution and a twice-daily review gate. The differentiator was the operating loop, not a new model release.

Second objection: not every team has an engineer who can review that fast, so this does not generalize. Correct, and that is why the case study is dangerous when it gets sold as a universal cost cut. The result generalizes only to work with a machine-checkable definition of correct and an owner who can judge it at cadence. Teams with neither will mislead themselves badly.

Third: twice-daily review will not scale to real production velocity. True at large scale. Which is exactly why the reviewer is the constraint you design around, and why the gate being load-bearing is the whole lesson. The case is proof the gate carries weight. It is not proof the gate is free.

Name the owner before you run the agents

This week, before you point Codex or any coding agent at a backlog, pick one migration and name the single senior owner who will review every batch, someone who can tell useful code from merely correct code. Budget that person's hours first, then the seats. If you cannot name that owner, do not run the agents on that migration yet. The agents are the cheap part.

The person to celebrate in the Asana case is the engineer with the tenacity to hold twenty review gates in two weeks and the taste to know which of a thousand passing diffs actually belonged. Buy his judgment before you buy his seats, or you get the debt without the win.

If you have a problem, if no one else can help, and if you can find them, maybe you can hire Nyyon.