OpenAI's public material describes two connected systems. One team redesigned a repository so Codex could build, test, review, and maintain a working product. It then created Symphony to assign issue-tracker work to isolated Codex sessions and keep those sessions running until people could review the result.
Harness engineering changes the repository around the agent
OpenAI's harness-engineering account follows an internal product built under a strict experiment: no manually written code. Over five months, a small team used Codex to generate application code, tests, CI configuration, documentation, observability, and internal tools.
OpenAI reports roughly one million lines of code and about 1,500 merged pull requests, with three engineers initially directing the work and seven later. The team estimates that it built the product in one tenth of the time manual coding would have required. The product had internal daily users and external alpha testers.
Harness engineering means improving the environment around an agent so it can do reliable work. In this experiment, people specified intent, designed the system, improved the tools, and encoded feedback. Codex performed the repository changes.
The time estimate is a team judgment about a counterfactual project that did not happen. Lines of code and pull-request count measure production volume, not usefulness or maintainability. The experiment also started with an empty repository, which makes it different from changing a mature product with years of hidden assumptions.
The repository becomes the shared memory
The team kept a short AGENTS.md as a map, then stored architecture, product specifications, execution plans, reliability guidance, and design decisions in a structured docs directory. Mechanical checks verified that the knowledge remained linked and current. A recurring documentation agent looked for stale material and proposed repairs.
This approach is called progressive disclosure. The agent receives a small map first and loads deeper context only when the task needs it. It protects the context window from a large instruction file while keeping important decisions close to the code they govern.
The application could start once per Git worktree, giving each change an isolated instance. Codex could inspect the browser through Chrome DevTools and query task-local logs, metrics, and traces. Architectural dependency rules, data-boundary checks, file-size limits, and other invariants were enforced by linters and structural tests.
These feedback loops made product behavior legible to the agent. A request such as keeping startup below a time limit can only be delegated when the agent can run the system, measure the result, and tell whether its change helped.
Symphony turns the issue tracker into a control plane
The team later published Symphony, an open-source specification for coordinating coding agents. Symphony watches a project board such as Linear. Each active issue receives an isolated workspace and an agent session. The agent can use repository tools, create several pull requests, read review feedback, and continue until the issue reaches a terminal state or needs human input.
The issue tracker acts as a control plane: it records the work, status, ownership, and human decisions while execution happens elsewhere. Instead of supervising terminal tabs, a person reviews the deliverable and its evidence in the ordinary product workflow.
The public Symphony repository is an engineering preview centered on a language-independent specification. It is inspectable starting material, not a hosted production service or proof that a particular implementation is safe for every repository.
Agent-to-agent review protects human attention
For a pull request, Codex reviews its own changes, requests focused reviews from other agents, responds to agent and human comments, and iterates until the required reviewers are satisfied. People may review changes, but the experiment moved much of the routine review burden to agent-to-agent loops.
This changes where people spend time. Engineers inspect goals, architecture, product behavior, exceptions, and the quality of the controls. It also creates a new risk: several agents can repeat the same blind spot. Deterministic checks and independent human judgment remain important where the consequence is high or the success condition cannot be expressed completely.
Company-wide adoption adds scale, not outcome proof
OpenAI's June 2026 work study says the average OpenAI engineer generated 99 percent of their output tokens through Codex rather than ChatGPT. Among daily active internal users, people at the 99th percentile generated more than 60 hours of Codex agent turns per day across parallel agents.
Tokens and agent hours show how the tool is used. They do not measure accepted code, customer benefit, cost effectiveness, or quality. The paper estimates human task duration with a model judge and says those horizon estimates should be treated as directional.
The evidence comes from a bounded experiment
OpenAI authored all three operating accounts. The harness article describes one new product and says the team still does not know how coherence will evolve over years. Public material does not provide raw review data, defect trends, full operating cost, abandoned runs, or a controlled comparison. Symphony is public, while the internal product, repositories, prompts, tools, and usage data remain private.
What a product team can copy
Make the repository the current source of product and engineering knowledge. Give agents isolated, runnable applications plus direct access to tests, logs, metrics, and interface evidence. Enforce architecture with exact checks. Use the issue tracker to hold durable state while agents work elsewhere. Start with a bounded product line, and measure accepted outcomes, rework, defects, cost, and human attention alongside generation volume.