Shared context beats individual prompt skill
The best practices for running OpenAI Codex with an engineering team almost all reduce to one thing: put the standing knowledge in the repository, not in people's heads. Codex reads your project for context. If every engineer supplies that context verbally, in their own words, you get eight different house styles in the same service within a month.
Write one file at the repo root that carries the build command, the test command, the directory conventions, and the hard prohibitions. Commit it. Review changes to it like code. When someone finds a phrasing that stops a recurring mistake, it goes in the file rather than into a Slack thread that disappears.
Scope tasks so review stays possible
The number that predicts whether a team's adoption succeeds is median diff size. Agents will happily produce a 900-line change, and a 900-line change gets approved rather than reviewed. We have seen teams triple their throughput metric and simultaneously lose all real review coverage, which is a worse position than where they started.
What holds up in practice:
- One task, one concern, one pull request. If the description needs the word "and" twice, split it.
- Give the agent the test command so it verifies before reporting done. An agent that cannot run
pytestor your equivalent is guessing at correctness. - Cap what a single agent run may touch. Many teams draw the line at one service or one package.
- Require the human author to be able to explain every line. If they cannot, the diff goes back regardless of whether it works.
Write the delegation policy down
Every team we work with has an unwritten, inconsistent view of what agents may touch. Making it explicit takes about an hour and prevents the argument that otherwise happens during an incident. The common shape: routine feature work and test coverage are fine to delegate, while schema migrations, authentication paths, payment logic, and anything with a compliance surface require a human author and a named reviewer.
Your list will differ. What matters is that it exists and that new joiners read it in week one.
What goes wrong in month two
Adoption problems are rarely technical. The pattern we see: week one is enthusiasm, week three is a review backlog, month two is a quiet split where two engineers have gone all in and the rest have drifted back to their old workflow while saying otherwise in standup.
Catch it by watching review latency and pull request size rather than usage stats. Usage stats look healthy right up until they do not mean anything. Also be honest about the tools: agents are weakest exactly where your system's rules are unwritten, and every codebase has more unwritten rules than its owners believe.
Do this next
This week, do two things. Write the repo-root context file and get the team to agree on it in a single meeting. Then pull your last thirty merged pull requests and record median size and time to first substantive comment. Those two numbers are your baseline. Re-run them in a month, and you will know whether your adoption is working or just looking busy.