Harness Engineering

Harness Engineering is a software development discipline, articulated by Ryan Lopopolo of OpenAI, concerned with designing the systems, conventions, and contextual scaffolding that govern how AI agents execute software tasks while humans steer at a higher level. Its central thesis is that as AI agents take over implementation work, the scarce resources shift from code-writing capacity to human attention and model context windows — and the harness is what manages those resources effectively.

Core framing: what has changed

Lopopolo opens with a foundational premise: "implementation is no longer the scarce resource of what it means to do the job of software engineering". Instead, human time, human attention, and model context window are the binding constraints. This reframing motivates the entire discipline: if code is cheap to generate, the engineering challenge moves upstream to context curation and harness design. Taken to its logical conclusion, code should be treated as a disposable build artifact rather than something to be carefully conserved.

The LLM itself is conceptualized as a fuzzy compiler: "all of the context that we're putting in the codebase for harness engineering is effectively like constraints and optimization passes" that determine what code is acceptable output — analogous to how compiler optimization passes shape machine code.

Key components of a harness

Progressive disclosure of context

Rather than front-loading all instructions, a good harness surfaces them at the right moment: "figuring out ways to either defer or just in time surface those instructions is kind of what a good harness should do". The corollary is that "all the harness should do is surface instructions to the model at the right time" — overwhelming an agent upfront is counterproductive.

Skills

Agents are given structured capabilities alongside their tasks: "we give that ticket to an agent along with a couple of skills that enable it to manipulate our app". Skills are discrete, reusable tools the harness makes available at appropriate points in a workflow.

Auto-compaction

Managing the context window over long-running tasks is handled via auto-compaction: "with autocompaction, which is a thing that has continued to improve", the harness can compress prior context rather than losing it or halting.

Review agents

Quality assurance is embedded in the harness itself via "reviewer agents that inject comments onto the PR that we require the agent to address before it is able to propose it for merge". Human review is thus reserved for higher-level judgment rather than catching routine errors.

Garbage collection day

Systematic elimination of recurring failure patterns — rather than managing them case-by-case — is a harness responsibility: "figure out ways to categorically eliminate it from ever happening in the first place".

Repository structure as harness input

A significant portion of harness engineering is not in the tooling itself but in how codebases are organized for agent consumption.

Small, isolated packages: "structuring your repositories in ways that you can actually scope the directory subtree you are looking in to be able to do most of the change helps". Scoping change sets to directory subtrees reduces the context an agent must load and contain.

Codebase uniformity: "you should have one programming language. You should have one way of writing CI scripts". Uniformity means that "regardless of where in the repository your agent is looking, it develops a ton of transferable context", making token output more predictable across the codebase.

Encoding context into the repository: When human code review identifies a recurring agent mistake, that is a signal the context was missing, not a prompt to do more review. The response should be "getting that into the repository and then figuring out ways to automatically prompt inject the agent" so the mistake cannot recur.

Leveraging first-party harnesses

Lopopolo notes a strategic reason to depend on first-party tooling like Claude Code: "there is leverage to be had by depending on these sort of like first-party harnesses directly", because models are post-trained in the context of the harnesses in which they are primarily deployed. First-party harnesses receive this post-training alignment by default; custom harnesses do not.

Failure modes the harness must eliminate

The clearest diagnostic for harness failure is human interruption: "every time I have to type continue to the agent is like a failure of the harness to provide enough context" around what it means to continue to completion. Any point where an agent stalls waiting for human input is a gap in the harness's context provision.

Durability of the approach

Lopopolo argues this investment is not subject to model capability obsolescence: "this sort of thing is not going to be obsoleted by increases in model capability". Providing context at the right time is a durable engineering principle regardless of how capable underlying models become, making harness engineering a long-term structural investment rather than a workaround for current model limitations.