The Amplifier · frzip

§1

The meeting

I've been in this meeting. Big effort, many teams, a big number on the screen. Someone asks: “Did you factor agentic coding into this? The teams have AI tools now. Shouldn't this be faster?”

Fair question. Wrong question. And the difference is worth getting precise about, because the answer is not “AI doesn't help.” AI helps a lot. It helps one specific stage of delivery, and whether the estimate moves depends on whether that stage is the one setting the date.

The short version, so it isn't buried: low-context production can raise review demand faster than it raises accepted output. That's the whole claim, and it's conditional. When an effort's constraint is the verification queue, the few people who can judge whether work matches intent, the queue sets the date and production speed stops mattering. Agentic tooling fills the queue faster. It does not drain it faster. On efforts like this one I'll argue the queue usually is the constraint; the telemetry leans that way without proving it. The rest of this page is that argument with the arithmetic done.

§2

What kind of tool is this?

My first instinct was a tool analogy. It's a drill: master woodworker, amateur, same drill, different furniture. True, but it undersells something. A drill adds capability. This thing multiplies.

Better: it's an amplifier. Feed a guitar amp a clean signal and you get a bigger clean signal. Feed it noise and you get louder noise. Output scales with input.

The input isn't typing speed. It isn't even raw skill. On well-scoped, self-contained tasks the research says AI is a leveler. The biggest measured gains go to the least experienced people and the performance distribution compresses. Call centers: about 15% on average, the newest agents up around 34%, veterans roughly flat. 1 1Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at work. The Quarterly Journal of Economics, 140(2), 889–942; n = 5,179 support agents. The writing result: Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192. The coding task: Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv:2302.06590. Construct caveats in the rigor layer. Professional writing tasks: same shape. A greenfield coding task: less-experienced developers gained the most.

So if AI levels the field, why doesn't handing agentic tools to nine teams flatten my estimate?

Because the signal being amplified isn't skill. It's held intent. How much of the actual vision, the product context, the business constraints, the way this thing has to live inside the enterprise, is in the head of the person driving the tool. Plus the judgment to evaluate what comes back. On a self-contained task none of that matters, so AI closes the gap between novice and veteran. On intent-dense work inside a real system, it's nearly the only thing that matters. The most sobering study we have took experienced maintainers, gave them AI tools, and put them on their own mature codebases. The highest held-context scenario anyone has measured. Early-2025 tooling made them 19% slower. 2 2Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR; arXiv:2507.09089. A randomized trial, 16 maintainers, 246 tasks on their own repos. Small sample, early-2025 tooling; the table in §6 carries the caveats and METR's 2026 follow-up.

One big caveat on that number, and it cuts in AI's favor: the tooling was early 2025, which is ancient history in this field. The recency argument lives in the rigor layer; the short of it is that the multiplier is probably higher today than any published study shows, and whatever it is, it still applies to production, not to coordination or verification.

The amplifier is real. The question is what it amplifies, and what turns amplified output into shipped value.

§3

Where the time actually goes

Delivery has four stages, for every person or team involved:

Produce. Write the code, the docs, the artifacts. AI multiplies this stage. Call the multiplier m_P.
Align. Is what got produced what was meant? Two things decide this: how intent-sensitive the work is (a config migration barely cares, a platform redesign cares completely), and how much of the intent this producer actually holds (the architect nearly all of it, a team three handoffs from the vision maybe half). A low-context team on intent-sensitive work produces polished, plausible, wrong artifacts. Now at amplified speed.
Coordinate. Every dependency between teams burns real hours: re-encoding intent, handoffs, alignment meetings, integration surprises. How many of those dependency edges exist is a property of the work, its coupling; cross-team edges cost more than in-team ones, and the hours come out of the same people who produce and verify. Disproportionately the ones who hold the vision.
Verify. Someone with enough context has to judge whether the work matches the intent. This stage has its own multiplier, m_V. Today m_V is nowhere near m_P.

