Back Pressure (Verification-Bound Autonomy)

The systems-thinking rule that autonomy can only expand as far as verification capacity allows (queueing back-pressure applied to agent autonomy): a loop earns automated status only if its check is cheap, fast, high-frequency, and hard to fake.

Also known as: back pressure, backpressure, back-pressure

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (11)

• #ai #programming #softwareengineering | Addy Osmani | 11 comments Addy Osmani · 2026-10-08 source ↗ Reader 🖥️
  Software engineering has entered a third generation of AI coding tools — autonomous agents taking a spec and running for hours or days — where the engineer's job shifts from writing code to building and operating the 'factory' that orchestrates fleets of agents, and the decisive skill becomes specification clarity and verification rather than code generation.
• Brownfield Agentic Engineering Addy Osmani · 2026-09-14 source ↗ Reader 🖥️
  Agentic engineering in an old (brownfield) codebase succeeds by making hidden, undocumented constraints explicit and the cost of a wrong change cheap and visible — through human-drawn risk zones, durable research artifacts, characterization tests, migrations completed as whole units, and review that scales with blast radius rather than code volume — not by maximizing agent autonomy or parallelism first.
• Own the Outer Loop Addy Osmani · 2026-09-09 source ↗ Reader 🖥️
  Because agents supply capability but cannot inherit consequence, engineers must own the 'outer loop' of agentic systems — the boundary where Quality (checks/evidence), Verdict (the ship/block decision), and Answerability (the guarantee of being able to explain why) live — which means personal, attributable accountability, not code-writing skill, is what becomes scarce and valuable as harnesses, loops, fleets, and software factories absorb the inner work.
• All models, no matter how smart, will eventually build systems... Steve Yegge · 2026-09-02 Reader 🖥️
  Any AI coding model, left unconstrained, will eventually build a system that outgrows its own capacity to understand or maintain it — so the durable fix is not a smarter model but an externally imposed cap on system size.
• Loop Engineering: Building Blocks, Adoption, and Impact Jai Lal Lulla; Vahram Nersesyan; Seyedmoein Mohsenimofidi; Christoph Treude; Sebastian Baltes · 2026-08-28 Reader 🖥️
  "Loop engineering" has a stable, practitioner-agreed definition and set of building blocks (triggers, stop conditions, persisted state, verifiers, budgets, escalation points) for designing systems that repeatedly prompt coding agents instead of a human doing so turn by turn, but an exploratory mining study of 36,710 open-source repositories finds confirmed autonomous agent loops in only 0.59% of them, and shows that while loops' triggering configuration gets committed to version control, almost none of the prescribed runtime building blocks — state files, verifiers, budgets, machine-checkable goal conditions — do, leaving the practice's claimed value almost entirely untested by evidence.
• Human Oversight Is Not a Human in the Loop Gustavo Bataller · 2026-08-27 Reader 🖥️
  Meaningful human oversight of AI systems is not achieved by keeping a person nominally 'in the loop'; it is an institutional capability jointly produced by context, competence, sufficient time and attention, independence, and real, exercisable authority to intervene — and when any one of these conditions is missing, a human's formal presence preserves only the appearance of control, not control itself.
• Grab Cuts Mechanical Analytics Work From 44% to 30% with AI Agents Leela Kumili · 2026-08-17 source ↗ Reader 🖥️
  Grab reduced the mechanical share of its analysts' work by deploying AI agents across a staged autonomy model, an agent-routing system, and continuously maintained certified data context, while deliberately keeping humans accountable for metric definitions, causal interpretation, and final decisions.
• Addy Osmani's Post Addy Osmani · 2026-08-01 source ↗ Reader 🖥️
  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.
• Software Factories, Light and Dark AddyOsmani.com · 2026-07-20 source ↗ Reader 🖥️
  Because verification, not generation, is the real bottleneck of an AI-driven 'software factory,' an engineer's central job is to decide loop by loop how much autonomy each part of the pipeline can earn — full automation ('dark') only where a check is cheap, fast, and hard to fake, human judgment ('lit') everywhere else — with the human's own role relocating from writing code to owning and verifying that outer decision.
