Nobody Will Fund the Harness, and That's Rational

Chapter 16 - Team Topologies, public goods, and the economics of code review

The Agentic Development Lifecycle - @praveen govindaraj

Nobody Will Fund the Harness, and That's Rational
Chapter 16 of The Agentic Development Lifecycle — Team Topologies, public goods, and the economics of code review.
Your organization has a platform team, a developer productivity budget, and AI coding agents. Yet code reviews are still slow, and humans must inspect every change to decide whether it's safe.
The bottleneck hasn't disappeared. It's moved from writing code to verifying it.
And one reason it stays there is simple: everyone uses the harness, but nobody owns the economics of building it.
The harness is a public good
An agentic development harness includes the tests, validation rules, execution environments, and evidence that help teams trust AI-generated changes.
A good harness lets reviewers focus on exceptions instead of repeatedly checking routine properties.
So why doesn't every team invest in one?
Because the benefits are shared, while the costs fall on whoever builds it.
One team might spend weeks developing reusable validation infrastructure. Other teams benefit, but the original team pays the engineering cost.
Nobody needs to be selfish or incompetent for this to happen. The incentives alone can produce it.
A shared harness is a public good inside an organization. Asking teams to care more won't fix the funding problem.
More code doesn't mean more throughput
Coding agents can produce changes faster than humans can review them.
When that happens, the queue moves downstream. Reviewers face more pull requests, larger diffs, and more evidence to evaluate.
This is where Brooks's law offers a useful lens: adding producers to a constrained system doesn't automatically increase throughput.
The chapter discusses research reporting a 2.09× increase in per-capita throughput alongside roughly doubled reviewer load in the studied setting. These figures aren't universal constants, but they illustrate the challenge.
If review capacity doesn't keep pace with code production, faster generation can simply create a larger review queue.
Who should own the harness?
Three common approaches have predictable weaknesses:
• Nobody owns it: Teams duplicate tools and develop inconsistent standards.
• Every team owns everything: Teams repeatedly solve the same infrastructure problems.
• A central team owns everything: The platform team becomes a queue that other teams must wait on.
A more balanced model separates responsibilities:
• Platform teams build reusable templates and shared capabilities.
• Stream-aligned teams own the harness instances used for their products.
• Enabling teams help teams establish reliable practices and become self-sufficient.
The goal is shared infrastructure without creating permanent dependence on a central team.
Advisory checks aren't enough
Consider two automated checks.
One posts a comment saying a change may violate a rule. A human must investigate and decide what happens next.
The other blocks the change until the violation is resolved.
Both detect problems, but only the second can prevent routine issues from entering the review queue.
An advisory bot adds review work. A trusted blocking check can remove it.
Blocking checks must be reliable, understandable, and properly maintained. Otherwise, false positives create frustration and teams find ways around them.
Measure whether automation reduces human review effort—not how many comments or checks it produces.
Tokens are measured. Review time often isn't.
AI usage can be measured in tokens, API calls, and compute costs. Human review is harder to track.
A team might reduce code-generation costs while increasing the time reviewers spend reconstructing context and verifying results.
A complete view of agentic development must consider both:
• What does it cost to produce a change?
• What does it cost to verify that change?
• How much human attention is needed before it ships?
The objective isn't to eliminate human judgment. It's to stop spending expert attention on routine properties that trustworthy automation can verify.
Two practical steps

1. Sample automated decisions. Independently audit a sample of changes that pass the harness. Use the results to identify gaps and determine whether the checks deserve the trust placed in them.
2. Make ownership explicit. Name the people responsible for shared infrastructure, maintenance, and incorrectly failing checks. Allocate time for improvement instead of treating maintenance as invisible work. Shared benefits require an explicit ownership model. Try this week: name the owner Choose one harness your team depends on and write down who owns it. Ask: • Who maintains its shared capabilities? • Who owns the product-specific configuration? • Who fixes unreliable checks? • How do we know it's reducing review work? If nobody can answer, you've found an organizational bottleneck. The takeaway Agentic development isn't just about getting AI to write code. It's about building systems that let people trust that code without manually reconstructing every detail. The harness may benefit everyone, but it won't maintain itself.

📖 Read Chapter 16: Team Topologies and Review Economics.

Your turn
Who owns the harness where you work—the platform team, individual product teams, or nobody in particular?

Share your experience in the comments, and follow along as I explore The Agentic Development Lifecycle, one chapter at a time.