Why doesn't AI multiply verification the way it multiplies production? The mechanical parts, it does: tests, lint, static analysis, “does it compile.” That's why m_V is a knob in the model and not a constant. But the part that gates delivery is judging work against intent, and much of the intent is tacit. Naur called programming theory building: the theory lives in the people, and it doesn't survive being written down whole. Some of it serializes fine, into specs and acceptance tests and decision records. The rest goes into a prompt no better than it goes into a spec, and for the same reason. Whatever fraction of the vision survives the writing-down is the fraction the machine can check. The rest is the reviewer's job, at the reviewer's speed. Hold that thought for §4.

That concession invites the obvious attack: serialize enough of the intent and m_V catches up. So here is the claim that carries the result, stated so it can be shot at. Review hours don't spread evenly across the intent. They concentrate in the part that didn't serialize, because serialized intent fails loudly (a red acceptance test) while tacit intent fails plausibly (work that passes every written check and is still subtly not the thing), and plausible failures are the expensive kind: you have to notice one, diagnose why it's wrong, and re-review the fix. Serialize 70% of the vision and you have not cut review time 70%. You've automated the cheap checks and left the reviewer the expensive ones. If specs and acceptance tests ever drain review hours roughly in proportion to their coverage, this claim is false and the argument here folds; that's on the falsifiability list below.

Delivery is aligned production, capped by review capacity. In symbols, D = G · min(1, V/B): G is what got produced and would be accepted, B is the review hours that work demands, V is the review hours that exist. Full derivation below.

That gap between m_P and m_V is the whole story. Crank production without cranking verification and you don't ship faster. You grow a review queue. Telemetry across 10,000 developers found high-AI-adoption teams merged 98% more PRs while PR review time rose 91%, and org-level delivery metrics didn't move. 3 3Faros AI. (2025, July). The AI productivity paradox: AI engineering impact report. Telemetry from 1,255 teams and over 10,000 developers. Vendor data, correlational, not causal. DORA's 2024 report found AI adoption associated with worse delivery stability while three quarters of developers reported feeling more productive. They weren't wrong about the feeling. The queue ate it. DORA now has a name for this: the verification tax. 4 4DORA. (2024). Accelerate state of DevOps report. Google Cloud. DORA. (2025). State of AI-assisted software development report. Google Cloud; this one names the verification tax. The 2024 throughput finding partially reversed in 2025, the stability finding held both years.

§4

“So write better specs and cascade them down”

The standard rebuttal: architects write L1/L2 specs, teams write L3/L4 against them, implementations get reviewed upward at every level.

Run it through the model. Spec-writing converts your highest-context hours from production into serialization. Each handoff decays f, because a spec is lossy compression of intent. That's not a critique of anyone's writing. It's why we stopped doing waterfall. Review-at-every-level multiplies verification demand (four layers of artifacts now need intent-conformance checks) while capacity barely moves, because the reviewing falls on the same few people whose hours just went into specs. The coordination tax didn't go away. You financed it.

And when review saturates, the model gets specific. Under a shared review queue, adding an amplified low-context producer lowers delivered throughput whenever its review efficiency falls below the team's average. The AI multiplier cancels out of that condition entirely. In this model, amplification never decides whether a node helps or hurts. It only scales the consequence. (Fine print: this assumes reviewers can't freely triage. With perfect triage the damage routes through interruption and coordination instead. Full condition in the rigor layer.)

§5

What to actually do

Sort the portfolio by two properties: how separable the work is, and how intent-sensitive it is. They usually travel together, but not always, and the exceptions are why the model carries two parameters instead of one. Several teams each rebuilding their own domain's pricing logic against a shared product vision: intent-dense but cleanly separable. That work fails through the review queue, not through meetings. A dependency upgrade across forty tightly coupled services is the mirror image: barely any intent to lose, but the coordination hours are the estimate. Different failure modes, different fixes.

Separable, well-specified work: fan out. Give every team agentic tools. The leveling effect is real here, and “factor AI into the estimate” is a legitimate ask. I'll concede this one loudly.

