Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI
B · Useful, limited First-hand account from OpenAI engineer Ryan Lopopolo, whose team builds only through coding agents; concrete practices, but self-reported by a model vendor's staff with no measured outcomes.
Summary based on the full transcript·Original: about 46 minutes to watch
In short
A 46-minute AI Engineer London talk plus Q&A (April 2026) by Ryan Lopopolo of OpenAI, who has built software only through agents for nine months and bans his team from editing code by hand. His claim: implementation is no longer the scarce resource; human time, attention and model context are. The engineering job becomes "harness engineering": writing down non-functional requirements and surfacing them to agents at the right moment through docs, lints, tests and reviewer agents.
Key numbers
- over a billionoutput tokens a day the speaker consumes, per the session host
- 750packages in the team's pnpm workspace after restructuring the repo for agents
- three to fivePRs per engineer per day on a team of three
- 350 linesmaximum file length enforced by a source-code test to save model context
- five to 10skills the team centralises its agent tooling around
As reported by the source.
English·Video·opens youtube.com
What it reports
- Workflow: start from a ticket, hand it to Codex with a few skills that teach it to launch the app, the local observability stack and Chrome DevTools. Codex is the entry point, not a shell built around it.
- Guardrails as prompts: custom ESLint rules, tests on the structure of the source (package privacy, dependency edges, one canonical async helper, deduplicated Zod schemas), and lint messages that state the fix.
- Reviewer agents for security, reliability and other personas run on every push in CI and flag P2-or-above issues against written docs.
- "Garbage collection day" every Friday: each engineer turns the week's recurring review feedback into docs, lints or tests so the class of error stops.
- Repo restructured into 750 packages by domain and stack layer so agents can work within a subtree; one ORM, one language, one way to write CI scripts.
- Token split roughly a third each across planning and documentation, implementation, and CI. Plans approved without reading encode unwanted instructions; if used, review them as their own PR.
- Merge conflicts became the bottleneck at three to five PRs per engineer per day; fix was smaller code trees and shorter-lived PRs.
- Code described as a build artifact of the spec, with the LLM as a "fuzzy compiler".
How they got it
Personal practice of one internal OpenAI team, described in a conference keynote and a moderated Q&A. No metrics on defect rates, cycle time or cost beyond the token and PR figures quoted.
Limits
- Team of three building internal tools with unlimited access to the vendor's own models; cost and access do not transfer to most companies.
- No before-and-after data on quality or reliability.
- Strong advocacy framing ("code is free") from a model provider's staff.
- Auto-generated captions; names and some terms are mis-transcribed.
Why it matters for companies
The transferable part is organisational: senior engineers' review judgment has to be written into the repository as rules and checks, or agent output will not be trusted at volume. That shifts engineering capacity from writing code to writing standards, tests and review personas, and it makes documentation a production asset. Budget for a slower period while guardrails are built, and expect review and merge flow, not code generation, to become the constraint.
Summary based on the full transcript. Read the original for the full argument and data.Watch the original on youtube.com
- Tags
- Lecture