Code Got Cheap. Your Attention Didn’t.

Andrej Karpathy hasn’t written a line of code by hand since December 2025. His workflow flipped from 80% manual coding to 80% agent-driven, with the remaining 20% spent on oversight. “I’m still the bottleneck,” he said — not because the agents are slow, but because he can only review so fast.

That one sentence contains the entire economics of the agent era: code generation is approaching zero marginal cost, but human attention remains fixed. The binding constraint on your agent fleet isn’t compute, API spend, or model capability. It’s the operator sitting between generated output and production, deciding what to trust.

And most teams are treating that constraint like it doesn’t exist.

The Numbers That Should Scare You

Faros AI analyzed 22,000 developers across 4,000 teams in March 2026. The data is sobering:

• Code churn up 861%. Agents rewrite code that was just written — often their own.
• Incidents-to-PR ratio up 242.7%. More code, more bugs, proportionally more bugs.
• PRs merged with zero review: 31.3%. Almost a third of changes ship with nobody looking.
• Per-developer defect rate: 9% to 54%. Six times more bugs per person.
• Median review duration up 441.5%. Reviews take 4.4x longer when agents write the code.

Read Addy Osmani’s full analysis on agentic code review ->

Meanwhile, a study of 25,264 agentic pull requests found that 42.27% of projects had participation ratios below 5%. The overwhelming majority of agent-authored PRs are overseen by a single human. One person, standing between an arbitrarily large output stream and production.

The community is feeling the pain. On Hacker News, developers are building tools specifically to triage which agent PRs deserve human eyes and which can ship:

View discussion on Hacker News ->

The numbers tell a consistent story: individual throughput is up, team delivery is flat or worse, and the review queue is where velocity goes to die. A Harvard study confirmed the pattern — agents increased code volume by 30% without a matching gain in resolved issues. Review times jumped 49%. Revision requests nearly doubled.

The Attention Economy of Agent Fleets

Here’s what nobody is saying clearly enough: you need an attention budget, not just an API budget.

Addy Osmani, formerly of Google Chrome and now author of the most-cited practitioner writing on agent management, frames it this way: the bottleneck has shifted from “can this agent write code” to “should we build this” and “can I manage multiple agents doing so effectively.” His operating setup: 4-5 background agents on bounded tasks (tests, docs, dependency bumps) plus 3-5 local sessions for architecture and product work. Boris Cherny, Claude Code’s creator, reportedly runs 5 local plus 5-10 browser sessions. Greg Isenberg described running 5-10 concurrent cloud sessions producing 22-25 PRs per day.

Read the full piece: Your AI coding agents need a manager ->

But there’s a catch. Anthropic’s 2026 Agentic Coding Trends Report found that developers fully delegate only 0-20% of tasks to agents while actively supervising 80-100% of what they delegate. If you’re running 10 agents but supervising 80% of their output, you haven’t saved attention — you’ve multiplied the demand on it.

The uncomfortable math: attention doesn’t scale linearly with agent count. Each additional agent doesn’t add a fixed oversight cost. It adds a variable cost that depends on the trust level you’ve established, the reversibility of the change, and the blast radius if something goes wrong. Most teams ignore this entirely and discover it when the incident count spikes.

Practitioners are already asking this question in the open. One Ask HN thread captures the tension directly — how do you harden AI-generated changes to a million-line legacy SaaS before review?

View discussion on Hacker News ->

The Three Attention Allocation Patterns That Work

After reviewing every practitioner framework published this year — from Osmani’s operating loop to Somasundaram Sekar’s five-layer review model to Semgrep’s risk classification — three patterns emerge that actually survive contact with production.

Read the full article on Substack ->

Pattern 1: Trust Tiers (Not Uniform Review)

Stop reviewing everything the same way. Classify your agent output into tiers:

Tier 0 — Auto-merge. Formatting, dependency bumps, documentation fixes, test additions that pass CI. These are reversible, low-blast-radius changes. Set up automated gates (lint, typecheck, SAST, test suite) and let them ship. Semgrep’s data shows this class covers roughly 40% of agent output.

Tier 1 — Batch review. Feature additions in well-tested areas, refactors with high test coverage, infrastructure changes with rollback plans. Review these in blocks — not one at a time as they arrive, but in a daily 30-minute review session. A reviewer can meaningfully assess roughly 200-400 lines per hour. Batch them into digestible chunks.

Tier 2 — Deep review. Auth changes, payment flows, data migrations, API contracts, anything touching shared interfaces. These get the full human review: intent verification, structural analysis, edge-case probing, and the knowledge-transfer check (“can the author explain the agent’s approach?”). If they can’t, the code doesn’t merge.

Tier 3 — Human-only zones. Architecture decisions, security-sensitive design, product strategy expressed in code. No agent touches these without a human co-piloting from the start. Osmani calls this the “own” category — work you keep, not delegate.

Read Semgrep’s take on risk-based code review ->

Pattern 2: The Review Sandwich

This is the pattern emerging from Osmani’s agentic code review framework, refined through GitHub’s internal data: AI first pass, human middle, author verification.