Entangled, intent-dense work: put a small pod of vision-holders on it. The people with product, business, systems, and enterprise context in their heads, amplified. And to be fair to the model, run the pod through it too, because pods don't get an exemption. Pod members aren't interchangeable: the product person holds product intent, the systems person systems intent, so the pod has internal handoffs and nobody holds the whole vision alone. The claim isn't that its costs are zero. It's that both numbers are much better: the coupling stays inside one team, where edges are cheap, and each member holds most of the intent their own reviews need, so the queue stays short. The pod wins on the same arithmetic as everything else. And notice what AI does to this option: multiplying each vision-holder's output raises the ceiling on what a small pod can deliver before it has to fan out. AI didn't weaken the case for the pod. It handed the pod its best argument yet.

One cost the model can't see, because it's static: held context grows by doing the work. That is how every vision-holder became one. A standing pod concentrates context in the people who already have it, which is optimal this quarter and corrosive over years; the low-context teams never climb, and you end up with the same bottleneck, older. If the pod becomes a permanent org design rather than a delivery tactic, rotate people through it, and treat a seat in it as how context gets grown, not just spent.

How do you know your effort is the queue-bound kind? The model's gauge is review demand over review capacity, and its proxies sit in telemetry you already collect. Is time-to-first-review trending up while merge counts climb? Are the same few reviewers pinned at capacity while producer output grows? Are changes bouncing back from first review more often than they used to? Two of those moving together and you're queue-bound, and production tooling won't move the estimate. All three flat, and “factor AI into the estimate” is a fair ask.

The line for the meeting: AI multiplies production. This estimate is dominated by coordination and verification, and there's no multiplier on those yet. If you want the number to drop, reduce the handoffs. Don't ask me to turn up the amp.

§6

Rigor layer

The prose above is the argument. This is the arithmetic underneath it, for anyone who wants to check the work.

The napkin version

Collapse everything to one producer pool and one reviewer pool. P is production hours, V is review hours, p is the fraction of output that matches intent, q is the review hours each unit costs:

D = min( p·m_P·P ,  (p/q)·m_V·V )
       what gets built   what gets accepted

Left argument: the amplifier. Right argument: the queue. Delivery is whichever is smaller. Once review is the bottleneck, D = (p/q)·m_V·V, and m_P doesn't appear in the expression at all. Everything below is commentary on the terms: coordination shrinks P and V off the top, fan-out lowers p, misalignment raises q.

For the meeting itself, the Amdahl form. If production is fraction s of the schedule and AI multiplies only that:

speedup = 1 / ( (1 − s) + s/m_P )

Say production is 30% of a cross-org estimate and the tools are a genuine 2×. Total speedup ≈ 1.18×, which shortens the schedule about 15%. Not 50%. Honest limitation: this treats verification as fixed-duration rather than a queue, so it understates the problem when the queue actually backs up. The min() form above covers that case.

The model, fully stated

The full version is a per-person accounting. Each person's week splits into production, review, and coordination hours, with cross-team dependency edges costing more than in-team ones. Production scales with m_P, review capacity with m_V. Notation for the quantities the prose named in words: ρ is the work's intent-sensitivity, f the fraction of intent the producer holds, β the coupling density (dependency edges per node). Two relations do the rest of the work:

p = 1 − ρ·(1 − f)      how much output matches intent
q = τ₀ + τ₁·(1 − p)     reviewer-hours per unit (misaligned costs more)

Sum aligned production G, review demand B, and review capacity V over everyone, and delivery is the napkin formula again: D = G·min(1, V/B), with u = B/V as the backlog gauge. D is a steady-state index. It names no dates.

A word on τ₁, because it looks like the assumption doing the work, and I'd attack it too. It isn't what carries the result. Under saturated shared-queue review, set τ₁ = 0 and the harm condition degenerates to p_k below the incumbents' weighted-average acceptance: a below-average-alignment producer still lowers throughput on constant per-unit review cost alone, because it dilutes the queue. All τ₁ > 0 does is move the threshold toward the intuition that misaligned work costs extra review: you have to diagnose why it's wrong, not just that it's wrong, then re-review the fix. Somewhere in the 2–5× first-pass range is plausible for that. Scenario knob, labeled as one; the qualitative result doesn't depend on it.

