#ai #programming #softwareengineering | Addy Osmani | 11 comments

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

Back Pressure (Verification-Bound Autonomy)Human as Orchestrator of Agents Orchestration Tax / Human Review Bottleneck Software Factory Verifiability (as the Quality Bar)

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.

practical · argumentative — A LinkedIn post promoting and summarizing Osmani's own longer article; argues for a specific mental model ('the factory') and draws out a few concrete practical takeaways from it.

Structure

Part	Role
Framing: AI coding tools have progressed through three generations — autocomplete, synchronous prompt-by-prompt agents, autonomous long-running agents	context
The factory mental model: you're no longer a coder but someone building the factory that builds software, managing fleets of agents in parallel	evidence
Claim that traditional SWE skills aren't deprecated, just relocated to specification, abstraction design, TDD discipline, and verification	evidence
Three takeaways: spec as leverage, verification as the new bottleneck, tests as mandatory safety system	evidence
Personal anecdote: 25+ years coding, now spending more time orchestrating and prompting than reviewing line-by-line, except where problems are subtle	evidence

Key terms

The factory model
A mental model for AI-era software work in which the engineer's job is to design and operate a system that runs many parallel, autonomous coding agents, rather than to personally write the code those agents produce.
Synchronous agents
The second generation of AI coding tools: agents that collaborate with the developer prompt-by-prompt, requiring the human present and responding turn by turn (contrasted with earlier pure autocomplete and later autonomous, long-running agents).

Propositions

explicitAI coding tools have progressed through three distinct generations: accelerated autocomplete, synchronous prompt-by-prompt agents, and autonomous agents that take a spec and run independently for hours or days.conf: high
explicitThe history of software engineering is a history of raising the level of abstraction (bits to assembly, C to managed languages), and the shift from writing code to orchestrating fleets of agents is the next step in that same lineage.conf: high
explicitWhen an engineer orchestrates a fleet of autonomous agents instead of writing code directly, the engineer's actual job becomes building and operating 'the factory' — the system that manages parallel agents handling implementation.conf: high
explicitTraditional software engineering skills have not been made obsolete by agentic coding tools; they have relocated upward, into specification clarity, abstraction design, TDD discipline, and the ability to verify rather than merely generate.conf: high
supportsSoftware Factories, Light and Dark · p21 — The post's claim that SWE skill relocates to spec/verification is the same redefinition Osmani later develops explicitly as 'expertise redefined away from code-writing and toward judgment about verification design.'
explicitA specification is the leverage point of agent-orchestrated work: when orchestrating dozens of agents, vague thinking in the spec multiplies into chaos, so the spec functions as product thinking made explicit rather than just a prompt.conf: high
supportsSoftware Factories, Light and Dark · p13 — Both identify the specification/upfront design step as the real leverage point — cheaper to get right than reviewing the large diff it eventually produces.
explicitGeneration is largely a solved problem for many classes of coding task; the unsolved problem, and the new bottleneck, is knowing with confidence that autonomously-generated output is actually correct.conf: high
supportsSoftware Factories, Light and Dark · p10 — This post's 'generation is solved, verification is the new bottleneck' claim is the seed of Osmani's later, fully worked-out 'back pressure' rule (autonomy only as far as cheap, reliable verification allows).
explicitIn an agentic workflow, test-driven development stops being optional ceremony and becomes the mandatory safety system that prevents the factory from stalling or shipping incorrect output.conf: high
explicitAfter 25+ years coding, the author personally now spends more time orchestrating and prompting multiple agents than reviewing their output line-by-line, reserving manual coding for subtle problems or cases where agents get it wrong.conf: high
extendsThe Orchestration Tax is You · p6 — The personal anecdote (prompting and orchestrating more than reviewing line-by-line) is a concrete first-person instance of the structural 'orchestration tax' gap the later piece formalizes between agent production capacity and what one developer can actually merge.
explicitProgramming as primarily a keystroke activity will increasingly be reserved for the most nuanced, complex problems, while programming as thinking, systems design, and orchestration becomes the dominant mode of the work.conf: high

Arguments

Engineers should adopt 'building and operating a factory' as their working mental model for AI-assisted development, rather than 'writing code with AI help.' strength: medium

Explicit premises:

AI coding tools have progressed to a third generation capable of autonomous, hours-to-days-long execution from a spec
The abstraction-raising historical arc of software engineering (bits to assembly, C to managed languages) makes each such jump in agent autonomy the natural next rung

Implicit premises:

The three-generation taxonomy (autocomplete -> synchronous agents -> autonomous agents) is a clean, discrete progression rather than a continuum with much overlap and regression (teams still mix all three modes depending on task)
A metaphor that fits the author's own current workflow (spinning up parallel agents, prompting more than reviewing) generalizes to engineers working in different contexts — e.g. regulated, brownfield, or small-team settings where parallel fleets of autonomous agents may not be feasible or desirable

Inferences:

If the factory model holds generally, hiring, tooling, and skill development should reorganize around specification and verification skill rather than code-writing speed

Narratives

The author's own 25-year coding career, now shifted to orchestrating and prompting multiple agents rather than reviewing code line-by-line, except where problems are subtle or agents get something wrong.
→ Functions as lived, first-person evidence for the claim that keystroke-level programming is being reserved for edge cases while orchestration becomes the default — grounding an abstract 'factory model' claim in the author's own practice rather than theory alone.

Questions addressed

✅ If AI agents can now generate most code autonomously, what is left for the human software engineer to do?
Build and operate the 'factory': write clear specifications, design strong abstractions, keep TDD discipline, and verify output — none of which disappears, all of which relocates upward.

Gaps

incompleteThe post asserts 'verification is the new bottleneck' and 'tests are mandatory' but gives no account of how verification itself scales when dozens of parallel agents are producing output faster than any one developer's judgement throughput can review — the exact structural constraint the corpus's own orchestration-tax analysis names (one developer, non-parallelizable judgement, Amdahl's-Law-bound throughput).
Read next: extract-osmani-orchestration-tax-is-you, which works out in detail why spawning more agents does not create more reviewing capacity, and what to do about it (batch reviews, cap parallelism to what you can actually review).
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.
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.