Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI

Ryan Lopopolo frames harness engineering around a fundamental change in how software gets built: when agents can produce, refactor, maintain, and delete code, typing out an implementation stops being the principal constraint. In his account, the limiting factors become human time, human and model attention, and the model context window. The engineering challenge shifts from personally executing every task to deciding how to deploy available model capacity effectively. 1:54

This changes the shape of engineering work. Instead of treating lower-priority improvements as permanently unaffordable, a team can delegate several candidate implementations and select one that solves the problem. Lopopolo gives localization and internationalization of internal tools as an example: capabilities that previously competed for scarce engineering attention become easier to incorporate when implementation can be delegated. This argument depends on available compute and token budgets; agent capacity is not presented as literally unconstrained. 1:54

The new role looks less like managing a personal queue of coding tasks and more like acting as a staff engineer for a mixed team of people and agents. Engineers still determine which problems matter, what acceptable software looks like, and which structures enable sustained execution. The objective is not to abandon engineering judgment, but to apply that judgment to systems design, delegation, and orchestration rather than to each individual line of code. 1:54

An agent cannot reliably reproduce a team’s standards if those standards exist only as tacit knowledge. Lopopolo points to documentation, architecture decision records, historical tickets, code reviews, and persona-oriented descriptions of successful work as the context that originally shaped a codebase. Harness engineering makes that context legible to agents, especially the many underspecified nonfunctional decisions involved in producing maintainable, reliable code. 6:56

The practical mechanism is to turn recurring expectations into durable guardrails. Security and reliability reviewer agents can inspect proposed changes during CI; repository-specific lint rules can require retries and timeouts around network calls; source-level tests can enforce architectural properties or keep files below a chosen length so they fit more comfortably within model context. When a failure occurs, its error message should explain the expected pattern and the remediation, giving both humans and agents a concrete next action. 11:21

A particularly important tradeoff is that building these safeguards can reduce short-term delivery speed. Lopopolo argues that teams should nevertheless investigate repeated mistakes, encode the missing requirement, and then step back once the problem has been addressed systematically. Team members with different strengths can contribute specialized standards once, allowing future agent executions to benefit from shared expertise in areas such as frontend architecture, reliability, scalability, and QA. 9:16

For Lopopolo, a useful harness is not an elaborate substitute for the underlying coding agent. Its essential job is just-in-time context delivery: presenting task requirements and quality expectations when they become relevant. Putting every rule into the initial prompt can overwhelm the agent, while long-running sessions and automatic compaction mean earlier instructions may eventually leave active context. Review comments, lint failures, test results, and skills can therefore refresh the relevant guidance throughout execution. 11:21

His React example makes the sequencing concrete. An agent can first explore and prototype the desired interface without being burdened by every structural requirement. Later, linting or testing can require the implementation to decompose components into smaller, more stateless pieces and follow the team’s preferred dependency patterns. The agent then revises the existing patch against those newly surfaced constraints, preserving room for exploration while still enforcing the final standard. 24:04

The workflow starts with a ticket and a limited set of skills that let Codex launch the application, start local observability, and attach browser tooling. Rather than maintaining a sprawling catalog, Lopopolo says his team concentrates leverage in roughly five to ten skills, improving those interfaces while allowing underlying development infrastructure to evolve. He also favors integrating with first-party harnesses, arguing that their tools and invocation conventions benefit from being included in model post-training, while repository owners focus on steering observable behavior. 20:16

Repository structure is part of the prompt. Lopopolo describes moving from an initially simple application repository to a PNPM workspace with 750 packages, organized around business domains and stack layers. The goal was to give agents concrete filesystem boundaries, enforce package privacy and dependency edges, and make most changes understandable within a limited subtree. Custom ESLint rules and structural checks also enforce shared utilities, deduplicated Zod schemas, and canonical implementations of common helpers. 21:26

Consistency reduces the amount of fresh context an agent must acquire in each part of the codebase. Lopopolo recommends standardizing recurring choices, such as bounded-concurrency helpers, instrumented commands, the ORM, programming language, CI scripts, and mechanisms for adding lint rules. In this framing, large-scale migrations become worthwhile because uniform patterns make the desired output easier for agents to predict and apply across the repository. 6:56

High implementation throughput also changes code review. When engineers were producing several pull requests per day, large overlapping changes created merge conflicts, and waiting for human review kept pull requests open longer. The team responded by separating code more clearly and dedicating a weekly garbage collection day to converting recurring review complaints into documentation, automated checks, and specialized reviewer agents. Persona-specific reviewers examine changes on each push and surface sufficiently serious issues, reducing repeated synchronous human intervention. 36:46

However, automation should not turn review into an inflexible obstacle course. Lopopolo describes GitHub pull requests and repository Markdown files as the shared collaboration surface for humans and agents, with implementation agents allowed to acknowledge, defer, or reject feedback. Requiring every comment to be addressed can overwhelm the coding agent and optimize for minutiae instead of accepted, useful changes; the desired balance is meaningful enforcement without perfectionism. 28:32

For teams beginning the transition, Lopopolo offers two practical entry points. First, ask agents to write tests for existing behavior, improving confidence in the current system while making the codebase easier for agents to navigate safely. Second, inspect where human time actually goes—manual implementation, slow CI, flaky tests, or waiting for review—and automate those bottlenecks incrementally. The purpose is to move people toward defining, prioritizing, sequencing, and delegating work. 30:28

He estimates his own token use as roughly split among planning and ticket or documentation work, implementation, and CI activity. Importantly, he does not treat an automatically generated plan as inherently useful: approving an unread plan can lock an agent into bad instructions. If a plan materially governs execution, he recommends treating it as a separate, carefully reviewed artifact with human approval; otherwise, a sufficiently well-specified ticket should let the agent proceed directly. Spending model capacity in CI matters because generated code becomes valuable only when it can be accepted and move the product forward. 40:01

The longer-term vision extends beyond writing and reviewing code. Lopopolo describes discovering that artifact-level QA and smoke testing were initially weak because agents lacked the necessary documentation and tools to download, launch, and inspect built software. He broadens the target to user-feedback triage, operational incidents, preventing PII leakage in production logs, support runbooks, and critical user journeys. The limitation is explicit: each newly encountered part of the software lifecycle requires its own tools, process documentation, and acceptance criteria before agents can handle it reliably. 43:35

His final mental model is the LLM as a fuzzy compiler: specifications, documentation, tests, review standards, and architectural constraints determine which generated implementations are acceptable. Different models may produce different code, just as different compiler backends produce different machine instructions, but the surrounding structure should preserve the required properties. In that model, durable value resides less in any particular generated implementation than in the human-defined objectives and constraints that guide repeated execution. 41:55