The marginal-node condition

Add a producer node k under saturated, shared-queue review (B ≥ V), holding verification capacity fixed, all else equal. Then D falls ⇔ p_k/q_k < G/B, meaning the node's review efficiency sits below the incumbent average. m_P cancels out of that condition entirely: amplification scales the consequence, it never determines the sign. The cancellation is a theorem of an assumption, stated here as one: p_k doesn't depend on m_P. If amplification changes alignment quality, in either direction, the multiplier and the sign are no longer independent. (With slack in the queue, nothing falls until the slack is consumed; the threshold then shifts by the slack per unit of the node's output.)

“Holding verification capacity fixed” deserves a defense, because a new team brings its own reviewers and the phrase can read like the conclusion smuggled in as an assumption. The capacity a new node adds is real but low-efficiency for the review that gates delivery: its reviewers can check correctness, not conformance to an intent they don't hold. That's not a separate assumption; it's the same fact that makes p_k low. Credit the node's reviewers to V at their intent-conformance efficiency and the threshold moves, but the sign doesn't flip unless they hold context the scenario says they don't.

This holds under shared-queue (FIFO or proportional) review. With free reviewer triage, a low-efficiency node harms only via unavoidable costs: triage time, coordination edges, interruption. It is never a “negative-sum theorem.”

Narrowest honest version of the claim: in intent-sensitive regimes, low-context production can increase review demand faster than accepted output; when review is saturated, that lowers realized throughput.

What the evidence shows, honestly

Source	What it actually shows
Compression studies (Brynjolfsson, Noy & Zhang, Peng, Dell’Acqua)	Measure tenure or task proficiency on self-contained tasks, a different construct from vision-holding, at a different level.
METR 2025	Sixteen developers, so a small sample. The nearest proxy for a vision-holder (repo maintainers on their own code), still not the full archetype (no product, business, or enterprise dimension). The tooling snapshot is early 2025: before the strong agentic workflows and the late-2025 model generation (Opus 4.5, GPT 5.6, the Claude 5 family), and the tools shifted hard that November and December. METR's February 2026 follow-up (ten of the original developers plus new recruits, 800-plus tasks) softened the number: roughly −18% for the returning subset, about −4% for the new cohort, both with intervals that cross zero, and METR reported the design was compromised enough by selection effects that they're rebuilding the experiment. Read the 2025 result as evidence about what held-context work demands, not as a ceiling on current tooling. METR labels the scope this way themselves.
Faros 2025, GitClear	Vendor telemetry. Correlational, not causal.
DORA 2024 / DORA 2025	2024's throughput finding partially reversed in 2025; the stability finding held both years.
Boehm's defect-cost escalation, often repurposed as a handoff argument	Directional at best; see Bossavit's critique.

And plainly: no study has measured intent proximity directly. This model makes it an explicit variable instead of borrowing tenure as a proxy. That's a modeling choice, and it's disclosed as one.

What this model is not

Not an estimator. No calendar dates. Parameters are scenario choices with honest ranges. It's a mental model with the arithmetic done, so the argument can happen precisely instead of by anecdote.

It should still be falsifiable, so here is what would count against it: teams far from the vision clearing intent-dense review as cheaply as the vision-holders do; delivered throughput rising in step with production tooling while review capacity stands still; or review hours falling roughly in proportion to spec and acceptance-test coverage, which would mean the tacit residual doesn't dominate review time after all. Show me any of those in the data and the model is wrong.

Prior art

Brooks (partitionability, the n(n−1)/2 intuition), Amdahl (speed up one stage and watch another become the limit; an analogy, not an identity), Goldratt (crank a non-bottleneck and you grow inventory, not throughput), Naur (the program is a theory held by people, and the theory doesn't survive documentation), queueing theory via Little and Reinertsen (real queues degrade nonlinearly as utilization nears 1, which makes the min() form conservative), Conway, Parnas (why good decomposition creates the fan-out case), Cataldo & Herbsleb (coordination should match dependencies; coordination is not waste), Team Topologies (cognitive-load-sized teams, minimal handoffs).