• How we Claude Code Claude · 2026-05-22 Reader 🖥️
  As models get more capable and agents are trusted to run longer on more ambiguous tasks, engineers should stop trying to hand-constrain Claude up front and instead let it interview them into a spec, review that spec through richer, denser artifacts (HTML, not long Markdown), and build verification directly into the artifact itself (as an agent-readable DOM contract) so the same checks can run under human, agent, and headless (CI) supervision alike.
• Maintainability sensors for coding agents Birgitta Böckeler · 2026-05-19 source ↗ Reader 🖥️
  Static analysis tools like ESLint, now cheap to customize because AI can write the rules and messages, are an immediately high-value sensor for keeping an AI coding agent's output maintainable — provided their warnings are rewritten as explicit self-correction guidance for the agent rather than left as generic human-facing messages — but this same newfound ease risks producing feedback overload and a false sense of quality assurance.

Propositions touching this concept (5)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitestablishedBack pressure — you can only hand a loop as much autonomy as you can cheaply and reliably verify, 'and not one inch more' — makes verification, not generation, the actual constraint on how fast a software factory can run.
  Software Factories, Light and Dark · p10
• explicitEncoding an agent's work as an explicit graph, rather than a free-running loop, is back pressure made visible as a diagram: it trades some of the agent's freedom for mandatory checkpoints and legible failure points, so a broken run can be traced to the specific node that killed it.
  Software Factories, Light and Dark · p19

2026-08

• explicitdevelopedWell-designed constraints act as back-pressure, letting a system resist bad work before it propagates downstream and becomes someone else's problem.
  Addy Osmani's Post · p6

2026-09

• explicitcorroboratedQuality means deliberately not granting agents as much autonomy as they can technically exercise, but only as much as leaves enough backpressure (via ordinary engineering signals — types, tests, hooks, sandbox limits, audit logs, monitors) to stop, regulate, and check them.
  Own the Outer Loop · p11
• explicitAutomation does not eliminate engineering work; it relocates the bottleneck from 'can we build this' to 'should this exist, can we answer for it,' which itself creates new, real work designing new loops, new evidence, new backpressure mechanisms, and new agents.
  Own the Outer Loop · p22

Open gaps (10)

• illogicalThe piece argues both that free-running loops are dangerously unstructured (motivating the pivot to explicit graphs) and that short, low-stakes loops (the nightly lint-fix cron) legitimately earn full autonomy without any explicit graph structure — it never reconciles when a loop needs graph-discipline versus when it's fine to run as a pure loop; length and stakes are offered as the answer for automation-worthiness, but that criterion is never explicitly connected back to the separate loop-vs-graph argument.
  Software Factories, Light and Dark — read next: Read for a unified framework connecting loop-length/stakes-based autonomy criteria with graph/state-machine architecture choices, rather than treating them as two independent recommendations.
• incompleteThe rule of thumb that 'an agent holds up for three to ten steps, then starts losing the thread past twenty' is stated (attributed to Dex Horthy) without any grounding for why that specific numeric range holds, what model or context window it was measured against, or whether it's expected to shift as context windows and context-management techniques improve — it's treated as a durable constant rather than a fast-moving, model-dependent empirical measurement.
  Software Factories, Light and Dark — read next: Look for benchmark data on agent step-count reliability across model generations and context-management techniques, to see whether this threshold is already stale.
• incompleteAll observations come from a single practitioner working solo on one greenfield rebuild. The article never addresses how self-correction guidance and the threshold-increase mechanism would behave with multiple developers and multiple concurrent agents sharing the same ruleset — e.g. whether inconsistent judgment calls about suppressions/threshold increases across people or agent sessions would recreate the same 'clean house' management-overhead problem she credits agents with solving for a single author.
  Maintainability sensors for coding agents — read next: Team-scale (not single-practitioner) case studies of agent-maintained lint hygiene across many contributors and concurrent agent sessions.
