How I build the Agent Harness, 10,700 lines changed in hours while keeping the quality bar
The result
| Files Changed | 85 |
|---|---|
| Lines added | 10,712 |
| Total Commits | 46 (42 by the agents) |
| Test runs on the merged code | 614, all passing |
| Planted defects caught by the tests | 28 of 28 |
| From merge request to merge | about 4 hours 15 minutes |
My harness conducts multiple agent sessions that built a production feature in hours with adversarial reviews, and run comprehensive tests, keep high bar quality of code changes.
That volume should worry anyone who has reviewed code. It held up because the harness I run assumes every model will sometimes be wrong, and checks each claim before it reaches a person or a system we don't own.
Four sessions, one job each
The conductor, on Fable 5.1, reviews and gates. Runner 2, on Opus 5.5, builds epic 2: the code, tests and charts. Runner 1, also on Opus 5.5, keeps epic 1's specification and watches the conductor's writes. An upper level reviews the text before it reaches the client team. I'm the only human in the loop, and I make every call that can't be undone: revert, push, post, approve, merge.
Tests that had to fail first
Before the tests were trusted, Runner 2 planted 28 defects in scratch copies of the code, one at a time. The suite caught all 28. Integration tests ran against real PostgreSQL and Kafka, and the gateway's tests ran inside the built container over a real TLS stream.
What kept the quality up
- Nobody checks their own work. Whoever wrote something never reviews it.
- Reviews are files. Each names what it checked. Seven review rounds ran before the merge request opened.
- Re-read the source before every claim. Tickets, merge request and branch, pulled again in the same turn.
- Approvals are files, too. Nobody acts on an "approved" in a chat line.
- Every write to someone else's system is watched live. 33 requests over three days, none unwatched.
- Guards are hooks. Off-limits paths are refused by the tooling itself.
- Context loss is planned for. Each session keeps an anchor file. Three context resets that day; no step lost.
- I write the command, the resource, the expected effect, a snapshot, and the rollback.
- Watcher reads them and records a GO.
- The command runs once.
- The result is read back from the server.
- It's compared by hash.
Caught before anyone saw it
| What | Caught by |
|---|---|
| Two regressions introduced by an earlier round's fixes | a review round |
| A safety-hook fix that passed only its own 51 tests | 57 attack cases written by Runner 1; the fourth build held |
| 20 findings on the previous feature's specification | a standing red team; all 20 accepted |
How I work
This is how I run AI agent teams on production work. Beyond this one day, I've implemented multiple agent-driven campaigns in production at scale. More on the method in AI Boost.
Discuss it on LinkedIn.