Skip to content

Harness Engineering

Definition (per ryan-lopopolo, AI Engineer London 2026): "How to build software when humans steer and agents execute." The discipline of operationalizing your codebase, dev environment, and team processes so that agents — not humans — do the full job of writing, refactoring, and maintaining code.

Core axioms

  1. Implementation is no longer scarce. "Code is free. We have an abundance of code to solve the problems that we come across." Hiring hands on keyboards is now constrained only by GPU capacity and token budgets.
  2. Human time, human attention, and model context window are the three scarce resources. The engineer's role is to move synchronous human time into higher-leverage activities.
  3. The agent is the full software engineer. "The models at this point are good enough where they're isomorphic to you and I in terms of the ability to produce code at high quality." Lopopolo's stance is stronger than agent-as-junior-engineer — it's agent-as-peer-with-infinite-patience.

What the practice looks like

  • Ban editors. Lopopolo's team works exclusively through the harness. "I've lived that experience by banning my team from even touching their editors."
  • Make the codebase legible to agents. Structure code, docs, and tools natively for model consumption — short files, predictable patterns, same-as-possible shapes to limit activation attention.
  • Write tests about the source code, not just the behavior. e.g. "a test that limits the fact that files are no longer than 350 lines" — adapting the codebase to fit the context window.
  • Non-functional requirements become prompts. See non-functional-requirements-as-prompts. "The important thing is not the code but the prompt and the guardrails that got you there."
  • Hub-and-spoke collaboration on PRs. Markdown files in the repo + GitHub are the broadcast domain. Agents and humans comment; implementation agent can acknowledge, defer, or reject feedback. "We optimize for throughput, we don't block on any sort of like contribution."
  • Centralize on 5–10 skills. "We don't go super wide on skills, preferring to mature them deeply." A skill teaches Codex how to launch the app, spin up observability, attach Chrome DevTools.
  • Leverage through systematic elimination. When agents repeatedly make a class of mistake, don't scold — write a lint, write a persona doc, refactor the codebase. "Taking short-term velocity hits in order to back up… put the guardrails in place so they stop making those mistakes."

Shifted priority stack

In the old world: P0s and P2s ship, "P3s will never get done." In the harness-engineered world: "all those P3s get kicked off immediately, maybe 4x in parallel. We pick one that solves the problem and in it goes." → see parallel-agent-competitions.

Reifications

In the Latent Space follow-up (ryan-lopopolo-latent-space-symphony-2026) Lopopolo packaged the discipline into concrete artifacts:

  • symphony — open-sourced agent orchestrator; the 0-layer + 6 reflection levels (policy, configuration, coordination, execution, integration, observability) are harness engineering as a framework
  • ghost-library — the distribution layer: ship the spec, let the agent re-derive the impl
  • agent-legible-software — files ≤350 lines, bespoke lints, agent-first observability; the concrete shape of "make it readable to agents"
  • dual-agent-pr-loop — author + reviewer agents tuned so neither bullies the other; the mechanism behind 0% human-reviewed code
  • skill-distillation — point Codex at its own session logs to improve itself; harness compounding over time

Connects to