Harness Engineering: How OpenAI Built a Million Lines of Code With Zero Human Commits

⬅️ Back to Tutorials

In February 2026, OpenAI published a blog post by Ryan Lopopolo: a product had been built over five months with zero lines of human-written code. Around a million lines, roughly 1,500 pull requests, 3.5 PRs per engineer per day. No human ever typed a line of application logic.

This tutorial walks through Lopopolo’s two artifacts: the OpenAI blog post (the essay) and the lopopolo/harness-engineering repo (the reference implementation). The first is the why; the second is the how.

TLDR:

Read the OpenAI post in 20 minutes for the full argument: harness engineering is the practice of improving agent output by shaping the environment, not the model.
Clone Lopopolo’s companion repo for copy-ready templates: AGENTS.md, playbooks, evals, and a structured docs/ directory.
The core insight: hold the model constant, curate the two external levers, context and tools, and make nonfunctional requirements recoverable from the repo itself.
Everything in Lopopolo’s repo is CC-BY-4.0 licensed and designed to be pointed at alongside your own codebase.

Prerequisites: Familiarity with coding agents (Claude Code, Codex, Cursor). No prior harness experience needed.

Step 1: Read the OpenAI post

Open openai.com/index/harness-engineering. It is a long read but every section earns its space. Key sections:

We started with an empty git repository. The scaffold, CI, even the initial AGENTS.md were all written by Codex. No human code to anchor the system from day one.
Redefining the role of the engineer. Humans stopped writing code entirely. They worked depth-first: break goals into blocks, prompt the agent, identify missing capabilities when things failed. The fix was never “try harder.” It was always “what is missing from the environment?”
Repository knowledge as the system of record. A 100-line AGENTS.md serves as a table of contents, not an encyclopedia. The real knowledge lives in a structured docs/ directory. Linters and CI validate freshness and cross-links.
Agent legibility is the goal. Anything the agent cannot access in-context effectively does not exist. Google Docs, Slack threads, and people’s heads are invisible to the system. If it is not in the repo, the agent cannot use it.
Enforcing architecture, not micromanaging. Custom linters enforce dependency direction, structured logging, naming conventions, and file size limits. The error messages include remediation instructions for the agent.
Entropy and garbage collection. The team spent every Friday cleaning up “AI slop” until they encoded golden principles into the repo and automated the cleanup. Technical debt is paid down in small increments daily.

Step 2: Clone the companion repo

git clone https://github.com/lopopolo/harness-engineering.git

Open the README. The repo is Lopopolo’s anthology, field guide, and agent context bundle. It is designed to be pointed at alongside your own system: the AGENTS.md routes the task to the relevant arguments, cases, and proof.

The repo structure:

harness-engineering/
├── AGENTS.md           # ~100-line table of contents
├── ARCHITECTURE.md     # top-level map of concepts
├── docs/               # thesis index with deep arguments
│   ├── domain-modeling/
│   ├── durable-systems/
│   ├── last-mile-deployment/
│   └── ...
├── playbooks/          # application-specific harness blueprints
├── evals/              # harness evaluation scripts
├── sources/            # referenced material including the OpenAI post
└── assets/

Success: you now have a reference harness that you can study, adapt, or point your agent at alongside your own repo.

Step 3: Study the core documents

Open docs/ in the cloned repo. Three documents are worth reading first:

docs/domain-modeling/make-nonfunctional-requirements-recoverable.md The central argument: quality attributes (reliability, security, maintainability, performance, operability, risk posture, polish) must be retrievable from the repo as context, examples, tools, and executable constraints.
docs/durable-systems/make-coherence-cumulative.md How to turn feedback loops into cumulative coherence. Lessons from accepted work, corrections, and failures become context and checks that shape later agent trajectories.
docs/last-mile-deployment/ How the agent’s internal action language produces reliable domain outcomes for people who never review the implementation. The harness supplies context, capabilities, authority, and proof.

Pro tip: Do not just read these. Point your own agent at the repo alongside a task. Lopopolo explicitly designed it for that use. The AGENTS.md routes the agent directly to the relevant document.

Step 4: Run the evals (optional)

cd harness-engineering
# check which evals are available
ls evals/

The evals directory contains scripts that test whether a harness is doing its job. Run them against your own repo to measure how legible it is to an agent. Low scores tell you what is missing.

Success: you know your repo’s harness score and have a list of gaps to fix.

Step 5: Adapt the playbooks

The playbooks/ directory contains harness blueprints for specific scenarios. These are the closest thing to copy-paste templates. Adapt one to your project structure.

The key pattern from the OpenAI post: start small, let the agent build the harness itself. The initial AGENTS.md was generated by Codex. Your first harness file does not need to be perfect. It needs to exist and improve over time.

If it breaks

The companion repo is a reference, not a drop-in. Your specific stack will need different linters, different context files, and a different threshold for what constitutes “done.” Start with the AGENTS.md-as-table-of-contents pattern and a structured docs/ directory. Everything else follows from what your agent actually needs.