Harness engineering: leveraging Codex in an agent-first world

Ryan Lopopolo on five months of building an internal OpenAI product under one constraint: zero manually-written lines of code. Everything, application logic, tests, CI config, documentation, observability and internal tooling, came from Codex. About a million lines and roughly 1,500 merged PRs, starting from an empty repository in late August 2025, with three engineers driving the agents. That works out at 3.5 PRs per engineer per day, and the rate went up rather than down as the team grew to seven. They estimate it took about a tenth of the time hand-writing it would have.

Harness engineering is the name for what the humans did instead of coding. The scarce resource is human time and attention, so the job becomes designing the environment the agent works in: humans steer, agents execute. When something failed, the response was not to prompt harder but to ask what capability was missing and make it legible and enforceable. Review has largely followed:

Humans may review pull requests, but aren’t required to. Over time, we’ve pushed almost all review effort towards being handled agent-to-agent.

Most of the concrete work is making the running system inspectable by the agent. The app boots per git worktree so Codex can drive its own instance; the Chrome DevTools Protocol is wired into the agent runtime for DOM snapshots and screenshots; logs and metrics go to an ephemeral per-worktree observability stack the agent queries with LogQL and PromQL. Once that exists, prompts like ensure service startup completes in under 800ms or no span in these four critical user journeys exceeds two seconds become things you can actually ask for.

The context lesson is the one this repo copies. One big AGENTS.md failed predictably: it crowds out the task, everything being important means nothing is, it rots into stale rules, and a single blob resists mechanical checking. So AGENTS.md becomes a table of contents of roughly 100 lines, pointing into a structured docs/ directory that is the system of record, with linters and CI jobs validating that the knowledge base stays cross-linked and current and a recurring doc-gardening agent opening fix-up PRs for docs that no longer match the code. Give Codex a map, not a 1,000-page instruction manual.

Two things stop this being a straightforward recipe. Drift is real: Codex copies whatever patterns it finds, including bad ones, and the team spent every Friday cleaning up AI slop before they encoded “golden principles” and let background tasks open the refactors instead. And the post declines to generalise from its own results. On the end-to-end autonomy it describes, it says the behaviour depends heavily on the specific structure and tooling of this repository and should not be assumed to generalize without similar investment.