Attention goes to the back of the queue: in LinearB's 8.1 million pull requests, AI-assisted pull requests waited about five times longer than human-written ones for a first look, then reviewed faster

Key takeaways

In LinearB's data on 8.1 million pull requests, AI-assisted ones waited about five times longer than human-written ones for a first look, then were reviewed faster. LinearB sells tools for improving the code-review process. In mid-August, three posts looked like the discovery of a new step in the work: Anthropic's chief product officer said four sentences now do the job where at the start of the year a whole scaffold had to be built first, one senior developer's agents run all night while the developer steps in twice a day to review, and that developer's startup made its signature feature a single glance across every working window to find the one that needs a person. The inference followed. What held people up was no longer how to brief the agent but which output to look at first. At the time, SecondSource logged the claim as an observation and did not adopt it. Two speakers with a stake had written three posts and measured nothing. The number that mattered most, how much of a night's output is usable the next morning, did not exist.

That number now exists. With it, the August hypothesis holds: attention, not briefing the agent, is where people get held up. But SecondSource's hypothesis tracked the wrong thing. The number to watch is how long each finished piece of output waits for a human, not how many agent windows are open at once. A second August claim is false. That claim said model companies could not build the live view for supervising agents, and OpenAI and Anthropic had both already shipped one. The piece first defines attention routing. Attention routing is the new step between handing work to agents and checking the result. It is the step of deciding which finished job a person should look at first. Next, the piece tests that step against three independent large-sample measurements. They show how many people run agents in parallel, how much output is usable the next day, and where human attention goes. It then splits the waiting in two, which is the core finding. It ends on timing: the model companies entered this layer months ago, by a different road.

Beyond the daily brief's item on the same subject, the piece adds three concrete points. First, waiting to be looked at and being looked at are now two separate numbers. In a dataset of 8.1 million pull requests (the unit in which an engineer submits a set of code changes for review before they merge into the main codebase), AI-assisted pull requests waited about 1,050 minutes on average before anyone started reading them; human-written ones waited about 200. Once someone started, the AI-assisted request took 194 minutes on average to finish review; the human-written one took 252. In LinearB's data, the wait before a first look was more than five times as long as the review itself. The claim that attention is the upfront cost of verification now has a measured price. Attention here means the time output waits before anyone starts checking it. Second, the obvious rebuttal, that AI-assisted pull requests are simply bigger, was run against this reading, and the reading did not fully survive it. AI-assisted pull requests are indeed 2.6 times larger, and large changes always wait longer, so the data does not separate how much of the fivefold gap is attention and how much is size. This piece cannot separate it either. That hole is in the body, not in a footnote. Third, the line that model companies cannot eat this layer was already false the day it was written. OpenAI's own launch announcement pitched the desktop Codex app as a command center for agents on February 2. In Anthropic's Claude Code changelog, the view that counts how many background agents are waiting for input has not only shipped, it has already had a status-display bug fixed. A bug to fix means the feature has been in users' hands long enough to break.

First, the step itself: what attention routing is

The term needs explaining because it names nothing that already exists.

How the problem grew. The traditional relationship between a person and software is synchronous: a command goes in, a result comes back, the person is present. In that form there is no question of what to look at first, because there is only one thing and the person is already looking at it. Once an agent can run for eight hours while the person sleeps, two things change at once. The output arrives at a time decoupled from the person's waking hours, and more than one delegated job is running at the same time. Between deciding whether to delegate and verifying whether the result is right, a step that did not exist before appears: in one limited sitting, pick out which job needs the person.

Why it is a separate step rather than part of verification. The cost structures differ completely. Verification cost tracks task difficulty: hard things take longer to check. The cost of finding which one to look at tracks the number of jobs running at once, regardless of how hard each one is. The two also fail in different places. A verification failure is looking and getting it wrong, approving what should not pass. A routing failure is not looking at all: the output sits and waits, or gets skipped. That distinction is the foundation for every judgment below.

Where the boundary sits. The step exists only when two or more jobs are delegated and their outputs are asynchronous. One agent at a time, watched while it runs, costs zero here. So the first empirical question is how many people are actually in that state.

The first number: parallelism is real, but inside the model companies, not in the market

On June 25, six researchers (Drew Johnston, David Holtz, Alex Martin Richmond, Christopher Ong, Prasanna Tambe and Aaron Chatterji) published a large-scale analysis of OpenAI Codex usage data. What makes the study useful is that it splits users into three groups: OpenAI's own employees, external users on organization accounts, and external users on individual accounts. The abstract's headline figure is that more than 10% of users were managing three or more Codex agents at the same time at some point in a given week.

