I’ve been fascinated recently at what the best practices in the new age of engineering look like. But it’s hard to find real data on best practices. For example, X has a ton of “information” about what’s happening at the cutting edge, but it’s very hard to validate whether any of it is real. Talks suffer from the same problem as an exec at a company can say anything they want or stretch the truth. Are people really not looking at any of their code? Are people productively using billions of tokens every day? It’s hard to get ground truth on that.

Because of that, I thought OpenAI’s open source Codex repo would be an good place to get a bit closer to ground truth:

• OpenAI’s internal teams have access to edge of the frontier (it’s rumored that Astra is a step change above GPT-5.6-sol for example)
• The Codex repo has been open source since it was launched in 2025, so there’s plenty of stuff that has happened in the open.
• OpenAI likely has the best pulse of any company in the world (save a few) on how to build software in the agentic engineering way

So I kicked off an analysis of the repo using a combination of Codex (gpt-5.6-sol) and Claude Code (Fable 5) to try to see what they were doing.

My immediate observation is that Codex has seen a step change increase in PRs per week over the last few months. In May 2025, the Rust implementation had 98 commits from six authors, and one person wrote 89 of them. In the first 25 days of August 2026, it had more than 1,000 commits from 135 authors. This is a big jump, and it’s an interesting convergence of a few factors: a) likely a lot of coding agent usage b) aggressive hiring for the team and c) heavy investments in guardrails and automation rules that make it easier for many people and agents to work at the same time.

Graduating from small team / handwritten-ish code to large team with agents

The public Codex repository started on April 16, 2025 as a TypeScript CLI. Since then, the repo has changed quite significantly. The initial era of the Codex repo had a small number of authors pushing out everything. For example, Michael Bolin wrote the original Rust implementation and also 150 of the first 169 Rust commits.

However, over time, this has changed dramatically:

The volume of changes grew roughly 8x, from 98 commits in May 2025 to 791 in March 2026. By August, the repository was already hitting 900 commits. Commit counts are an imperfect measure of output, especially as development practices change, but the surrounding evidence points to a similar story – there were more authors were shipping on the same day, across many more parts of the codebase.

Even though coding agents have recently gotten much better, part of the sizeable increase in Codex velocity comes down to sheer team size. OpenAI appears to have put a lot more people on the project (137 members now) and generally been able to keep people working on separate parallel streams of work (most authors seem to be working on separate, parallel crates).

With that many more people and agents changing the code at the same time, the rules around how they work become much more important.

Agent guardrails and rules

The first interesting thing is the repo’s AGENTS.md file. The Codex repo takes this fairly seriously: it’s clear they’ve put a lot of thought into and have been aggressive at removing slop and extras (the main file is 322 lines).

There are five rules in particular that I found interesting:

1. “Never add or modify any code related to CODEX_SANDBOX_NETWORK_DISABLED_ENV_VAR or CODEX_SANDBOX_ENV_VAR.” Some tests check these variables to figure out whether they can safely run nested sandboxing or network behavior. An agent might otherwise see those checks, decide they are getting in the way of a test, and “fix” them. I think it’s quite smart to find these types of cheating behaviors that you’ve seen in test runs and encode them as rules.

2. “Do not add tests for values that are statically defined” and “Do not add negative tests for logic that was removed.” These rules are aimed at tests that make a change look more rigorous without checking any meaningful behavior. Coding agents are very good at generating this kind of plausible-looking test volume, so explicitly telling them what not to test keeps the suite focused on behavior that can actually regress.

4. “Features that change the agent logic MUST add an integration test.” Agent behavior usually comes from the combination of context, tools, model responses, and the turn loop, so a small unit test often can’t tell you whether the agent will actually do the right thing. Codex’s TestCodexBuilder test harness runs the real agent loop against fake model streams. New tests are also supposed to use an automatic environment setup so they keep working when the app-server and exec-server are on different operating systems.

5. “Avoid bool or ambiguous Option parameters.” If an API can’t be changed, opaque values like false, None, or a bare number need an exact /*param_name*/ comment next to them. This is already more specific than what you normally see in an instruction file, but the interesting part is that they didn’t leave it as an instruction.

Lint rules

The ambiguous argument rule is probably my favorite example of what the team does next. Rust makes it easy to end up with calls like this:

foo(false, None, 1000)

It is basically impossible to review that without jumping to the function definition. The Codex team would prefer that you change the API, but when that is impractical they require comments next to ambiguous literal arguments:

foo(
    /*enabled*/ false,
    /*parent_turn_id*/ None,
    /*timeout_ms*/ 1000,
)

