Addy Osmani's Post

Addy Osmani · article · 2026-08-01 source ↗ Reader 🖥️

Agent Harness Back Pressure (Verification-Bound Autonomy)Code Quality Feedback Loops Guardrails Orchestration Tax / Human Review Bottleneck

Because agents can now generate more code than people can read, software quality control must move from human inspection of the code itself into deterministic constraints (tests, checks, metrics) engineered into the harness and environment around the agent.

practical · argumentative — A compressed practical argument: two premises (review no longer scales; therefore quality checks must live elsewhere) drive an imperative conclusion ('Set your constraints'). Not expository — it is making a claim and asking the reader to act on it, not just describing a state of affairs.

Structure

Part	Role
Opening thesis: "Software quality now depends on the constraints you set around your agents."	thesis
Historical baseline: when humans manually wrote code, quality was assessed by reading the code itself (clean, thoughtful, fast, understandable, tested).	context / contrast baseline
The shift: agents generate more code than people can read, so once generation scales beyond review, quality checks must live somewhere else.	core premise
Location claim: quality moves into the harness, environment and operating system around the agent.	conclusion of the shift argument
Elaboration: names the mechanisms — deterministic checks including unit tests, property tests, acceptance tests, mutation testing, quality metrics.	evidence / concretization
Reframe: "This back-pressure lets the system resist bad work before it becomes somebody else's problem."	systems-control framing
Closing imperative: "Set your constraints. They decide whether the code your agents generate is good enough to ship."	practical conclusion / call to action

Key terms

constraints
The deterministic tests, checks and metrics engineered around an agent that define and bound what output is acceptable — not vague guidelines but specific, automatable mechanisms (unit tests, property tests, acceptance tests, mutation testing, quality metrics).
harness Agent Harness
The environment, tooling and operating-system layer around the agent — the place quality control moves to once it can no longer live in human code review. Used interchangeably with 'environment' and 'operating system around the agent.'
back-pressure Back Pressure (Verification-Bound Autonomy)
A systems/queueing metaphor: constraints act as resistance that stops bad work from propagating downstream before it becomes someone else's problem, rather than a filter applied after the fact.
quality Code Quality
An itemized, checkable bundle: correctness, maintainability, security, performance ("etc.") — implicitly reduced to properties a deterministic check could plausibly verify.

Propositions

explicitSoftware quality now depends primarily on the constraints set around agents rather than on manually inspecting the code they produce.conf: high
explicitWhen humans manually wrote most code, its quality could be judged by reading the code itself — cleanliness, thoughtfulness, speed, comprehensibility, and test presence.conf: high
explicitAgents can now generate more code than people can read, so once code generation scales beyond human review capacity, quality checks must be located somewhere other than manual code reading.conf: high
supportsAgentic Code Review · p1 — Independently states the same review-bottleneck premise — code generation has outpaced human reading/understanding speed — corroborating it from a different author and framing.
explicitQuality control relocates into the harness, environment, and operating system surrounding the agent, rather than residing in the code or in code review.conf: high
explicitConcrete quality mechanisms are deterministic checks — unit tests, property tests, acceptance tests, mutation testing, and quality metrics — that decide what the agent-driven system is allowed to do.conf: high
supportsArchitecture as Code to Teach Humans and Agents About Architecture · p3 — Both claim agents can only be trusted to produce acceptable output when deterministic constraints (tests/metrics here, architecture-as-code there) define success, rather than relying on human judgment per instance.
explicitdevelopedWell-designed constraints act as back-pressure, letting a system resist bad work before it propagates downstream and becomes someone else's problem.conf: high
extendsThe Orchestration Tax is You · p20 — Osmani's earlier essay warned that a system not designed around the human review bottleneck will silently lower its standards; this post supplies the deliberate design (constraints as back-pressure) that is meant to prevent exactly that silent erosion.
extends ←Maintainability sensors for coding agents · p5 — Osmani's general claim that well-designed constraints act as back-pressure, resisting bad work before it propagates, is given a specific mechanism here: letting the agent raise (not suppress) a numeric threshold preserves the back-pressure for the future instead of removing it.
extends ←Own the Outer Loop · p11 — Restates the harness-constraints-as-backpressure claim and sharpens it into an explicit autonomy-sizing principle ('just enough autonomy... not one inch more' in spirit).
implicitConstraints are a precondition, not an optional add-on, for loops of agents to deliver production software reliably at scale.conf: medium

Arguments

Quality assurance must shift from human code review into deterministic constraints embedded in the agent's harness/environment.

Explicit premises:

Agents can now generate more code than people can read.
Historically, when humans wrote the code, its quality was verified by directly reading the code.

Implicit premises:

Human review capacity is fixed and does not scale with the volume of agent-generated code (the review-bottleneck premise the post never states outright).
Deterministic, automatable checks (tests, mutation testing, metrics) are an adequate proxy for the fuller quality checklist the post itself opens with — correctness, maintainability, security, performance, and even 'is it clean/thoughtful/understandable.'

Inferences:

If an agent-generating system lacks well-designed constraints, quality will silently degrade rather than fail loudly, because neither human review capacity nor an automated substitute is present to catch it.
The design effort in agentic software delivery shifts from writing code to writing and maintaining the harness's constraints — a different, likely underinvested, skill.

Questions addressed

✅ How should software quality be assured when agents produce more code than any human can review?
Move quality control out of human code review and into deterministic constraints and checks (tests, mutation testing, quality metrics) embedded in the harness/environment around the agent.
⭕ Which quality dimensions can actually be captured by deterministic, automatable checks, versus which require irreducibly human judgment (e.g., 'is it thoughtful,' 'is it clean')?
Not addressed — the post silently narrows from its own opening checklist (clean, thoughtful, understandable) to the subset that automated checks can verify (correctness-flavored properties), without acknowledging the narrowing.

Gaps

incompleteThe post never addresses who builds, tests, and maintains the constraints themselves — the harness's tests and deterministic checks are also artifacts that can be under-specified, become stale as models change, or be gamed/weakened by the very agents they're meant to bound. It treats 'set your constraints' as a one-time, self-evidently sufficient act rather than an ongoing engineering discipline with its own failure modes.
Read next: extract-agentic-code-review.json (p15: agents will weaken CI to make themselves pass) and extract-anthropic-harness-design-long-running-application-development.json (harness components encode assumptions that go stale as models improve) — both treat the harness itself as needing continuous tending, which this post takes for granted.
closed byThe New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering — That gap asks who builds, tests, and maintains the harness's own constraints on an ongoing basis. This paper's 'for engineering leaders' advice answers directly: treat AGENTS.md, system prompts, eval suites, and skill libraries as code — reviewed in pull requests, versioned with the project, owned by named engineers — framing it explicitly as an ongoing discipline ('without this discipline, the harness drifts') rather than a one-time setup act.
incompleteNo discussion of which quality signals resist deterministic proxying altogether. Mutation testing and unit tests can catch correctness regressions but not architectural coherence, elegance, or long-term comprehensibility — the very qualities ('clean', 'thoughtful') the post's own opening paragraph names as markers of good code.
Read next: extract-garg-reducing-friction-ai-development.json (g2: Polanyi's paradox — the most important quality signals may be exactly the ones hardest to articulate as explicit constraints) and the software-design-fundamentals corpus (Ousterhout on deep modules, complexity) for what judgment stays irreducibly human.