Taken apart, the 10% is an average across three groups whose shapes differ enormously. In the readings for the week before June 11:

• OpenAI employees: only 10.7% were working single-threaded at any given moment, and close to 28.6% had at some point managed five or more agents at once.
• External organization users: 67.4% used no parallelism at all over the whole period; among those who did, most peaked at two.
• External individual users: 63.9% used no parallelism at all.

One more caveat applies to the individual-account group. The sample covers only users who consented to having their queries used for training, so it may not represent all individual users.

So the picture of an agent fleet is real, but it is the daily life of a model company's own staff, not the market's. The market median is zero to two. That lines up with the only field reading SecondSource had in hand: a senior developer who schedules agents into a daily routine, and is founding a company that builds this kind of tool, reported a normal parallel count of at least two. Two is not a modest figure here. That developer sits at the upper edge of external users.

The direction cuts against this piece's conclusion, which makes it more credible. The data is OpenAI's own, and the author list includes the company's chief economist. If there is a motive, the motive is to paint adoption deeper, not shallower. The number the paper reports is that two thirds of organization users do not run agents in parallel at all. When a source's bias points the opposite way from the result it reports, the result stands up better.

In the same study, though, one number runs the opposite direction, and it is the engine for the rest of this piece: the share of users submitting tasks that an experienced human would need eight hours or more to do rose from 2.1% to 25.6%. Parallelism has not spread, but longer single jobs have. A quarter of users now hand over a job that would take a person a full day.

Side by side, the two numbers show a shape. Most people are not watching eight windows at once. They hand over one very large thing and walk away. That matters for everything that follows, because what happens to that thing after the person walks away is the real question.

The second number: how much of the overnight output is usable the next day

What SecondSource wrote at the time: without a next-day adoption rate for overnight agent output, the line that attention is the bottleneck is only a story that sounds right.

The closest public proxy comes from LinearB's 2026 engineering benchmarks report. The population is 8.1 million pull requests from about 4,800 engineering teams in 42 countries. LinearB sorts pull requests into three classes: fully human-written, human-written with AI shaping the change, and fully agent-generated. Acceptance is defined as merged within thirty days. The reading:

Human-written pull requests merged within thirty days 84.4% of the time; AI-assisted ones, 32.7%.

What the number cannot do comes first. It does not say that two thirds of AI-written code is bad. A pull request goes unmerged for many reasons: duplication, replacement by a better approach, a change in requirements, or the author abandoning it. Nor is it an industry constant. LinearB sells tools for improving exactly this process, the dataset is LinearB's own customers, and the report does not publish how a pull request was classed as AI-assisted. The relative gap within one vendor's data under one definition is usable; the absolute level cannot be carried off as common knowledge.

Even with those caveats, one result holds: under one classification standard, across the same teams, AI output reaches the main branch less than half as often as human output. The order of magnitude that was wanted when the judgment was first logged, how much of a night's run is usable the next day, now has an answer: far less than assumed. For the first time, a sample of 8.1 million pull requests can answer it.

Splitting the wait: AI-assisted pull requests wait longer for a first look, then get reviewed faster

The same report splits the time from opening a pull request to merging it into two segments, and the split lands squarely on the step defined above.

The first segment is waiting to be looked at (the industry term is pickup time): from the request being opened to the first person actually starting to read it. The second segment is being looked at: from that start to a conclusion. The readings:

The two segments move in opposite directions. For AI-assisted requests, the wait to be looked at was roughly 5.25 times as long. Once someone sat down to read, the AI-assisted request was faster than the human one (194 minutes against 252).

This split is the most important finding in the piece. It says human review capacity has not degraded; review itself got lighter, probably because AI output is more regularly structured. One experiment supports that. A June preprint, over 64 controlled runs, found that writing out the delegation contract had no effect on correctness, because at that difficulty band everything was already correct. What improved was legibility of what the agent did: the rate at which a changed-files list appeared jumped from 7% to 93%. One caveat applies. All 64 acceptance and reviewability scores came from LLM graders, not people, so whether humans actually find such output easier to review has not itself been tested on humans. What blew up is the first segment: the blank stretch between the output existing and anyone being willing to spare it attention.

That blank stretch is the step defined earlier. So the claim that attention is the upfront cost of verification now has a measured price, in LinearB's data. In this data the upfront cost is more than five times the review itself, and it is the only segment where AI-assisted requests fare worse.

One hole in this reading, stated here first

The most obvious rebuttal was run against it: AI pull requests are bigger, and big things always wait longer.