• incompleteSeveral central claims — that HTML specs net-reduce token cost, that Opus 4.7's vision model materially improves screenshot-based feedback, that the verification framework meaningfully improves reliability — are asserted from the presenter's own experience with a single demo repo, without any measurement, benchmark, or before/after comparison.
  How we Claude Code — read next: Compare against the corpus's recurring pattern of unreplicated single-author agentic-workflow anecdotes (e.g. extract-anatomy-of-an-agent-harness's own unquantified 'giving the model a way to verify its own work improves quality 2-3x' claim) for how thin this evidentiary base typically is across the corpus.
• incomplete'Authority' is defined functionally (the system must be obliged to respond) but the essay never distinguishes how that obligation is actually enforced — a technical control (the agent literally cannot proceed without an unblocking signal), a policy/process control, or a cultural/incentive norm. These have very different failure modes, yet 'real authority' is treated as roughly binary rather than as a spectrum of enforcement mechanisms with different robustness.
  Human Oversight Is Not a Human in the Loop — read next: Read alongside back-pressure/verification-bound-autonomy material that treats authority boundaries as engineered, mechanical constraints ('only as much autonomy as you can cheaply and reliably verify') rather than primarily an organizational/cultural property.
• incompleteThe illustrative failure-mode vignettes (specialist without authority, overloaded manager, reviewer seeing only the final answer, someone discouraged from disagreeing) are presented as plausible scenarios rather than drawn from documented incidents. No specific, named case of an AI-oversight failure grounds the argument, which weakens falsifiability — a reader cannot check whether the five-condition taxonomy actually predicts or explains a known real failure.
  Human Oversight Is Not a Human in the Loop — read next: Compare against concrete incident write-ups elsewhere in the corpus (e.g. production-database-deletion incidents where an agent operated without an approval gate, or major automated-decision failures with public postmortems) to test whether Bataller's framework actually accounts for those specific failures.
• incompleteThe mining study measures public open-source adoption only. The paper itself notes that 'high-volume internal deployments... leave no public trace,' but the headline anecdotes it discusses (Stripe's Minions, 1,300 PRs/week) are exactly such internal deployments. The 0.59% figure is therefore a floor on publicly-visible evidence, not a measure of practice overall, and the paper cannot adjudicate whether loop engineering is genuinely rare or merely rare in public repositories.
  Loop Engineering: Building Blocks, Adoption, and Impact — read next: An internal-tooling survey or structured practitioner-interview study of enterprise/internal loop adoption (the kind this corpus's Stripe and 'software factory' pieces gesture toward) to estimate private adoption rates that public GitHub mining cannot reach.
• incompleteThe claim that traditional SWE skills 'shift up the stack' into spec-writing and verification is asserted without any worked example of what a verification-bound, back-pressure-style allocation rule (deciding which parts of the factory can safely run unverified) actually looks like in practice.
  #ai #programming #softwareengineering | Addy Osmani | 11 comments — read next: extract-addy-osmani-software-factories-light-dark, the author's own later, fuller treatment, which supplies the concrete 'back pressure' rule and the lit/dark factory distinction this post only gestures at.
• incompleteThe essay proposes an 'accountability contract' (checklist understood, evidence, who's accountable, system status) but never specifies how any of these fields get populated from an actual hour-scale agentic run whose intermediate decisions are, by the essay's own admission, not fully recorded and cannot all be traced back to input tokens — leaving the central operational question (how do you produce the evidence you're claiming to own) unanswered.
  Own the Outer Loop — read next: Read Osmani's own 'Quality in the Harness' and 'Software Factories, Light and Dark' for the concrete evidence artifacts (tests, static analysis, review gates) he specifies elsewhere, and read agent-governance / decision-provenance literature for concrete audit-trail mechanisms.
• illogicalThe closing operating model instructs 'put all quality assurances and verification inside the loop' and separately 'put humans in their rightful place, on the right decisions' as if these were sequential, non-competing instructions — but the essay's own earlier claim that 'the agent can ship more than you can review' implies verification-inside-the-loop and human decision-capacity are in tension precisely as loop throughput scales, and the essay never reconciles how 'put verification inside the loop' avoids collapsing into exactly the 'dark factory' pattern its companion piece warns against.
  Own the Outer Loop — read next: Reread the dark/lit factory framework in 'Software Factories, Light and Dark,' which draws this line explicitly and carefully, for how much more precise that essay is on this exact point than this one.