1. AI pre-screen: Run 2+ different AI review tools (their blind spots don’t overlap). This catches surface issues — style, known anti-patterns, obvious bugs — and generates a risk score for triage.
2. Human judgment layer: Humans review intent (does this match the ticket?), risk tier (what breaks if this is wrong?), and structure (are the abstractions right?). This is the irreducible human work.
3. Author verification: Before merge, the human who requested the change must explain the agent’s approach. If they can’t articulate why the code works this way, it doesn’t ship.

GitHub reports this pattern reduced human review time by 30-50% internally — not by removing human attention, but by focusing it on the decisions only humans can make.

Pattern 3: WIP Limits for Agent Streams

This one comes straight from manufacturing theory, and it’s the most underused pattern in agent fleet management.

Cap the number of active agent streams to your review capacity, not your compute capacity. If you can meaningfully review 4-5 PRs per session, don’t run 15 agents producing 25 PRs. You’ll spend the day context-switching between review queues instead of actually reviewing.

Osmani recommends explicit WIP limits:

• Define kill criteria before starting a feature (what counts as “stop and ask”)
• Set time limits (“stop and report blockers after 15 minutes without progress”)
• Cap the number of concurrent agent PRs waiting for review at a number your team can clear in a day
• Use git worktrees to isolate agent work — one agent per PR, no merge conflicts

Read Wavect’s analysis on focus as the bottleneck ->

The Wavect analysis argues there’s no evidence-based universal ceiling on agents per operator, but recommends measuring accepted outcomes rather than activity, and reducing concurrency when review queues grow. The right number of agents isn’t “as many as possible” — it’s “as many as you can verify.”

Measuring Oversight Cost

You can’t budget what you don’t measure. Here are the metrics that matter for attention allocation:

Ready-to-accepted time. How long between an agent finishing a PR and a human accepting it? If this grows faster than your agent count, your attention budget is overdrawn.

Review queue age. If PRs wait more than 2 days for first response, you have a capacity problem, not a velocity problem. Target 4-hour first response, 24-hour resolution.

First-pass acceptance rate. What percentage of agent PRs merge without revision requests? If it’s below 60%, your agents need better briefs — the problem is upstream, not in review.

Cost per accepted outcome. Track API spend + compute + human review hours per merged, incident-free change. Not per PR, not per line of code — per outcome that worked. This is the number that tells you whether your fleet is actually productive or just busy.

Oversight-to-output ratio. What percentage of your engineering hours go to reviewing agent output vs. doing work agents can’t? If review consumes more than 40% of senior engineer time, you’re spending your scarcest resource on verification instead of judgment. That’s a staffing problem, not a tooling problem.

The Community Is Split

The developer community hasn’t converged on a single answer. HN threads show a spectrum from “just review the agent’s approach, not every line” to “I still read every diff”:

View discussion on Hacker News ->

And the broader question of how to use LLMs effectively in established codebases — where the stakes and blast radius are highest — continues to generate heated debate:

View discussion on Hacker News ->

The Skill Atrophy Problem Nobody Wants to Talk About

There’s a darker side to the attention allocation question. A position paper from Dhanorkar et al. (2026) interviewed 17 professional developers and found early signs that supervising agents erodes hands-on programming skill. One participant said they had shipped Go code they didn’t know how to write a month earlier.

This creates a vicious cycle: as developers spend more time reviewing and less time writing, their ability to catch subtle bugs in agent-generated code degrades. The reviewer atrophies into an approver.

The fix isn’t to avoid delegation. It’s to keep humans writing code in high-judgment areas (Tier 3) while delegating bounded tasks (Tier 0-1). The Pragmatic Engineer’s conversation with Osmani frames this as “mutual amplification” — using agents to handle volume while keeping humans sharp on the work that matters.

What This Means for You

If you’re running an agent fleet today — or planning to — here’s the playbook:

1. Audit your current oversight spend. How many hours per week do your senior engineers spend reviewing agent output? If you don’t know, start measuring. The number will surprise you.

2. Implement trust tiers. Not every change deserves the same attention. Auto-merge formatting and test additions. Batch-review feature work. Deep-review anything touching auth, payments, or shared interfaces. Keep architecture human-only.

3. Set WIP limits based on review capacity, not compute capacity. If your team can review 15 PRs per day, don’t let agents produce 40. The excess just rots in the queue and creates merge conflicts.

4. Front-load intent. Write delegation briefs. Define acceptance criteria before the agent starts. Two of four oversight forms happen before any code is written — invest there.

5. Measure outcomes, not output. Lines of code and PR count are vanity metrics. Track cost per accepted, incident-free change. That’s your real productivity number.

6. Protect review capacity like you protect compute. When you cut headcount because agents made coding faster, you’re cutting the one resource that doesn’t scale with AI: human judgment under load.

The teams that figure out attention allocation will ship 10x more than the teams that just add more agents. The constraint was never code. It was always the human in the loop — and now we need to treat that human’s attention like the scarce, expensive, non-renewable resource it is.

---

For the verification side of this problem — how to build trust gates that actually work — see Lean Is Becoming AI’s Trust Layer. For fleet orchestration patterns, see The Agent-of-Agents Problem. For why the model isn’t the bottleneck, see Your AI Agent’s Bottleneck Isn’t the Model. And for the PR-volume data that kicked off this entire conversation, see 10x PRs, 1x Reviewers.