They then built a custom lint that checks whether the comment exactly matches the parameter name in the function definition. It was introduced in March 2026, applied across the Rust workspace a couple of days later, and then moved into Bazel CI.

The other thing worth saying is that these rules did not appear all at once. Support for AGENTS.md landed in May 2025. More detailed test guidance followed that summer. Snapshot requirements came in February 2026, the warning about codex-core in March, the trait guidance in April, and the model context and change-size rules in June. It looks a lot like the team is taking repeated review feedback and putting it somewhere that the next person or agent will see before making the same mistake.

You can see a rough pattern here: a problem first shows up repeatedly in code review, it gets written into AGENTS.md so humans and agents see it before making a change, and then the team turns it into a lint or CI check once the rule is stable enough. Not every rule makes it to the last step, but the expensive and objectively checkable ones tend to.

Codex has 38 lint rules, and I think it’s part of what makes the repo easier to work on as an agent because it has a large number of automated checks that prevent out-of policy behavior (and in a deterministic way).

Investing in an integration test harness

One other thing that I thought was interesting was how much the Codex team has invested in their tests. Tests compose about 615k lines (or 40%) of the codebase, and Codex has also invested in a full mock test harness: they’ve spent around 7k lines of code across 300+ commits to built out a harness that can stub out http responses from the Responses API. This integration test harness will run a real Codex thread, and it can call tools, apply approvals, and generally iterate on requests as if it’s getting responses back from the LLM. It’s a really interesting and deterministic way to test a large amount of behavior, and I think it’s quite smart to have invested so heavily in this because the Codex loop is ultimately the most important part of the product.

Another area that I was curious about (especially because our team has seen our test suites slow down as our coding agents get better and faster at writing tests), is how they’re still able to keep up speed of development despite a large number of tests. Codex doesn’t run the same enormous test suite at every stage. While someone is working on a change, the setup is to test only the affected Rust crate. If you change the terminal UI, for example, you run the terminal UI tests, not the entire workspace. This keeps the everyday edit-test loop reasonably fast.

Before a change is merged, CI broadens the coverage. Bazel runs the compatible Rust tests across macOS, Linux, and Windows, while separate jobs check the SDKs, formatting, dependencies, and repository rules. The largest workloads are divided across machines and reuse remote build caches.

After the code reaches main, Codex pays for a much more exhaustive pass. It runs the full Cargo test suite across five platform and architecture combinations. Each platform compiles the tests once, packages the resulting binaries, and distributes their execution across four machines. Slower native Windows checks, release builds, and remote-environment tests also happen here.

Basically, Codex has set up their environment so only relevant tests are run while developing, and get progressively more thorough as a piece of code gets closer to deployment. This makes it so you can still have fast deploys and ship quickly, while keeping safety and correctness in the long run.

Migrations with linting and feature flags

The other fascinating thing we observed in Codex’s codebase is some good old-fashioned, high-quality engineering. Their engineering team uses a combination of feature flags, linters, and other rollout mechanisms to ensure safety but also speedin rollout. Large changes are staged so the old and new implementations can coexist, and the migration plan is eventually encoded in lint rules instead of depending on everyone remembering it.

The TUI migration is a nice example. On March 16, the team created a temporary parallel implementation behind a tui_app_server feature flag. Ten days later, they enabled it by default. Once it was stable, they deleted the old TUI and retired the feature flag, while continuing to accept the old flag in configuration so existing users would not get an error.

Two weeks later, they added a CI rule preventing the TUI from importing codex-core directly. I think this is a particularly good way to finish a migration. It’s easy to clean up a dependency once, but on a team this large, someone will eventually add it back unless CI stops them. The feature flag made it easier to move over incrementally, and the lint rule made sure the team couldn’t accidentally undo the work later.

Conclusion: speed == testing, boundaries, lint, hiring

The Codex team is running and building upon a highly used, production-level codebase while moving incredibly quickly. They’ve ramped up velocity considerably in the last few months through a combination of AI coding agent usage as well as hiring for new team members. There are a lot more people working on Codex than there were a year ago and many of those people appear to be very effective engineers. Also, the codebase is explicitly organized to give agents context. OpenAI have invested in the tests and boundaries that let all of those people and agents work at the same time.

The interesting thing is that at least for the Codex team, as implementation got cheaper, it did not make the rest of engineering less important. Codex put a lot of work into a well-designed system, particularly focused on the classic parts of engineering excellence: testing, high quality boundaries and abstractions, automatic linting systems, and of course hiring good people. All of those things seemed to have gotten more important.