Codex. Claude. Gemini. Pick one? Or run all three. ⚔️

Most teams run four or five models across one codebase and almost never record which one wrote what. So when quality drops, there's no way to tell a model problem from a prompt problem from a people problem. You're debugging with the label torn off.

Every productivity pitch for two years has been about typing less. Typing was maybe a tenth of the job. The rest was deciding what should exist and noticing when the thing in front of you is wrong. Neither got cheaper.

The hard case was never code that fails. It's code that runs, passes, reads fine, and is quietly wrong about one thing. Tests don't catch that and a fast skim doesn't either. It takes somebody who knows the system, and that person doesn't scale.

Output went up across the whole team. Review quality didn't, because it was never even to begin with. The gap between your strongest and weakest reviewer used to cost a few bugs a quarter. Now it's multiplied by every line an agent writes.

When an agent gets something wrong, the postmortem says the AI made a mistake. It didn't. A person read it and said yes. Accountability never moved. Only the typing did.

Big diff, tests green, the agent sounded certain, you hit approve. That isn't a review, it's a bet. And git blame will have your name on it, not the model's.

Teams keep saying they feel slower since adopting agents. They aren't slower at building. They're buried in output nobody put time on the calendar to read. The bottleneck moved and the process didn't.

AI made the first two years of an engineering career look skippable. Those two years are where judgment came from. Skip them and in five years you've got a team that can generate code and can't evaluate it. You can't hire your way out of that in the quarter you notice it.

Reading code you didn't write is a skill, and nearly everyone built it by writing a lot of bad code first. Juniors now read agent output all day and never do the writing half. We took away the reps that built the judgment and kept the part that needs it.

The agent writes the change in a minute, then it waits two days in review, because the one person who can actually judge it is holding forty other diffs. That's not a faster team. That's the same queue, moved to your most expensive engineer.

Writing code got cheap. Reading it did not. The engineer who can look at a large diff and say no is worth more than they were two years ago, not less. Every workflow worth building still assumes a human reads the thing.

An agent writes eighty percent of the change in about a minute. The last twenty percent is where prod breaks, and that part does not compress. Teams that optimized only the writing half moved their bottleneck. They did not remove it.

When something ships broken the ticket says the AI got it wrong. Which model. On what task. With what context. If nobody on the team can answer that, it is not a model problem, it is a logging problem. Put the model name in the commit.

Every AI coding demo builds the same thing. Empty folder, todo app, four minutes, applause. Your repo has a decade of decisions in it and one service nobody wants to touch. The gap between those two is the entire job. Judge tools on the second one.

Most agent failures are not reasoning failures. The model did not have the file. It did not know the convention. It never saw the ticket. Before you reach for a bigger model, go look at what you actually handed the one you have.

Loud failures are cheap. A test goes red, the agent retries, nobody is hurt. The expensive ones are quiet: correct syntax, plausible logic, wrong assumption, and it clears review because it reads well. A second model from a different family catches those. A tired human at five does not.

Eighteen frontier models in one workspace. Opus 5, GPT 5.6, Gemini 3 Pro, and the rest of the list. The length is not the point. The point is that the right model for a migration is not the right model for a formatting pass, and which one that is keeps moving.

A rename does not need your most expensive model. Neither does a doc fix or a formatting pass. Your team already routes compute by task size everywhere else in the stack. Model selection is the one place that habit stopped.

The eval that beats every leaderboard: take ten tickets your team already closed, run them through the model you are considering, and read the diffs yourself. That number will not match the leaderboard. Yours is the one that predicts your repo. It takes an afternoon.

The model that wrote the code is the worst available reviewer of it. Same weights, same context, same blind spot. It says yes because it genuinely cannot see what it already could not see. Route the diff to a different family than the one that wrote it. Who reviews yours?