The Third Schedule: A Field Survey¶
Earlier today I published The Third Schedule — a deliberately tight essay arguing that the quiet assumption under Paul Graham's Maker's Schedule, Manager's Schedule has broken: maker time is no longer singular. The evidence was one practitioner's own git history — 9,806 commits across 183 repositories, January through late August 2026 — showing that half of all continuous work sessions (51.6%) put commits into two or more repositories, and one in eight (12.7%) into five or more. Those are the raw figures; a stricter re-scoring of the same dataset that counts only substantive commits — merges, scripted rollouts, doc-and-chore traffic, and sub-ten-line tweaks stripped out — puts them at 42.2% and 5.2%. This survey uses both and says which is which, because they measure different things: repositories touched versus threads genuinely judged.
That essay was built to stand on its own data and claim nothing beyond it. This piece is the companion it deserves: a genuine survey of what everyone else has published on this intersection as of August 2026 — prior reframings of Graham, practitioner accounts of parallel-agent work, the oversight-bandwidth research, the field-scale commit-mining studies, and the skeptics. The rule throughout is the same discipline the tight essay applied to my own informal "20x" gut number, which it declined to treat as data: every external claim gets checked against something actually measured before it's allowed to carry weight. Where the measured thing is my own dataset, I say so, and I say what a sample of one can and cannot calibrate.
The short version, for the impatient: the reframing of Graham for the agent era is genuinely in the air — at least two published pieces walk right up to it. The practitioner pattern is widely and independently reported, with a striking convergence I didn't expect. The oversight-bandwidth ceiling turns out to have twenty years of formal research behind it, from a literature most software people have never opened. The field-scale telemetry corroborates the absorption problem more brutally than my own data does. And the specific measurement at the center of my essay — session-level cross-repo parallelism from git history — appears in none of it, which is a finding of its own that I'll be honest about at the end.
1. Prior art: has someone already written this essay?¶
First obligation of any "X, revisited" piece: check whether someone already revisited X.
They have — partially. The closest published prior art I found is Aparna Chennapragada's Every Maker Is Now a Manager (of AI) (February 11, 2026). She invokes Graham directly — makers rely on long uninterrupted stretches; agent-based work pulls them into supervisory mode — and her core argument is about the cognitive strain of that shift: high responsibility plus low execution control, sustained by conversation, which she correctly identifies as a high-effort cognitive activity in its own right. It's a good essay and it deserves the acknowledgment. But it is explicitly anecdotal and theoretical — the supporting citations are Karasek's demand-control model and Kahneman, not measurements of anyone's actual work — and its claim is different from mine. Chennapragada says the maker has been pulled onto the manager's schedule. The Third Schedule says something stronger and, I think, structurally prior: the maker time itself now parallelizes, and the manager-shaped day is the human's rational response to that, visible in commit metadata. Her essay describes the felt experience of the shift; mine tries to measure its shape. They're compatible — hers is arguably the phenomenology of the same event — but they are not the same essay.
There is also a June 2026 Medium piece, The Maker's Schedule Is Changing. The AI Era Needs a New One, which by its title and search-visible summary reframes Graham around agent supervision and cites the METR productivity research. Honesty requires a disclosure: the article is behind Medium's wall and returned a 403 to my research tooling, so I can confirm it exists and roughly what it argues, but I have not read it in full and won't characterize it beyond that. And DHH has commented publicly on the maker/manager framing in the AI context, though in passing rather than as a worked-out revision.
So: the reframing is in the air, as it should be — the underlying shift is visible to everyone living it. What I did not find, anywhere, is a version of the argument that rests on measured data rather than felt experience. That gap is precisely where The Third Schedule sits, and this survey exists partly to check whether the gap is real or just badly searched. More on that in section 5.
2. The practitioners: who else runs parallel builders, and what do they report?¶
The parallel-agent working pattern is by now abundantly documented by practitioners — almost entirely as workflow description, almost never as measurement.
Simon Willison named the pattern in Embracing the parallel coding agent lifestyle (October 5, 2025): several Claude Code or Codex instances at once, sometimes in the same repo, sometimes across worktrees; one main agent watched closely, others on research, proofs-of-concept, and small maintenance. By November 2025 his parallel-agents tag records what he called his most extreme case: six terminal windows running the same prompt against six different repos. Gergely Orosz documented the same shift as an industry trend in The Pragmatic Engineer's New trend: programming by kicking off parallel AI agents, and Mike Mason's AI Coding Agents in 2026 framed the emerging discipline as "coherence through orchestration, not autonomy" — which is a manager's-schedule sentence if I ever read one.
The most concretely useful practitioner account is Kilo's How 7 Kilo Code Engineers Run Up to 20 Parallel Agents and Still Ship Clean Code (May 26, 2026): seven senior engineers, each running 2–4 foreground agents under active management, with up to 20+ counting fire-and-forget background tasks. Crucially, they admit where it breaks: attention becomes the bottleneck beyond 2–4 actively-supervised agents, output quality decays as context fills, and large diffs defeat thorough review. The same post notes the calibration range across well-known names: Mitchell Hashimoto manages at most two agents; Willison keeps one significant change at a time in focus.
Here is the convergence I didn't expect, and it's the most interesting single thing this survey turned up on the practitioner side. The Kilo engineers' subjective ceiling — 2–4 agents under real supervision, more only as fire-and-forget — is almost exactly the measured distribution in my own git history, arrived at independently and by an entirely different method. My sessions touch 2+ repos 51.6% of the time; they touch 5+ only 12.7% of the time — and when every commit is re-scored for complexity, the versions that count only substantive work come out at 42.2% and 5.2%. Four in five of the multi-repo sessions survive that stricter test, so modest parallelism is real and not an artifact of cheap traffic; the 5+ tail roughly halves, because wide sessions are typically a few hard threads surrounded by mechanical ones. The complexity-weighted pair is the honest one to set against Kilo's 2–4, since "agents under active management" is a claim about judgment, not about repos receiving a commit. Nobody set that ceiling by policy. It's where my practice settled under the ordinary pressure of having to actually stand behind the output — and it lands within the same band that seven engineers at a different company, with different tools, report as the limit of meaningful oversight. One practitioner's measured distribution matching other practitioners' self-reported ceiling isn't proof of a law. But two independent methods agreeing on 2–4-routine-with-a-5+-tail is exactly what you'd expect if the ceiling is set by human judgment bandwidth rather than by tooling — which is the tight essay's central mechanism, showing up in someone else's data. Or rather: in someone else's honest confession, matching my data.
At the far end of the range sits Steve Yegge, whose August 2026 essay The Shape of Things to Come describes his "Wheelhouse" setup: a crew of 18 named design agents, an implementing fleet, standing role agents operating production unattended, roughly 175 real commits a day, 69 billion tokens burned in July, and the claim that "human code review gets a seven-month countdown." Checked against the measured floor: my single most extreme day in eight months — July 14, 205 commits across 60 repos in 12 hours — is in the same numeric neighborhood as what Yegge describes as his steady state. But that day has to face the same complexity-scoring discipline as every other number in this survey, and it doesn't flatter me: 86.6% of those commits were mechanical, 146 of them a single scripted rollout landing an identical platform change across roughly sixty repos. The breadth was real; the substance wasn't spread across it. Strip the mechanical mass away and roughly eight or nine repos received genuinely substantive parallel work that day — not 60, and not the 44 that a naive "repos with three or more commits each" count suggests, since of those 44, only eight had even one substantive commit. That correction sharpens the comparison rather than softening it. The one day in my 236 that reaches Yegge's claimed daily volume turns out to be mostly scripted fan-out wrapped around a small core of real judgment — which is exactly how the supervisory-control research in section 3 says large fan-out is achieved: by driving per-task attention toward zero. I can't audit his numbers and he can't audit mine, so the honest statement is narrow: commit volumes of that order are achievable, because I've measured them — but in my practice that volume is a once-in-eight-months tail, and even the tail was breadth of a fundamentally cheaper kind than the steady-state parallel judgment the headline numbers imply. Anyone presenting tail days as typical days — and the genre invites it — is doing with volume what the perception-gap research in section 4 shows developers doing with speed; anyone presenting mechanical breadth as parallel judgment is compounding it. As for review getting a seven-month countdown: every measured number in section 4 points the other way, and I'll let those numbers make the argument.
One more practitioner data point deserves mention because Willison's tag page treats it with appropriate suspicion: Cursor's FastRender experiment (January 2026), hundreds of concurrent agents on a single project producing over a million lines of code — greeted with immediate skepticism about missing build documentation and failing CI. Hundreds of unsupervised agents producing code nobody can attest to is not parallel maker time; it's the absorption problem deliberately unsolved, as spectacle.
What none of these accounts contains — Willison's, Kilo's, Yegge's, any of them — is session-level measurement. Counts of agents launched, yes. Anecdotes of extreme days, yes. Commit-timestamp analysis showing what fraction of working sessions are actually parallel across real workstreams over months: I found none.
3. The research: oversight bandwidth has a literature, and it's older than you'd think¶
The tight essay's core mechanism — judgment bandwidth as the ceiling — turns out to have a formal research lineage that predates LLMs by two decades. It comes from human-robot interaction, and it's embarrassing how directly it applies.
In the mid-2000s, Dan Olsen and Michael Goodrich formalized fan-out: the number of semi-autonomous robots one human can effectively supervise. The equation is FO = (NT + IT) / IT, where neglect time is how long a robot can be safely ignored before its performance degrades below threshold, and interaction time is how long the human needs to service it (Crandall & Cummings, Developing performance metrics for the supervisory control of multiple robots; a 2025 review of the whole single-human/multiple-robot literature is here). The literature also established the fan-out plateau: past a threshold, adding robots adds no task efficiency at all — the human is saturated. Empirical fan-out numbers in those studies ran from about 5 robots in cluttered environments to about 9 with high autonomy in clean ones.
Read that equation as an agent supervisor and it stops being an analogy and becomes an accounting identity. Raising agent autonomy raises neglect time — that's what all the harness engineering in the five-agents comparison is for. Structuring output as brief-now-detail-on-demand lowers interaction time — that's the absorption pattern the tight essay describes, and the entire Sunstone Atlas trust-ladder, seen from the fan-out side: oversight modes that relax with track record are neglect time being earned. And the plateau is the Kilo engineers' 2–4, and my complexity-weighted 42.2%/5.2% distribution, derived twenty years early on robots. The claim "judgment bandwidth is the ceiling" isn't a 2026 blog intuition. It's settled supervisory-control theory waiting for its third application domain.
The second research pillar is even more pointed, and the date is almost too good: in 2009 — the same year Graham published his essay — Sophie Leroy published Why is it so hard to do my work? The challenge of attention residue when switching between work tasks (Organizational Behavior and Human Decision Processes 109(2)). Attention residue is the mechanism underneath Graham's essay: when you switch away from an unfinished task, part of your cognition stays with it, and performance on the next task measurably degrades — worst when the abandoned task was unfinished and time-pressured. Graham named the economics; Leroy, the same year, measured the physiology. This matters for the third-schedule argument because it draws the boundary honestly: the human side of the check-in day still pays Leroy's tax in full. Parallelizing builder time doesn't repeal attention residue — it concentrates all of it onto one person, which is exactly why the measured ceiling sits at 2–4 and not 20. The agents escaped Graham's economics. The director didn't.
Third, and most current: Microsoft Research published Overseeing Agents Without Constant Oversight: Challenges and Opportunities (Grunde-McLaughlin, Mozannar, Murad, Chen, Amershi, Fourney — 2026), three user studies on how to present agent reasoning traces so humans can actually verify them. Their finding cuts uncomfortably close to the tight essay's favorite pattern. A redesigned trace interface reduced the time participants spent finding errors — but final accuracy was not meaningfully improved. Faster review, not better judgment. I lean hard on "brief now, full detail on demand, evidence attached" as the absorption mechanism, and this study says the brief can make you quicker without making you righter — the tension they name is that traces must be "informative, but not overwhelming," and interface design alone doesn't resolve it. Checked against my own practice: nothing in my commit data can rebut this, because timestamps measure throughput, not judgment quality. The honest position is that the Grunde-McLaughlin result stands as an open threat to the check-in pattern — it suggests the five-minute check-in can feel sufficient while sampling too shallowly — and the only real defense is the one the governance posts argue for: evidence trails that are checkable rather than merely readable, so sampling has teeth. Whether that defense actually closes the accuracy gap is, on current evidence, unproven. I'd rather write that sentence than pretend otherwise.
4. The field telemetry: absorption is already failing at scale¶
If the third-schedule thesis is right, the field-scale symptom should be production outrunning review everywhere agents are deployed without an absorption design. The 2026 telemetry is unambiguous, and grimmer than I expected.
The most complete aggregation I found is FlowVerify's compilation of 2026 review-bottleneck data, which collects numbers from Faros AI's 2026 telemetry (~22,000 developers), LinearB's 2026 Software Engineering Benchmarks Report (8.1 million pull requests, 4,800+ teams), and GitHub. I'm citing these through the aggregator, which names its sources; the numbers below are theirs, not mine, and I haven't re-derived them from the underlying reports. With that caveat:
- Faros AI: task throughput per developer up 33.7% — while median code review time is up 441.5%, code churn is up 861%, and pull requests merged with no review at all are up 31.3%. Production-incidents-per-PR up 242.7%.
- LinearB: AI-assisted PRs run 400+ lines at the 75th percentile versus 157 for unassisted; reviewer pickup time 16+ hours versus ~200 minutes; and — the number that stopped me — a 30-day merge rate of 32.7% versus 84.5% for unassisted PRs. Two-thirds of AI-assisted PRs in that dataset just… sit there.
- Also widely reported (CIO's write-up is representative): CircleCI data showing feature-branch throughput up 59% year over year while median main-branch throughput actually fell.
Read as a whole: the field produced dramatically more, reviewed dramatically slower, skipped review more often, and merged less. That last pair — CircleCI's rising feature branches and falling main-branch throughput, LinearB's 32.7% merge rate — is the third-schedule collision measured at industry scale: builder time parallelized, judgment bandwidth didn't, and the queue between them is now visible in everyone's metrics. The tight essay's line was "the organizations that don't figure out absorption will drown in the output of their most productive workers." I wrote that as a warning. The telemetry says it's a description.
Checked against the measured floor, one instructive contrast: in my own eight months, commits landed on 223 of 236 calendar days across 183 repos — the work absorbs, continuously, because the whole practice is built around short-loop review with evidence attached, one accountable human, no queue to another reviewer. That's not a boast about scale — it's a sample of one, on work I chose — but it locates exactly where the field's numbers and mine diverge: the bottleneck isn't AI producing too much. It's produced work waiting on judgment that was never restructured to receive it. A single practitioner can restructure themselves. A 4,800-team dataset, evidently, mostly hasn't.
On the field-measurement side proper, the mining-software-repositories community started publishing hard numbers this year. The most rigorous is Khosravani & Mockus, Detecting AI Coding Agents in Open Source: A Validated Multi-Method Census of 180 Million Repositories: commit-attributed agents collectively landing over 320,000 commits per month by April 2026, Claude Code alone at 886,122 cumulative commits across 17,295 projects — and, tellingly, a 30x relative-recall gap between naive bot-account detection and their multi-method census, meaning most prior counts of agent activity were undercounts by an order of magnitude. Companion studies profile the behavior: How AI Coding Agents Modify Code analyzes 24,014 merged agentic PRs comprising 440,295 commits from the AIDev dataset, and Fingerprinting AI Coding Agents on GitHub shows the major agents leave distinguishable behavioral signatures across 33,580 PRs.
These are real, large, careful measurements — and every one of them measures the agent's output stream. Which repos, which PRs, what code shape, which tool. None of them reconstructs the human director's working session across their whole portfolio: how many distinct workstreams one accountable person actually advances in one continuous stretch. That view requires owning the vantage point — every repo, every timestamp, one identifiable human — which public-data researchers structurally don't have.
5. The skeptics, and what survives them¶
The strongest skeptical evidence in this space remains METR's randomized controlled trial (July 2025): 16 experienced open-source developers, 246 real tasks in mature repos they knew well, and the famous result — tasks took 19% longer with AI tools allowed, while the developers believed they'd been made 20% faster. A 39-point gap between perception and measurement, in the gold-standard study design.
Every practitioner essay in section 2, including mine, has to be read under that shadow: this is a field in which sincere, expert self-report about one's own productivity has been experimentally shown to carry the wrong sign.
METR's own follow-up complicates the picture honestly in both directions. Their February 2026 update reports that a newer, larger cohort (57 developers, 800+ tasks, late-2025 tools) showed only a −4% slowdown with a confidence interval spanning −15% to +9% — statistically indistinguishable from zero — and announces a redesign of the experiment, partly because developers increasingly refused to be randomized into working without AI, which corrupts the signal. METR states they believe developers are likely more sped up in early 2026 than the 2025 estimate suggested. So the skeptical literature, read carefully, says: the measured effect moved from negative toward zero-or-positive within a year, the selection problems are getting worse, and nobody's headline multiplier — positive or negative — deserves your confidence without a measurement attached. The broader skeptical genre — The 10x AI Developer is a Myth, 93% adoption, ~10% measured gains — mostly amplifies that same caution against multiplier talk.
I want to be precise about what this skepticism does and doesn't touch in the third-schedule argument, because engaging it fairly is the point of this piece. METR measures speed on single tasks — does AI make one developer finish one issue faster? The Third Schedule deliberately claims nothing about speed: no 20x, no throughput multiplier, no "faster." Its claim is about structure — that sessions demonstrably span multiple simultaneous workstreams — and structure is exactly what commit timestamps measure well and perception distorts least. You can misjudge how fast you are by 39 points; you cannot easily hallucinate commits into 60 repositories in 12 hours — though, as section 2 concedes, you can script most of them, which is why the complexity-scored numbers are the ones I let carry weight. In that specific sense the essay was built METR-proof, and this survey confirms the design choice was the right one: the perception-gap result demolishes the multiplier genre while leaving the parallelism measurement standing. What METR does legitimately threaten is any quiet slide from "parallel and structurally transformed" to "and therefore more productive" — a slide the tight essay refuses in its final section, a refusal this survey has only reinforced. And one skeptical arrow lands regardless: my dataset shows commits, not outcomes. A parallel session that ships three repos' worth of work I later revert would look identical in the data. Timestamps measure the shape of the work; only the longer record — did it stay merged, did it stay in production — measures whether the shape was worth having. Eight months in, the work has stayed. That's evidence, not proof.
Finally, the "agents work while you sleep" story, which my data already contradicted (2.6% of commits overnight), turns out to be contested in the field too. Fortune's February 2026 piece reports the gap between the always-on marketing and the reality of agents that stall, break, and demand supervision the moment stakes rise. Greptile's Rise of the Overnight Agents (May 2026) is more optimistic on autonomous-PR quality — but, notably for this survey, opens by confessing skepticism of the overnight anecdotes and contains no timing data whatsoever: it never measures when the work actually happens. As far as I can determine, nobody selling or studying the overnight story has published a timestamp distribution. Mine says 07:00 to 23:00, anchored to one awake human, 2.6% at night. I'd genuinely welcome someone else's timestamps proving their pipeline different — that's a falsifiable, checkable claim, which is more than the marketing offers.
What this survey settles, and the gap it confirms¶
Pulling the five threads together:
The reframing has prior art, and the differentiation is real. Chennapragada got to the maker-becomes-manager phenomenology first, in February, and deserves the citation. Nobody I can find got to maker time itself parallelizes, measured — the claims in print are experiential, the data in print is agent-side.
The practitioner ceiling and the measured distribution agree. 2–4 actively-supervised parallel threads as routine, 5+ as tail: reported subjectively by Kilo's engineers and Hashimoto's restraint, measured objectively in my session data — where the complexity-weighted figures, 42.2% of sessions with substantive work in two or more repos and 5.2% clearing five, are the honest match, since "actively supervised" is a claim about judgment rather than repo touches — and predicted formally by fan-out theory twenty years ago. Three independent methods, one number band. That's the closest thing to a replicated finding this young field has, and none of the three parties coordinated.
"Judgment bandwidth is the ceiling" is not a blog claim. It's Olsen–Goodrich fan-out, Leroy's attention residue, and 2026's own review telemetry — +441.5% review time, 32.7% merge rates — agreeing across three unrelated literatures. The tight essay's mechanism has, it turns out, the strongest external backing of anything in it. What has weaker backing than I'd like is my favorite mitigation: the Microsoft Research trace-verification study shows summaries can speed review without improving its accuracy, which keeps "brief now, detail on demand, evidence attached" a design hypothesis with a real open question at its center, not a solved pattern.
And the gap: I searched for a published equivalent of the core measurement — session-level, cross-repo parallelism reconstructed from a full portfolio's git history over months — and found none: not in practitioner essays, not in the MSR papers, not in vendor telemetry. My honest read is that this is vantage-point novelty rather than intellectual novelty. The analysis is trivial — commit timestamps and a two-hour session gap; any of the census authors could run it in an afternoon. What's rare is the position to run it: one person with full git access to 183 repos comprising essentially their entire working output, plus the incentive to check their own multiplier claims instead of quoting them. The MSR community measures agents because agents are what public data exposes; the practitioners narrate rather than measure because their evidence is scattered across employers' private repos. If this measurement is a first, it's first the way a photograph from an unusual window is first. The window is reproducible — anyone running a parallel-agent practice on their own repos has the same data sitting in their .git directories. The fan-out plateau at 2–4, the 07:00–23:00 envelope, the weekend flattening: every one of those is checkable against your own history with a day's scripting. The tight essay made a claim from one window. This survey's conclusion is an invitation: open yours, and publish the distribution. Three windows would make it a literature.
Co-authored with Claude, which also did the source research for this piece — every citation above was located and checked against the live source during writing, not recalled from memory; where a source couldn't be fully read (one paywalled Medium post) or was cited through an aggregator (the Faros/LinearB numbers via FlowVerify), that's disclosed inline. The companion essay is The Third Schedule; the same-day sibling on the correspondence dimension is Who Is This Document For?; the governance series this connects to starts at Trust Is Earned, Not Asserted. And Graham's original is still where it always was.
Series: The Third Schedule
← The Robots Got There First · Part 3 of 5 · Fan-Out: What the Literature Already Knew About the Third Schedule →