News · OpenAI's Codex team shipped a million-line product with zero human-written code

Jun, 295 min to read
Platform

OpenAI's Codex team shipped a million-line product with zero human-written code

An internal OpenAI team spent five months building a real product entirely through Codex agents. The interesting part isn't the code volume — it's what the engineers did instead of writing code.

The constraint that shaped everything: no manually-written code

The first commit landed in an empty repository in late August 2025. Five months later, according to the post, the repository holds roughly a million lines of code, and none of it was typed by a human. Even the initial scaffold — repository structure, CI config, formatting rules, package setup — was generated by Codex CLI running GPT-5, and the first AGENTS.md that tells agents how to work in the repo was itself written by the agent.

The team reports roughly 1,500 merged pull requests, an average of 3.5 PRs per engineer per day, and a headcount that grew from three engineers to seven while throughput went up rather than down. The product has hundreds of internal users and daily power users, so this isn't output for its own sake.

The 'no manually-written code' rule reads like a stunt, but the post is explicit that it was chosen deliberately as a forcing function. If humans can't fix things by typing, every failure becomes a question about the environment rather than the code: what capability is missing, and how do we make it legible and enforceable for the agent?

Making the running application legible to the agent

The bottleneck the team hit wasn't Codex's ability to write code — it was human QA capacity. Their response was to give the agent direct access to the things a human would normally look at. They made the app bootable per git worktree so Codex could launch its own instance per change, wired the Chrome DevTools Protocol into the agent runtime, and built skills for DOM snapshots, screenshots, and navigation.

They did the same for observability. Each worktree gets an ephemeral local stack of logs, metrics, and traces that is torn down when the task completes. Because the agent can query logs with LogQL and metrics with PromQL, prompts like 'ensure service startup completes in under 800ms' or 'no span in these four critical user journeys exceeds two seconds' become tractable instructions rather than aspirations.

This is the load-bearing idea in the post: as the author puts it, from the agent's point of view, anything it can't access in-context effectively doesn't exist. Knowledge in Slack threads, Google Docs, or people's heads is invisible. So the team treats a structured docs/ directory as the system of record and keeps AGENTS.md to about 100 lines — a table of contents, not an encyclopedia — with a recurring 'doc-gardening' agent that opens fix-up PRs when documentation drifts from real behavior.

Rigid architecture as a speed enabler, not a brake

The team wrapped the codebase in constraints that most organizations postpone until they have hundreds of engineers. Every business domain is split into fixed layers — Types, Config, Repo, Service, Runtime, UI — with dependencies only allowed to flow forward, and cross-cutting concerns like auth and telemetry forced through a single Providers interface. Everything else is disallowed and checked mechanically by custom linters, which are, of course, also Codex-generated.

The reasoning inverts the usual tradeoff. Strict boundaries feel pedantic in a human workflow; here they act as multipliers because once a rule is encoded it applies everywhere at once. Custom lint error messages even inject remediation instructions back into agent context, so a violation becomes a self-correcting loop rather than a blocked PR.

This is the kind of architecture you usually postpone until you have hundreds of engineers. With coding agents, it's an early prerequisite: the constraints are what allows speed without decay or architectural drift.Montana Labs

Notably, the team enforces boundaries centrally but leaves implementation free. They require parsing data shapes at the boundary but don't mandate a library — the model gravitated toward Zod on its own. They also chose to reimplement small utilities like a concurrency helper rather than pull in a generic package, because an in-repo version is fully inspectable and integrated with their instrumentation. 'Boring' technology wins here because it's stable, composable, and well-represented in training data.

Entropy is the recurring cost, and cleanup is now automated

Full autonomy created a new failure mode: Codex faithfully replicates existing patterns, including bad ones, so the codebase drifts. The team initially spent every Friday — a fifth of the week — cleaning up what they call 'AI slop.' That obviously didn't scale.

Their fix was to encode opinionated 'golden principles' directly into the repository and run background Codex tasks on a cadence to scan for deviations, update quality grades, and open targeted refactoring PRs — most reviewable in under a minute and automerged. They frame technical debt as a high-interest loan best paid down in small daily increments. Human taste gets captured once and then enforced continuously on every line.

The merge philosophy shifts accordingly. Blocking gates are minimal, PRs are short-lived, and test flakes are handled with follow-up runs rather than indefinite blocking. The team is candid that this would be irresponsible in a low-throughput environment; it works only because corrections are cheap and waiting is the expensive thing.

The specific lesson: the harness is the product engineers now build

OpenAI is careful to bound the claim. They say the end-to-end feature autonomy — reproduce a bug, record a video of the failure, fix it, validate by driving the app, record a resolution video, open and merge the PR — 'depends heavily on the specific structure and tooling of this repository and should not be assumed to generalize without similar investment.' They also admit they don't yet know how architectural coherence holds up over years in a fully agent-generated system.

The transferable takeaway isn't the million lines. It's that this team's engineering effort moved almost entirely into building the environment the agent operates in: per-worktree app instances, ephemeral observability, structured versioned docs, mechanically enforced layering, and self-correcting lint messages. Every time Codex struggled, the response was to add a missing tool, guardrail, or document — and to have Codex write that fix too.

For any team weighing agent-first development, the honest cost signal in this post is the scaffolding, not the prompting. The bottleneck was human attention, and everything they built was an attempt to spend less of it. The question worth carrying forward is how much of that harness investment a smaller team can afford before the throughput pays it back.

Find this story relevant to you?

Contact us to find a unique solution

Contact us

Need an AI engineering partner that can actually build?

We help businesses integrate AI, build AI-powered products, automate high-value workflows, and modernize the software systems behind them.

Get in touch

Related reading

More analysis around product delivery, operational AI, and the systems work that makes deployment hold up in reality.

Jul, 134 min to read
Platform

Doppel automates phishing takedowns with a five-stage GPT-5 and RFT pipeline

Jul, 134 min to read
Platform

Deutsche Telekom's bet that voice networks become the AI interface

Jul, 134 min to read
Platform

Meta's 5GW Louisiana Expansion Is Announced Through Teacher Bonuses, Not Teraflops