In a two-week pilot in August 2026 with a North American education-technology client, a two-person pod took 49 user stories to opened merge requests in about 48 elapsed hours, including the human approval gates, after seven working days of setup.
Three limits come with that sentence. The figure is self-reported from the pilot's run logs. The endpoint is a merge request opened, not merged. And quality outcomes haven't been measured yet. This article explains what the pod did, what the seven days bought, and what we can't yet say.
Key takeaways
- A pod is two people, a Forward Deployed Engineer and a Product Engineer, working with the Harnesses. People approve every plan and create every merge request.
- Seven of the ten working days went on access and configuration. The running took about two.
- The pilot started cold to the client's code, not cold to the tool.
- We haven't measured defects, review outcomes, effort or cost, and we are not quoting a speed-up multiple.
- Once the build got fast, the slow part moved upstream to requirements, design and approvals.
What did the pod actually do?
A pod is two people. The Forward Deployed Engineer owns the Harness on the account: configuring it to the client's estate, holding the approval gates and owning the merge request that reaches the client's repositories. The Product Engineer owns the work itself: turning requirements into stories the Harness can read, and judging the output against acceptance criteria. Agents write code, and people judge it. The Agentic Harness Orchestration page describes the three Harnesses behind it.
Every ticket follows one path of eight phases. Six of them stop for a human review: configuring the environment, discovery, requirements and open questions, the implementation plan, the implementation report and the merge request. One phase is an autonomous build loop, in which the agents develop, review and test until the work is clean. The last pushes the merge request. No agent can approve anything, and the Harness has no operation for merging.
Where did the seven days go?
The pilot ran from 17 to 31 August 2026. Week one was five days of configuration and no code. We were given access to the repositories and the tracker, then loaded the client's own standards into the Harness as versioned, machine-readable rules. Week two began with finishing that configuration. The run itself took two working days, followed by refinement.
The setup is the real price of the result: seven of the ten days went on setup. We expect most of it to be paid once per estate, with the run being the part that repeats. But we have one pilot, not a pattern, and we won't call it one until a second client confirms it.
How cold was the cold start?
We designed the pilot to remove our advantage. Neither person had worked on the client's project before. No product experts were available, and the pod worked in isolation. Everything they knew about the estate came from what the Harness discovered in the client's systems.
Two caveats belong next to that. One of the two people knew the Harness well, so the start was cold to the client's code, not cold to the tool. And the work started from the client's main branch with no existing code for the feature, so the Harness built on top of nothing. How it behaves on a large legacy codebase is an open question, and we say so.
What didn't we measure?
This is the list we would want to see before believing anyone's number, including ours.
- Quality. We have no figures for defects, review changes or acceptance rate.
- Merge outcomes. The endpoint is a merge request opened. We haven't published how many were merged, or what rework followed.
- Effort. We didn't record the two people's hours, or how much of the 48 hours was waiting on a human decision.
- Cost. We haven't published the model or infrastructure cost of the run.
- Independent verification. The figure comes from our own run logs.
We also have volume figures, such as lines of code and test cases. We aren't quoting them, because volume says nothing about whether the code is right. We haven't divided 48 hours by 49 to produce a per-story time either, since that is arithmetic, not a measurement, and it assumes the stories ran one after another.
The client's earlier build of similar work can't be compared like for like. The endpoints, samples and units differ, and the setup days sit on one side only. So we aren't publishing a speed-up multiple. If you want the habit behind that decision, we wrote about setting the pass mark before the test.
What changed because of the pilot?
The main lesson wasn't about speed. When the build step gets fast, the constraint moves to the steps that were always in the path and were never the slowest: requirements, design and approvals. The Harness didn't create that problem, it exposed it.
That is why we built the Requirements Harness, which is live with one client, and why we measured where upstream time goes before building anything else. Those measurements are the subject of where delivery time goes. The rules the agents work under, and why a person has to create every merge request, are in the rules our agents work under. How the same measurement-first approach extends beyond software delivery is set out in the ETA white paper.
When does this not apply?
This is one pilot with one client, on one epic, and it was a supervised proof, not production use. The Engineering Harness goes into its first client use in October 2026, and the Quality Harness is in development. A pod with a Harness suits work that can be specified, reviewed and verified. Plenty of engagements will keep running on conventional delivery alongside it, and we use whichever fits.
If you want to know how a pod would work on your estate, and what the setup would involve, talk to us. We will tell you what we would measure first, and what we can't yet claim.
About the author
How this was written. Drafted with AI assistance from Anitech's internal working papers and edited by Jack Dinneen.
