PulseFlow Tecnologia
← Insights
·6 min read·product-update·openai·harness-engineering·codex
PulseFlow Tecnologia

OpenAI Harness Engineering: what changes for engineering teams

OpenAI documented an internal experiment that works as both a case study and a product argument at once: a repository that started empty in August 2025, with the initial scaffold generated by Codex CLI (GPT-5), reached roughly a million lines of code in five months, with more than 1,500 merged pull requests - produced by just three engineers driving agents, with no line written manually by a human. The name OpenAI gives to the discipline behind this is harness engineering.

What changes: from writing code to designing the environment

The central shift OpenAI describes is one of role, not tool: when an engineering team's main job stops being writing code and becomes designing environments, specifying intent, and building feedback loops that let Codex agents do reliable work. The repository's initial AGENTS.md in the experiment was itself written by an agent - not by a human setting rules from the outside in.

Codex as the engine: isolation and iterative testing

Codex, the engine behind this experiment, runs on codex-1 (a version of o3 optimized for software engineering), inside an isolated cloud container, with no internet access during execution - it only sees the repository's code and the dependencies pre-installed via a setup script. The agent reads and edits files, runs tests, linters, and type checkers, and iterates until tests pass. Inside OpenAI itself, the most common use is exactly well-scoped, repetitive tasks - refactoring, renaming, writing tests - not open-ended generation of entire features without supervision.

Legibility: the requirement nobody used to document

The central lesson from the experiment is what OpenAI calls "legibility": the repository needs to be optimized so an agent can understand the entire business domain from the code and documentation itself - without relying on tacit context. When architecture decisions lived only in Slack conversations, they were as invisible to the agent as they'd be to a new hire on day one. The fix was bringing that context into the repository itself, where the agent actually looks - not as separate documentation, but as part of the code itself.

What this means for engineering leadership

The practical message for engineering teams isn't "adopt Codex" - it's that the repository's own structure becomes a decisive factor in agent productivity, the same way test coverage or technical debt is treated today. Teams that already document architecture, conventions, and decisions inside the repository (not in external knowledge tools) have an immediate advantage when introducing coding agents. Teams that rely on tacit context - conversations, meetings, unwritten knowledge - will feel that gap the first time they seriously try to use an agent at scale.

Sources