The rebuttal has grounds. In the same report, the 75th-percentile AI-assisted pull request is 408 lines; the human-written one is 157, a 2.6-fold difference. Size and pickup speed are strongly correlated. One analysis found small pull requests get picked up as much as twenty times faster, and Google's internal rule of thumb holds that review quality starts dropping visibly above 200 lines. A person who sees a 400-line change reflexively puts it off. No theory about agents is needed to explain that.

The rebuttal is not defeated here. LinearB did not recompute waiting time after controlling for size, and the raw data is not public, so no outside recomputation is possible. Of the 5.25-fold gap, how much belongs to too many jobs running at once with attention not stretching to cover them, and how much belongs to a change too big to read now, this piece cannot split.

The one clue cuts against size as the only driver, but it is only a clue. In the report's three-way split, fully agent-generated pull requests run about 290 lines, smaller than the AI-assisted 408. If size were the only driver, the fully automated class should wait less. The report does not publish that class's waiting time separately, so this is an unverified conjecture, not evidence. This is the piece's largest open question and the first thing to ask for next round.

The third number: in Faros's data, 31.3% of pull requests merged with no recorded review

A second independent source pushes this somewhere uglier. Faros AI's 2026 engineering report covers two years of telemetry from 22,000 developers across more than 4,000 teams. The method compares each organization's own metrics between its lowest and highest periods of AI adoption. Readings:

• Median wait for first review up 156.6%
• Median review duration up 441.5% (mean up 199.6%)
• Large items completed per person up 66%; task throughput per person up 33.7%; merge rate per person up 16.2%
• 31.3% of pull requests merged without going through any review at all
• Incidents per pull request up 242.7%; code rework up 861%

The report leaves the 31.3% undefined. It does not say how a pull request was counted as reviewed, whether automated checks or bot approvals count, or whether machine-opened changes are in the population. So the figure cannot be read as the share of changes no human ever saw.

The method has its own problem, which has to come first. Low-adoption period against high-adoption period within an organization is a before-and-after comparison, and more than AI changed over two years: team growth, process changes and staff turnover all mix in. So the magnitudes cannot be taken as precise. But Faros and LinearB are different companies, with different customer bases and different measurement methods, and both show the wait for first review stretching sharply. They disagree on the review itself. In LinearB's data AI-assisted requests were reviewed faster, 194 minutes against 252. In Faros's data median review duration rose 441.5%. That agreement on the wait weighs more than any single number.

The number to watch is the 31.3%. Taken together, three numbers matter: a third of changes merged with no recorded review, AI output gets in only a third of the time, and the wait for first review multiplied several times over. They point to too little review capacity, not review in the wrong order. Some output is approved without a look, and some is never picked up. It leaks at both ends. One end is approval without looking: risk is pushed past deployment, and the 242.7% rise in incidents per pull request hangs there. Separately, a longitudinal study of 182 real projects measured that for every 10 percentage points a project's unreviewed share rises, the downstream maintenance burden from agent contributions rises about 6%. The other end is never picked up at all: of the two thirds that never merged, how many sat until they went stale, the data does not say. The number is not zero.

This diagnosis is a grade more severe than not finding the one to look at. A which-to-look-at-first problem assumes everything eventually gets looked at and only the order is open. In the measured world, most of the output never gets looked at. An ordering problem and a capacity problem take different fixes. Ordering wants a ranking interface. Capacity wants fewer things that need a human to look at them.

Three roads, not two, and the model companies were already in this layer by February

When the claim was first logged as an observation, the fork written down had two branches. If the constraint really sits in the attention layer, tools converge on preview and notification surfaces. Superlogical bets that way. It is a startup building a tool for supervising agents. Its founder is the senior developer who runs agents overnight. Its product preview makes the signature feature a three-finger swipe that live-previews every working tab, and its stated goal is making the session that needs attention easy to find. If the constraint sits in execution, tools converge on isolated environments and fleet infrastructure. Cursor bets that way: Cursor is another company that builds coding-agent tools, and its official changelog says plainly that the aim is letting teams run a parallel fleet of agents that handle tasks end to end, with configurable dev environments, cross-project workspaces and background isolated branches built for it.

Checked, the two-way fork has two problems.

First, the line that model companies cannot eat the desktop-grade live interface was already false when it was written. The reasoning at the time: model companies can eat the scaffold but not the desktop-grade live interface, and Superlogical's self-reported bottleneck was finding good enough native-interface engineers, not models. The timeline does not fit:

• February 2, 2026: OpenAI shipped the desktop Codex app, and OpenAI's own announcement pitches it as a command center for agents, with the selling point of dispatching several tasks at once, running them in parallel and supervising them in one place (Windows followed on March 4).
• Anthropic's Claude Code: in the public changelog on GitHub (anthropics/claude-code, CHANGELOG.md), the view that lists every background session is already down to details. Version 2.1.210 made the agents footer hint show how many background agents are waiting for input, with a brief color emphasis when the count changes. Version 2.1.212 changed sessions that are waiting on a sandbox, on external tool input or on a settings approval from showing as working to showing as needing input. Version 2.1.206 fixed a bug in which that state would occasionally flip back to working. Version 2.1.233, a later release, had already shipped when this was written, so all three entries are in shipped builds.

The last entry is more persuasive than the first two: a status-display bug to fix means the feature has been in users' hands long enough, and used hard enough, to break. A feature still at the concept-video stage does not produce that bug. So the judgment that this was the layer farthest from the model companies was written while both of the largest model companies were already inside it. (In fairness, shipped is not the same as good. Superlogical bets on real-time rendering quality and desktop-grade interaction, and a changelog line does not prove an equivalent experience. A narrower reading holds: this layer is no longer out of the model companies' reach, but who does it well is not yet decided.)

Second, the fork has a third branch, and it predates the other two.

Back to the 31.3% merged with no review. Two readings are possible. One is abandonment. The other is that those changes were reviewed, just not by a person.

The evidence for this road is also the oldest. In September 2025, OpenAI's Thibault Sottiaux, speaking on an official OpenAI podcast about the design motive behind the company's code-review bot, said that as the volume of code needing review grew, the team's biggest bottleneck had become the sheer amount of reviewing its people had to do.

That was eleven months ago, nearly a year before the three data points behind this piece's judgment. And the fix was not a better dashboard for humans but delegating the review as well: a narrow, high-signal review mode that does not just read the diff but works out the intent and the contract behind a change, then goes back to check whether the code actually delivers that intent. Sottiaux described the internal rollout as quite successful, to the point that people get annoyed when it breaks because the safety net feels gone.

So the fork has three roads, each assuming the bottleneck sits somewhere different:

1. The attention surface: the bottleneck is people unable to tell which job to look at. The fix is ranking, preview and notification.

2. Execution infrastructure: the bottleneck is the environment cost of running agents. The fix is isolated environments, cross-project workspaces, caching and governance.

3. Delegating review itself: the bottleneck is total human review capacity. The fix is another agent reviewing first, with people looking only where it raises a hand.

The three measurements above are not neutral between these roads. A fivefold wait for first review, a review that got faster in LinearB's data, and a third of changes merging unreviewed point to insufficient capacity, not scrambled order. A ranking interface does not fix capacity. Even with eight jobs sorted perfectly, a person with time for two still finishes only two. The third road is the only one that touches capacity directly.

The third road has two open problems of its own and cannot be treated as settled. One: the account is a vendor describing its own internal adoption, with no external measurement. Two: a machine reviewer also produces things a person has to look at; its raised hands are themselves a queue. Whether it eliminates work or changes its shape, no data yet answers.

One more case that needs a person, which none of the three roads handles: an agent stalls halfway on a button only a human can press. On August 9 and 10 the creator of the Flask web framework logged the same failure two days running. A password manager's browser extension and a package registry's trusted-publishing settings are both designed for a person sitting at a browser; the agent gets to the door and asks for help clicking through. These interruptions are not an ordering problem or a review-capacity problem. They are a process that cannot finish. They need a fourth thing: authorization interfaces that a machine can complete.

What this changes, and for whom

Companies evaluating an agent platform: the procurement list gains one line, but a more precise one than the usual. The usual question is how the platform tells a person which task needs them, and that covers only the first of three roads. Three measures separate the roads: (a) how much the platform reduces the total output a person must look at, whether it has a built-in review layer and what that layer's false-positive rate is; (b) how long output waits for a human in the vendor's own customer data; (c) what share reaches the main branch without a human looking. The third is the most honest, because it measures how much oversight the system has actually given up, and most vendors do not volunteer it.

Engineering organizations: the most operational sentence in this piece is that the delivery ceiling has moved off the writing end. Per-person throughput alone looks strong, up 33.7% in the Faros data. Over the same period, the teams' median review wait rose 156.6%. A third of changes were merged with no recorded review, and incidents per change rose 242.7%. The scheduling implication is direct. If agents run overnight, the person who clears the overnight output first thing in the morning has to be a named person, not a volunteer, or the output piles up as unclaimed inventory. Unclaimed output may be one contributor to the 32.7% merge rate. The report does not say how much.

