Rolling out Codex to teams without losing the review gate

What changes when Codex teams scale past a few people

One engineer with an agent is a productivity story. Eight engineers with agents is a queue problem. Diffs arrive faster, they arrive larger, and the same two senior people are still the ones expected to read them. We have seen review latency triple in the second month of a rollout while everyone congratulated themselves on throughput.

Plan the review side first. Cap pull request size, formally. A limit of around 400 changed lines is arbitrary but it works, because it forces the agent-assisted work to be decomposed before it lands rather than after.

Share the configuration, not the prompts

Prompt libraries decay. Someone builds a Notion page of clever prompts, three people contribute, and by the next quarter it describes a workflow nobody uses.

What survives is configuration in the repository, because it is versioned and reviewed like everything else:

• AGENTS.md at the repository root with build and test commands, plus the conventions the model cannot infer.
• Per-package instructions in large monorepos, so a change in one service does not drag irrelevant context.
• A short list of directories that are generated or vendored, marked clearly so nobody's agent decides to refactor them.
• The team's chosen review prompt, checked in as a file so improvements propagate through pull requests.

When an engineer finds a phrasing that makes reviews catch more, they change the file and everyone gets it. That is the whole mechanism.

Two rollout patterns that waste a quarter

The first is the mandate. Leadership announces that everyone will use the tool, usage is measured, and engineers open sessions to satisfy the dashboard. The number goes up. Nothing else does.

The second is the enthusiast bottleneck. One engineer becomes very good, absorbs all the questions, and never writes anything down. When they take two weeks off the practice stops. Fix this by making them run a weekly half-hour where someone else drives while they watch, and by making the outcome of that session a commit to AGENTS.md.

Governance that is not theatre

Decide, in writing, three things. Which repositories are in scope. Whether agent-assisted changes are disclosed in the pull request description, and if so how. What happens when an incident traces back to a diff nobody read closely.

Our position on the second is that the author is accountable regardless of how the code was produced, so a disclosure label is mostly useful for the first quarter, when the team wants to know whether the review process is holding. After that it becomes noise. Set an end date for it when you introduce it.

On the third, be careful not to build a blame ritual. The useful post-incident question is what context the agent was missing and whether the repository configuration could have supplied it. That question produces a commit. Asking who approved it produces silence.

What to do next

Look at your last twenty merged pull requests and measure two numbers: median size and median time to first review. Write them down before you roll anything out. In six weeks, those two numbers will tell you more about the rollout than any usage dashboard.

If you want help putting this into practice, talk to us.