Grading Ourselves Against the Harness Engineering Playbook - Orbital Witness<br>Grading Ourselves Against the Harness Engineering Playbook<br>Scoring our agent harness against OpenAI's twelve open-source theses.<br>Andrew Thompson<br>July 22, 2026
We’re hiring! Explore our Product Engineering Guide to learn how we build at Orbital.
Last Saturday, Ryan Lopopolo pushed a repo to GitHub called harness-engineering. If the name doesn’t ring a bell, his earlier work will: Ryan wrote OpenAI’s Harness engineering: leveraging Codex in an agent-first world, the post from February where a team of three engineers (later seven) shipped roughly a million lines of code in five months with zero hand-written lines . Around 1,500 merged PRs. About 3.5 PRs per engineer per day. Every line, from application code to tests, CI, docs and observability, was written by agents.<br>The line from that post that stuck with everyone was four words long: “Humans steer. Agents execute.”<br>The new repo is the ideas from that post grown up into an opinionated thesis-and-playbook bundle: twelve theses about how to build the environment around a coding agent, three operational playbooks for improving it, and an AGENTS.md at the root, because the repo is designed to be read by your agent, not just by you.<br>We read it cover to cover (well, we and our agents did). And since we’ve spent the last 6 months building our own harness at Orbital, we thought it would be fun to do the honest thing: score ourselves against it, publicly. Here’s what we’re already doing, where we’d add nuance, and the parts we haven’t built yet but want to, both ourselves and alongside people we’d hire to work on exactly this.<br>What a harness actually is<br>If you missed the February post: harness engineering starts from an unfashionable premise. Stop obsessing over the model. Hold the model and the coding agent constant, treat them as a black box, and notice that you’re left with exactly two levers: the context the agent can reach, and the tools it can operate . That’s the harness: everything wrapped around the model that turns raw capability into shipped, trusted work.<br>The deeper argument, the one that runs through all twelve theses in the repo, is that your organisation’s most valuable knowledge is what Ryan calls the private process-data iceberg : your domain ontology, your quality bar, your exception history, who’s allowed to approve what. No frontier model will ever have that in its weights, because it lives in your heads and your Slack threads. The job of the harness is to move it somewhere an agent can retrieve it. And when an agent fails, the discipline is to ask “what capability is missing from the harness?” rather than just fixing the code by hand and moving on.<br>We didn’t need convincing. As we wrote in Everyone Ships Code Now, something shifted for us over Christmas 2025, and we’ve been rebuilding how we work around tiny teams ever since. What’s changed since February is the evidence.<br>The harness we’ve been building<br>We’ve come to treat the harness as a product in its own right, not a drawer of helper scripts: it has owners, a roadmap, and a quality bar of its own. Most of this post is about the pieces that make it work, but it’s worth starting with why we bother. The easiest place to see whether the investment is paying off is throughput, how much reviewed, shippable work each engineer actually gets out the door.<br>Weekly merged PRs per contributor have climbed steadily since May, when the harness’s impact started to show up clearly in our numbers. On a legacy codebase with the harness switched on, throughput has roughly doubled: it started around 3 a week and now averages in the mid-to-high single digits, mostly landing in a 6-to-7 range. On a newer codebase built fully around the harness the gains are larger but a lot more volatile (fewer people work in it, the work there is far more varied as we build out the core harness itself, and agentic coding turns out to be genuinely addictive), swinging between the low teens and low twenties from week to week; averaged over recent weeks it runs at roughly three times the harness-enabled repo. It’s worth pausing on that. These aren’t vanity PRs: every one clears the same review bar, type checks, and CI gates as before, with most of the review now handled by coding agents and humans checking the rest. If the pattern holds, a codebase built fully around the harness is roughly three times more productive to work in than one that has merely switched it on. That is not a marginal gain; it’s a step change.<br>Weekly merged PRs per contributor, May to July.<br>The number that matters to us isn’t lines of code; it’s throughput per person at the same quality bar. A few of the load-bearing pieces, in roughly the order an agent meets them:<br>The repo teaches the agent. A short root...