Startups building in this lane: the investment thesis that the attention surface is farthest from the model companies needs revising. Both of the largest model companies have shipped in this layer, and one is already fixing edge-case bugs. The defensible space left is not whether the view exists but two other places: cross-vendor (a model company builds the view for its own agents, while a team's eight jobs run on three vendors' tools), and capacity rather than order (ranking's ceiling is how much a person can read in one sitting; reduction's ceiling is an order of magnitude higher). As for the third road: if the real bottleneck is capacity, delegating review has already been endorsed by the largest model company with its own internal tool, eleven months before these three measurements, but so far only on the vendor's self-assessment, with no external measurement. And a machine reviewer produces its own things for people to look at, so whether it eliminates work or merely reshapes it is the blank cell in that road's valuation. The question to watch is whether any model company opens its agent-status view to other vendors' agents.

Individual developers buying tools: most people are not watching eight windows (two thirds of external users run nothing in parallel). The likelier situation is handing over one large thing, leaving, and coming back to one large pile of output. What has value there is a smaller, more clearly structured pile, more than a dashboard. That is what the contract experiment measured: writing the brief clearly does not buy a higher correctness rate (that difficulty band was already all correct); it buys legibility of what was done afterwards. The same June preprint puts the cost of writing out the contract at 13% more tokens and 38% more waiting time. Against AI output that is 2.6 times bigger and waits five times longer, that is a favorable trade, with the caveat that the experiment's graders were models, not people.

Our call

Agents have made delegation cheap and let jobs run long. So the human bottleneck has moved from instruction design to attention. Three mutually independent large-sample measurements support this. The wait for first review stretched sharply in two different vendors' data. In LinearB's 8.1 million pull requests, AI-assisted ones waited about 1,050 minutes against about 200 for human-written ones. In Faros's two years of telemetry, the median wait rose 156.6%. The review itself sped up in LinearB's data, 194 minutes against 252, but slowed in Faros's, where the median rose 441.5%.

But SecondSource's August hypothesis tracked the wrong unit. Its claim that model companies could not build this layer is also false. The unit: the thing in the queue is not the session but the output, so the key number is pull-request waiting time, not the count of open windows. Parallelism itself has not spread. In OpenAI's Codex usage data, 67.4% of external organization users and 63.9% of the consenting external individual users ran nothing in parallel. What spread is longer single jobs. In the same data, the share of users submitting eight-hour-class tasks rose from 2.1% to 25.6%.

On the model companies: the claim that they could not build this layer had counterexamples when it was written. OpenAI's February 2026 launch announcement called the desktop Codex app an agent command center. Anthropic's count of background agents needing input has shipped and is being bug-fixed. More critically, the race has three roads, not two. They are the attention surface, execution infrastructure, and delegating the review itself. The three measurements jointly point to insufficient capacity rather than scrambled order. In Faros's data, 31.3% of pull requests merged with no recorded review. In LinearB's data, AI-assisted pull requests had a 32.7% thirty-day merge rate. A capacity shortfall is bad for products that only rank or preview agent output for humans. The largest open question in this call: of the 5.25-fold waiting gap for AI output, how much is attention and how much is size, which current public data cannot separate. AI changes are 2.6 times larger, and large changes always wait longer.

What would prove this wrong: First, any dataset that recomputes waiting time after controlling for change size. If the AI waiting gap converges to near zero once size is controlled, this piece's core reading, that attention is a separate step and now has a price, is void, and the whole call falls back to sounds right but not yet shown. This is the data most worth asking for and the piece's most fragile section. Second, if the wait for first review falls back in the next annual benchmarks (LinearB and Faros both publish annually, so the next edition is the window; this is a window set by SecondSource, not a date either company has committed to), the bottleneck is transitional congestion rather than a structural constraint, and this call is weakened. Third, if external measurement of the third road, delegated review, shows it does not reduce total human review and only reshapes it, the inference that capacity beats order fails and the three roads return to a draw. Fourth, if external organization users' parallel rate rises sharply in later readings (SecondSource's own threshold: the fully non-parallel share falls below half), the conclusion that parallelism has not spread no longer holds, and the market for ranking interfaces is far larger than estimated here. Fifth, if the model companies make the attention surface a closed feature limited to their own agents with no cross-vendor opening, the judgment that cross-vendor is the remaining defensible space is confirmed; if any model company opens cross-vendor session import, that space closes too.

Written from the same research and judgments as the Traditional Chinese edition. Sources are linked; we distinguish original documents from reporting and mark what we could not verify.