Overview
This post from zhichai.net discusses OpenAI's "Harness Engineering" concept, based on Ryan Lopopolo's article Harness engineering: leveraging Codex in an agent-first world (February 11, 2026), with related coverage from a Latent Space interview with Sherwin Wu.
Key points
The experiment
- Starting from an empty Git repository, OpenAI built a real, deployable software product in 5 months with zero human-written code
- ~1 million lines of code, ~1,500 PRs, driven by only 3 engineers directing Codex
- Estimated delivery speed roughly 1/10 of traditional hand-coding
- The product has internal daily active users, external alpha testers, and a real deploy/crash/fix lifecycle
- Source article: Harness engineering: leveraging Codex in an agent-first world
- Author: Ryan Lopopolo (OpenAI), published February 11, 2026
- Related podcast: Latent Space interview with Sherwin Wu
What Harness Engineering means
Traditional software engineering: humans write code, AI assists. Harness Engineering: humans design the environment, AI executes. Engineers shift from writing code to designing environments, specifying intent, and building feedback loops.
Core principles
1. No manual code — everything from CI config to tests, docs, observability, and internal tooling is generated by Codex, including the initial AGENTS.md file itself.
2. Deep-first work method — decompose goals into small building blocks, prompt agents to build them, then use them to unlock more complex tasks. When something fails, ask "what capability is missing?" rather than "retry."
3. Progressive disclosure — a monolithic AGENTS.md failed: context is scarce, too much guidance equals no guidance, and the manual rots. Solution: treat AGENTS.md as a directory pointing to organized docs (ARCHITECTURE.md, docs/design-docs/, docs/exec-plans/, docs/SECURITY.md, etc.), not an encyclopedia.
4. Make the app agent-readable — every git worktree can launch an app instance; Chrome DevTools Protocol is wired into the agent runtime; logs, metrics, and traces are exposed via a local observability stack (LogQL/PromQL queries). This makes prompts like "ensure service startup completes within 800ms" feasible.
5. Enforce architecture and taste via invariants — data shapes parsed at boundaries (model chose Zod itself), fixed layer ordering (Types → Config → Repo → Service → Runtime → UI), cross-cutting concerns through explicit Providers. Enforced by custom linters (also Codex-generated).
6. Throughput changes merge philosophy — minimize blocking merge gates, keep PR lifetimes short, resolve flaky tests with reruns. Corrections are cheap; waiting is expensive.
7. Entropy and garbage collection — agents copy existing patterns including bad ones, causing drift. Weekly human cleanup didn't scale; instead, codify "golden principles" and run periodic background Codex cleanup tasks that open targeted refactor PRs, mostly reviewable in 1 minute. Technical debt is like high-interest debt: small continuous payments beat painful lump-sum fixes.
Agent readability
Context the runtime can't access effectively doesn't exist. Knowledge in Google Docs, chat threads, or people's heads is invisible to the system. Repo-local, versioned artifacts are all the agent sees — an undiscoverable Slack discussion is as unreadable as onboarding material a new hire never receives.
The engineer's role redefined
Sherwin Wu (OpenAI API & Developer Platform engineering lead): IC engineers are becoming tech leads — essentially managers of "fleets" of agents. Engineers now run 10–20 parallel threads; 95% of engineers use Codex daily, and 100% of PRs are Codex-reviewed. Engineers who use Codex more submit 70% more PRs, with the gap widening.
Code review revolution
Codex reviews 100% of PRs, shrinking review from 10–15 minutes to often 2–3 minutes, since suggestions are pre-baked. Human attention per PR dropped from 100% to ~30% — though most engineers still glance at PRs themselves.
Rising autonomy
From a single prompt, agents can now: verify repo state, reproduce a reported bug, record a video of the failure, implement the fix, verify it by driving the app, record a second video, open a PR, respond to agent/human feedback, detect and fix build failures, escalate only when judgment is needed, and merge. This depends on the repo's specific structure and tooling investment — don't assume it generalizes yet.
Advice for developers
1. Start simple — don't build giant control flows 2. Build deletable things — new models will replace your logic 3. The harness is the dataset — competitive advantage lies in captured trajectories, not prompts 4. Make things agent-readable — repo knowledge is the system of record 5. Enforce invariants, not micro-management of implementation 6. Accept entropy — build garbage collection mechanisms
Conclusion: the sorcerer's apprentice
Sherwin Wu compares the experience to *The Sorcerer's Apprentice* from Fantasia: immense power, but only if you know what you're doing. Letting go entirely leads to runaway floods — the extreme form of vibe coding. Running 20 Codex threads demands skill, seniority, and judgment. Yet the leverage is extraordinary: a senior engineer fluent with these tools now accomplishes previously impossible workloads.
The magic feeling has never been closer to reality.
---