Over the past nine months I have run LLM agents against the largest projects I have ever worked on alone: a stable of open source tools I use and maintain daily, and the automated pipeline that publishes part of this blog. The models improved underneath me the whole time, and that helped less than I expected. What actually moved the needle was learning to handle four challenges: providing the right context, iterating through non-obvious design decisions, managing the scale of the work, and keeping artifacts consistent while decisions change. None of the four is about getting a model to write better code. All four decide whether the code the model writes turns into a finished project.

What the nine months covered

#

GitHub gives the scale better than my memory does: since January I have contributed 1,338 commits across 51 repositories, along with 66 pull requests and 181 issues. By mid September, 9 months in, the session counter read 3,400 sessions, 82,000 messages, and 6.8 billion tokens, 6.5 billion of them served from cache, spread across 63 projects and 33 models, on a path that had moved from Claude Sonnet 4.5 to GLM 5.3 Flash. The volume is not the point. The point is that the same four challenges appeared in every project, and how I answered them changed more than any model upgrade did.

Challenge 1: Providing the Right Context

#

Nine months ago my working assumption was that a capable agent would gather whatever it needed by exploring the repository. On a small project, that assumption holds. On a large one, it fails quietly: a session is generally scoped to a single location, one repository or directory, and a large project rarely fits inside one, so each session sees a narrow slice of the project, and the knowledge outside that slice might as well not exist. The cost showed up as steering time. I would launch a session, come back, and find it had built on a wrong assumption, then spend the next half hour correcting course. Worse, the corrections sometimes left the written context inconsistent, one artifact updated while the artifacts that depend on it stayed stale, and later sessions inherited the contradiction as ground truth. On a large project, under-provisioned context does not just slow one session down, it poisons the sessions that follow.

What I do now is treat context provisioning as a phase with an exit condition, not a chore. Access first: every source the answers live in gets a way in and a pointer, which is the setup I described in Teach Your Agent Where Everything Lives. Then the map: which repositories exist, how they relate, where decisions live, written down so a cold session can orient in minutes. The exit condition: a cold session, dropped into the project with only its instructions file, can find every source it needs without asking me. I test it by handing the session a question whose answer I know lives in one of the mapped sources, and provisioning is done when it comes back with the answer and the trail instead of a question. The principle underneath is the one I keep coming back to, that context quality dominates model choice. Every session I launch inherits the preparation, and every session I under-provision collects the tax in steering time.

Challenge 2: Iterating Through Non-Obvious Design Decisions

#

The decisions that sink large projects are rarely the ones I can state up front. They are the non-obvious ones: how two modules should share a data format, what happens when a change is abandoned halfway through, whether a behavior belongs in a shared library or in the calling code. I cannot enumerate those in a prompt, and an agent cannot discover them from the code alone, because half of them are not written down anywhere.

What I do now is iterate. Before any implementation session launches, I work with an agent to understand the current codebase and describe the changes we need to make, and we go back and forth until most open questions are resolved. The agent is a design partner, not a typist: it restates my description, catches the cases I glossed over, and proposes the alternatives I did not consider. The exit condition is simple: when the questions the implementing agent would ask have already been asked and answered, the design conversation is done. Answering a design question in conversation costs minutes. Answering it mid-implementation costs a stalled session, a wrong branch, or a refactor, and the stalls compound on every long run. This is the principle behind Say It Once, that every question an agent would ask mid-run should be answered before the run, applied one phase earlier: not just the standing rules, but the design itself.

Here is the loop as it runs today, from first contact with the codebase to the moment parallel sessions can safely start:

flowchart TD
    A[Explore the current codebase with an agent] --> B[Describe the change]
    B --> C{Open questions remain?}
    C -->|yes| D[Agent questions assumptions and proposes alternatives]
    D --> B
    C -->|no| E[Write decisions into the artifact tree]
    E --> F[Seed requirements and specs per feature]
    F --> G[Stand up the verification environment]
    G --> H[Partition the work and launch parallel sessions]

Challenge 3: Managing the Scale of the Work

#

A large project carries more work than one session can absorb, and more than I can supervise. On the most feature-heavy project I have run through my pipeline, the features outnumbered my attention within weeks: creating a directory per feature was cheap, walking each one through design personally was not. The answer is delegation and parallelism, but both have to be earned. Parallel sessions collide unless the work is partitioned along real seams, and the seams only become visible through the design iteration of the previous section.

The preparation is what makes scale manageable. Each feature keeps its own artifact directory, seeded before any implementation session starts. Owning agents take features as far as they can and stop at the gates that need a human decision. Sessions get their own worktrees, so parallel work never steps on itself. Tasks that share a file serialize; everything else runs in parallel. Parallelism is earned at partition time, not at spawn time. Spawning ten sessions on an unpartitioned codebase produces ten half-features and a merge conflict. Spawning ten sessions along the seams the design conversation exposed produces a project.

The other half of scale is me. With a dozen sessions running, I become the bottleneck unless decisions are batched and gates are explicit, which is the supervision problem I worked through in Managing Many Concurrent LLM Agent Sessions.

Challenge 4: Keeping Artifacts Consistent While Decisions Change

#

The final challenge never stops. On a project with dozens of interlocking features, decisions keep changing, and every change ripples. A revision to one feature’s specification forces updates in the requirements and plans of the features that consume what it produces. A session forked last week works from a snapshot that the sessions around it have already moved past.

Nine months ago I treated consistency as something to check at review time. Review time is too late: the stale artifacts have already fed other sessions by then. What I do now comes in two layers. Artifacts declare what they depend on, so the ripple has a map, and a propagation pass follows the map when an artifact changes, updating dependents or raising questions where a decision is needed. I worked out that mechanism in detail in What Needs Updating When Agents Do the Work. Verification environments catch whatever the map misses: an hour spent making the environment catch the inconsistency beats an hour reading diffs hoping to see it, which is the trade I laid out in My AI Workflow. Consistency on a large project is not a milestone you reach, it is a loop you run, and only a machine can run it at the frequency the project changes.

What to Do Next

#

1. Before launching implementation, run the design loop with an agent until the open questions are resolved, and write the answers where the implementing sessions will read them.
2. Treat context provisioning as a phase with an exit condition: access, map, pointers.
3. Seed the artifact tree per feature before the first implementation session starts.
4. Partition along the seams the design work exposed, isolate with worktrees, and serialize whatever shares a file.
5. Add dependency declarations and a propagation pass so artifact consistency is maintained by loop, not by review.
6. Watch your steering time: if you correct sessions more than you review them, the context was under-provisioned.

See also

#

• Three Gaps My SDLC Pipeline Hit on a Machine Learning Platform - the failures that produced the scale and consistency challenges
• What Needs Updating When Agents Do the Work - the pull-request-node version of the artifact graph and propagation pass described in Challenge 4
• Speeding Up LLM Work on a Single Codebase - the parallelism mechanics this article summarizes, in full detail
• Say It Once - standing rules that replace mid-run questions, the runtime twin of the design loop
• My AI Workflow - where the skills and verification environments come from
• Six Months with OpenChamber - the tooling that made running thousands of agent sessions practical
• Managing Many Concurrent LLM Agent Sessions - the supervision side of scale
• The Importance of Context When Interacting with LLMs - the principle underneath the first challenge

References

#

• METR, “Measuring AI Ability to Complete Long Software Tasks” - the reliability gap on long tasks that makes preparation and verification mandatory
• Anthropic, “Effective Context Engineering for AI Agents” - attention budgets and just-in-time retrieval, the theory behind the context phase
• git worktree - the isolation mechanism behind the parallel sessions

When an agent pushes a code change, the change itself is the fastest thing in the pipeline. The PR title and description written before the second revision, the review comments nobody answered, and the red CI run all become outdated and inconsistent with the code. Agentic work does not end when the code is written, it ends when a change has propagated through the graph of records in both directions.

The Push Is Never Final

#

In human-paced development, a push was a statement of completion. The author finished the work, wrote the PR title and description last, and pushed once. The PR title and description were accurate because they were written after the code settled.

Agentic development breaks that ordering. An agent pushes a first draft, receives feedback, addresses it, and pushes again. Then it rebases, fixes a failing test, and pushes again. Each push improves the code and invalidates the records describing the previous version. The diff updates itself on every push, the PR title and description do not.

That asymmetry is the whole problem. After three iterations, a pull request can contain correct code wrapped in a wrong story. The PR title and description explain a feature that no longer exists. The comments hold questions the final code already answers. The last CI run failed before the final fix landed, and nothing explains why the failure no longer matters. Nothing in the code is broken, and everything around the code is stale.

A Graph of Artifacts, Not a Checklist

#

These stale records present themselves as a checklist: walk the pull request and fix each one. The checklist view fails because the records are not independent, each one was written from another. The artifacts around a change form a directed acyclic graph. The issue feeds the requirements, the requirements feed the specification, the specification feeds the code, and the code feeds the tests, the PR title and description, and the documentation, and no artifact feeds back into itself. Each artifact should declare what it depends on, because the declarations are the map that a propagation pass follows.

Here is the structure, with a change entering at the code node:

flowchart TD
    ISSUE[Issue] --> REQ[Requirements]
    REQ --> SPEC[Specification]
    SPEC --> CODE[Code]
    CODE --> CI[Tests and CI]
    CODE --> DESC[PR title and description]
    CODE --> DOCS[Documentation]
    SPEC --> DESC
    X([A change lands in one artifact]) -. enters .-> CODE
    ISSUE <-.-> REQ
    REQ <-.-> SPEC
    SPEC <-.-> CODE
    CODE <-.-> CI
    CODE <-.-> DESC
    CODE <-.-> DOCS
    SPEC <-.-> DESC

Solid arrows are declared dependencies: an artifact is built from the artifacts its solid arrows come from. Dotted double arrows are propagation, and they run along every edge in both directions. Downward, a changed artifact updates its dependents: the PR title and description must be rewritten, the documentation must describe the new behavior, and the test expectations must assert it. Upward, a changed artifact questions its premises: if the code had to deviate from the specification to work, the specification is now wrong, the requirements it satisfied are in doubt, and the issue behind them may be wrong too. No matter where the change lands, the two walks visit every artifact the declared edges connect.

Propagation has to run in both directions, because each direction catches a different kind of staleness. Downward-only propagation keeps the record aligned with the change while leaving the premises unexamined, which produces a consistent account of the wrong decision. Upward-only propagation questions everything and updates nothing. An agent runs both walks mechanically: it follows the declared edges, applies every update whose resolution follows from the change, and raises a question wherever two connected artifacts disagree in a way that admits more than one resolution.

A single forward pass is the ideal Say It Once argues for. The issue produces the requirements, the requirements produce the specification, the specification produces the code, and the code produces the rest, with every question answered before the next artifact starts. In most cases, though, the forward pass cannot complete in a single iteration, because some gaps become visible only when a downstream artifact is produced. Writing the code is how you learn the specification never said what happens when the input is empty. Writing the documentation is how you learn that nobody decided what the feature is called. Producing a downstream artifact is also a probe: it tests the artifacts before it, and every gap it finds sends the walk back upward.

The Update Loop

#

The loop below is the graph in motion at the pull request node, the place where every agent-authored change lands first. Automated review reads the diff and produces feedback. An agent addresses that feedback, with a human steering when judgment is needed. The agent then brings the pull request back in sync: it replies to the review comments, handles the CI failures, and updates the PR title and description if the latest push made them outdated. The documentation that describes the changed behavior is updated in the same pass. Then review runs again.

flowchart TD
    A([Code change pushed]) --> B[Automated review and CI run]
    B --> C{Feedback or failures?}
    C -->|none| M([Ready to merge])
    C -->|yes| D[Agent addresses the feedback]
    HUMAN[Human feedback] -. steers .-> D
    D -. raises questions .-> HUMAN
    D --> U[Agent brings the PR back in sync]
    U --> F[Replies to PR comments]
    U --> G[Handles CI failures]
    U --> I[Updates the outdated PR title and description]
    U --> DOCS[Updates the documentation]
    F --> B
    G --> B
    I --> B
    DOCS --> B

Every station in this loop has an owner, and the default owner is the agent. Assigning any station to a human by default re-serializes work the machine could finish in minutes, the same mistake made at pipeline scale when human review gates machine-rate output in Rethinking Code Review in the Age of LLMs. The update loop runs several times per pull request, so any station handled by hand multiplies by the number of iterations, not the number of pull requests.

The Three Update Jobs

#

At the pull request node of the graph, the propagation pass takes the form of three jobs. Documentation is a dependent of code too, and it is updated in the same pass, inside the same pull request as the code change.

Every comment gets a reply

#

An unanswered review comment is ambiguous. The reader cannot tell whether the agent missed it, disagreed with it, or resolved it silently in a later push. The agent should reply to every comment with what it changed and why, including an explicit “declined, because” when it rejects a suggestion. The reply is not politeness, it is what turns the thread into a record. A thread where every comment has an answer reads later as a decision log, and the human who scans it before merging reads conclusions instead of mysteries.

A CI failure is input, not a verdict

#

For a human author, a red build is a judgment to react to. For an agent, it is input to consume. The agent reads the failure, fixes the code, reruns the suite, and pushes. The loop continues without a human ever opening the log. Escalation stays reserved for the cases that need a decision: the same failure returning across pushes, a flaky test worth deleting, or a fix that changes behavior the specification did not authorize. A CI failure routed to a human queue is a decision the pipeline refused to make.

The PR title and description follow the code

#

The PR description is written when the pull request opens, which means it describes draft one. The title goes stale the same way: it names the purpose the change opened with, and the purpose may have moved by the third revision. By the time the code merges, both can be documents about a version that no longer exists. The agent should rewrite the description after significant revisions, and update the title whenever the purpose of the change moved, so both always describe the current diff: what changed, why, and which suggestions were rejected and why. A PR title and description are a promise about what the diff does, and an agent that stops updating the promise is asking the reader to audit the diff to find out.

Where the Human Fits

#

The human feedback in the loop enters as steering, not as typing. The human does not write the replies, fix the builds, or reword the PR titles and descriptions. The human reviews the agent’s proposed resolutions and decides the contested suggestions. The human also ends disagreements, because an agent arguing with an automated reviewer can cycle forever, and only a human can call the argument. And the human answers what propagation cannot settle: an update either follows from the change or it does not, and when it does not, the upward walk stops and hands the human a decision instead of a diff. The human’s job is not to answer the comments, it is to decide what the answers mean. Attention spent typing replies is attention not spent steering, and steering is the part of the loop a machine cannot do, which is the same division of labor argued in The Acceptance Gap.

I run this loop on my own work. When I open one of my agent’s pull requests, the threads are answered, the failures are explained, and the PR title and description match the diff. The judgment calls are still mine, which is exactly where my attention is worth the most.

The division also has an upstream payoff. When review feedback keeps revealing the same misunderstanding, the fix is not a better reply, it is a better specification, and the human is the only one positioned to write it.

What to Do Next

#

1. Make “reply to every review comment” a standing rule in your agent’s instructions, with an explicit declined-and-why format for rejected suggestions.
2. Have an agent handle PR feedback asynchronously: when a piece of feedback lands, it is already addressed by the time you look, and your part is to immediately pick the action to take instead of manually triggering an agent to address it.
3. Route CI failures to the agent before they reach a human, and escalate to you only on repeat failures or ambiguous fixes.
4. Add a PR title and description refresh as a required step before every re-review request and before merging, so both always match the latest diff.
5. Declare the dependencies between your artifacts: which issue a requirements document answers, which requirements a specification satisfies, which specification a change implements, which code a PR title and description describe. Propagation without a map is guesswork.
6. After every change, run the propagation pass in both directions: update what depends on the change, and re-check what the change depends on.
7. Watch the loop for livelock: when the same feedback returns twice, stop the agents and make the design call yourself.
8. Audit the artifact graph occasionally: check whether every artifact still matches what it depends on, across issue, requirements, specification, code, tests, PR title and description, and documentation, and treat the mismatch rate as the measure of how much of this loop you are still running by hand.

See also

#

• Rethinking Code Review in the Age of LLMs - the argument that verification moved from human reading to automated gates, the context that makes an agent-owned update loop necessary.
• Abandoning Code Review in the Age of Agents - reason 11, that review comments no longer land anywhere, is the record half of the gap this loop closes.
• Say It Once - the same principle applied around a run: answer the questions before the run, and answer every comment once, in the thread, after it.
• Nine Months of LLM Agents on Large Projects - the project-scale version of the artifact graph, where artifacts declare dependencies and a propagation pass follows the map when one changes.
• The Acceptance Gap - why acceptance, not review, is the gate between an agent and production, and where the human in this loop should spend attention.
• My AI Workflow - where the skills and verification environments that automate this loop come from.

References

#

• GitHub, “About GitHub Copilot cloud agent” - evidence that agent-driven changes with iterate-through-review cycles are shipped product behavior, not a personal experiment.

A team of six engineers runs the on-call rotation for an entire system, and the request for more people goes nowhere. The instinct is to treat this as a hiring problem and wait for management to fix it. Hiring is the slowest and least controllable lever you have, so the rotation has to get lighter first, and the case for headcount has to become a business case instead of a complaint. Here is what I would do in that position, in order.

The Rotation Is a Relearning Machine

#

Start with the arithmetic of a six-person rotation. Each engineer is primary once every six weeks and secondary once in the same window. Every primary shift demands enough context to triage, mitigate, and escalate a failure anywhere in the system. Between shifts, five weeks pass with little reason to touch the parts of the code you only see when they break. Memory of unfamiliar subsystems decays in days, not months, so by the time your shift arrives you are substantially relearning the system.

When every shift requires remembering everything and the gaps between shifts let the memory rot, you have not designed a rotation, you have designed a scheduled relearning exercise.

The Google SRE book, “Being On-Call” states the standard explicitly: an on-call engineer should feel capable of swift, effective action, and high page load or long post-shift recovery is treated as a defect of the system design, not of the person. The SRE Workbook’s on-call chapter makes the same point operationally: burden has to be balanced, or the rotation quietly converts engineers into ex-engineers. A six-person full-system rotation where nobody feels capable of acting is not a staffing failure yet, it is a design failure.

Count the Pain Before You Name the Cure

#

Instrument the pain first, because adjectives do not move management and you need the numbers for the later steps anyway. Export four weeks of paging data and compute a handful of numbers:

• Pages per shift, split by primary and secondary, and by day versus night.
• The actionable ratio: the fraction of pages that required genuine human judgment rather than a restart, a throttle bump, or an acknowledgment and nothing.
• Time to mitigate, and specifically how long it took the responder to have enough context to act at all.
• Repeat incidents: the same failure mode paging more than once.
• Re-entry ramp: how long it took each engineer to be fully productive on their normal work after coming off a shift.

Most teams that run this exercise discover that half or more of their pages were noise, and that the re-entry ramp after every shift costs a day or more of productive work per engineer. You cannot make a rotation lighter if you cannot say what it currently weighs.

Shrink the Load the System Puts on People

#

With the data in hand, reduce what pages and what a page demands.

Apply the alerting standard from the SRE Workbook’s “Alerting on SLOs”: a page is for a user-visible symptom that needs human judgment right now. Everything else becomes a ticket, a dashboard entry, or nothing. The alert that fires twice a week and is always dismissed is not information, it is an alarm nobody heeds, and it is eroding the reflex you need at 3 a.m.

For the pages that survive, write runbooks so the responder can act without tribal knowledge. A page with a runbook is a procedure, and a procedure survives the five-week memory gap. A page without one is a puzzle, and puzzles are what burn people out at night. The PagerDuty Incident Response guide’s “Being On-Call” chapter treats runbooks and escalation paths as core equipment of the on-call, not nice-to-haves.

Then standardize the machinery behind the alerts: one deployment path, one logging format, one dashboard layout per service. Most of the weight of on-call is not the size of the system, it is the size of the system minus what is written down. You do not control headcount this quarter, but you control this, and it compounds.

Split the Territory Instead of Stretching the People

#

If six people cannot hold the whole system, stop asking six people to hold the whole system. Partition ownership into two or three areas, by product surface or by subsystem, and rotate on-call within an area. The primary for another area becomes the escalation target when a page turns out to cross boundaries, which the incident review will catch and correct.

A three-person rotation puts the pager on each engineer every three weeks instead of every six, for half the system. But there is a trade-off: each area develops less cross coverage than one shared pool. You mitigate it by pairing the secondary from a neighboring area on big changes, and by rotating engineers between areas every few quarters so knowledge diffuses.

The reason the more frequent cadence is survivable is the one this article opened with: the pager arrives before your memory of the territory decays, and when it does arrive, the relearn covers four services instead of eight.

Team Topologies makes the underlying principle explicit: team cognitive load is the limit on what a group can own, so territory should be handed out in proportion to absorption capacity. Six people whose absorption capacity covers half the system are not underperforming, they are correctly reporting the size of the system.

There is a second benefit that matters for the hiring fight: if the system genuinely needs two rotations to be covered safely, you now have the strongest possible evidence for your headcount case, in the org’s own vocabulary.

Escalate as a Business Case, Not a Complaint

#

Headcount requests die as complaints and survive as cost calculations. Convert your measured pain into money: incident minutes multiplied by their revenue impact, engineer hours spent on re-entry ramps, and the replacement cost of an engineer who leaves, which Gallup puts at half to two times annual salary. Attrition is the number that lands, because a burned-out on-call engineer does not just handle pages badly, they take their context with them when they quit.

Then present the ask as a trade-off management has to accept in writing, not a favor it has to grant. With current staffing, one of three things happens: the team accepts a higher incident risk, the team accepts reduced coverage or slowed delivery, or the team gets help. If management reads that page and still does nothing, the pain has been priced and accepted, and you should operate knowing that.

Operate knowing it means this: keep doing the work you unilaterally control, the alert pruning, the runbooks, the territory split, and decide for yourself how long the residual risk is worth absorbing with your own nights.

What to Do Next

#

• Export four weeks of paging data and compute the actionable ratio and re-entry cost.
• Delete or downgrade every alert that is not a user-visible symptom needing judgment now.
• Write a runbook for each of the top five recurring pages.
• Propose two or three ownership areas with a rotation per area, and run it as an experiment for one cycle.
• Put the one-page business case in front of management with an explicit accept-or-fix decision requested.

Headcount may well be the right answer eventually, but a rotation you made lighter and a case you made undeniable are the only two things you control this quarter.

See also

#

• Code Factories: The RollerCoaster Tycoon Perspective - the patrol zone framing of giving an on-call engineer too many services to cover.
• The Codebase Gardener - why trying to personally hold every line is the fastest route to burnout.

References

#

• Google SRE Book, “Being On-Call” - the standard that on-call quality is a designed property, including page load limits and post-shift recovery.
• Google SRE Workbook, “On-Call” - operational guidance on balancing on-call burden across a team.
• Google SRE Workbook, “Alerting on SLOs” - the criteria for what deserves a page versus a ticket.
• PagerDuty Incident Response, “Being On-Call” - runbooks, escalation paths, and preparation as core on-call equipment.
• Skelton and Pais, “Team Topologies” - team cognitive load as the limit on how much territory a team can own.
• Gallup, “This Fixable Problem Costs U.S. Businesses $1 Trillion” - the half to two times salary figure for replacing an employee.

When a senior engineer opens a pull request, the reviewer should be able to start judging the change, not excavating it. The standard is that everything which did not require a second brain is already done before the review request goes out. CI is green, the diff is small and single-purpose, the description explains the change, the author has already read their own diff, and the proof that it works is in the PR. Anything less quietly converts review time into discovery time, and discovery is the most expensive way to use a reviewer.

The Standard Expectations

#

Stripped of argument, here is what a reviewer can assume when a senior engineer opens a PR:

• CI is green on the latest commit.
• The diff does one thing; refactors and behavior changes live in their own PRs.
• Stray logs, commented-out code, and unrelated reformatting are gone.
• The author has read the full diff as a stranger would and annotated the lines that need context.
• The description answers what changed, why, and how it was tested, and points at where to look closely and what is out of scope.
• Proof that it works is in the PR: tests for new behavior, plus written manual verification when tests are impractical.
• The requested reviewers own the subsystem you are touching, not whoever is idle.

Each of these assumptions a reviewer has to re-verify by hand is attention taken away from judging the change. When one of them breaks, the reasonable response is not a comment, it is returning the PR to draft.

The Cost of a Round Trip

#

The unit of waste in review is the round trip: the author requests review, the reviewer finds a gap, comments, and the change then sits in a queue until both people are free at the same time again. One round trip costs four context switches, two per side, plus a wait for the other person’s next open slot. The reviewer switches out of their own work to read the diff and back into it after commenting, and the author later switches out of their work to address the comment and back into it after pushing the fix. Because each switch means rebuilding the mental state you had before the interruption, a gap the author could have closed in minutes costs days of calendar time. Every expectation in the standard above exists to delete one class of round trip. A green build deletes the “your build is broken” loop, a single-purpose diff deletes the “split this up” loop, an annotated self-review deletes the “what is this line for” loop, and real proof deletes the most expensive loop of all, “your tests do not cover this”, which costs a test rewrite plus a full second pass. Research on real reviews backs the self-review half of the deal: in industrial code review, most comments ask for improvements and clarifications rather than catching real defects (Bacchelli and Bird, 2013), and Google’s study of its own process treats small, fast changes as the mechanism that keeps review load sustainable (Sadowski et al., 2018). Review latency is mostly queueing, not judging, and the standard is how you stop feeding the queue.

The Handoff Contract

#

Review is a handoff, and a handoff has two sides. The author’s side is logistics: prove the change works, make it easy to read, explain why it exists. The reviewer’s side is judgment: design, correctness, and whether the code will still make sense in a year. When the author skips their half, the reviewer inherits it. A PR that forces the reviewer to reconstruct the intent is a PR that was opened too early.

The division of work looks like this:

flowchart LR
    subgraph Author["Author, before opening"]
        A1[CI green]
        A2[Self-review done]
        A3[Description written]
        A4[Proof of testing]
        A5[Small single-purpose diff]
    end
    A1 --> O[Open PR]
    A2 --> O
    A3 --> O
    A4 --> O
    A5 --> O
    O --> R["Reviewer: judgment only<br/>design, correctness, maintainability"]

Small, Single-Purpose Diffs

#

The highest-leverage habit is also the dullest one: keep the diff small. Google’s engineering practices make the case from experience, small changes get reviewed faster and more thoroughly, and reviewers miss fewer defects. Size is not the only variable though, purpose is. A senior engineer separates refactoring from behavior changes, because a diff that does two things forces the reviewer to review both at once and catch neither. If a PR needs a live walkthrough before anyone can understand it, that is usually a sign the PR is several PRs wearing a trench coat.

There are legitimate exceptions, a generated-code migration or a mechanical rename can be large and still easy to review. The mark of a senior engineer is knowing which kind of large diff they have, and saying so in the description.

Self-Review Before Anyone Else Reviews

#

Before requesting review, the author reads their own diff on the same screen the reviewer will use, the Files Changed tab, end to end. This pass has two jobs. The first is debris removal: stray logs, commented-out code, leftover debugging, unrelated reformatting that inflates the diff. The second is annotation: leaving comments on the lines that need context, “this mirrors the logic above”, “this limit matches the upstream API”, so the reviewer does not have to ask.

Self-review is also where a senior engineer catches the embarrassing stuff, and catching it yourself is the whole point of being senior. Every defect the author removes before the review is a round trip that never happened.

A Description That Answers the Obvious Questions

#

The description exists so the reviewer never has to ask questions the author could have answered in writing. The questions are predictable:

• What does this change do, and why is it needed?
• How was it tested?
• What should the reviewer look at most closely?
• What is deliberately out of scope?

Screenshots for UI changes, before-and-after output for behavior changes, and a link to the ticket all belong here. The ticket link is a pointer, not a description. A reviewer who has to read the ticket to know what the PR does has been given homework instead of a review request.

Proof That It Works

#

The author’s job is to demonstrate the change works, not to believe it works. That means tests for new behavior, updated tests for changed behavior, and a written note on manual verification when tests are impractical (“ran the migration against a copy of staging, 4.2M rows, 90 seconds”). I put this in the description under “How I tested this”. The reviewer’s job is then to audit the proof: are the tests real assertions or tautologies, do they cover the failure modes, is the manual claim plausible. An author who ships “seems to work” is asking the reviewer to do QA on a hunch, and most reviewers will price that in with a request for changes.

After You Open It

#

The standard does not end when the PR is opened. Watch CI and fix failures immediately; a PR with a red build is blocking a reviewer for nothing. Respond to comments within a day, even if the answer is “I’ll get to this Thursday”. Push fixes as commits so the reviewer can see what changed since their last pass, and say when the PR is ready for a re-review. When a comment thread passes about twenty back-and-forths, take it to a call and write the conclusion back into the PR. And when you disagree with a reviewer, either convince them, accept the change, or escalate; a senior engineer does not let a PR rot in a stalemate.

When You Cannot Meet the Standard Yet

#

The standard has legitimate exceptions, and seniority shows in running the exception protocol instead of quietly lowering the bar. Sometimes the approach is still unsettled, sometimes a change cannot be split cleanly, and sometimes you need early eyes to avoid building the wrong thing for a week. Each case has a protocol that keeps discovery on the author’s side of the handoff:

• The approach is unsettled: settle it in a short design note or issue before writing code; a paragraph of prose resolves an approach faster than three rounds of review comments on code headed for the trash.
• You need early feedback: open the PR as a draft and name the exact question and the lines that answer it, for example “design feedback on the cache interface only, ignore the internals”.
• The diff is unavoidably large: stack it, base each PR on the previous one, and keep every PR in the stack single-purpose so the reviewer can approve them in order.

flowchart TD
    Q{"Cannot meet the<br/>standard yet?"} -->|"Approach unsettled"| D["Design note or issue<br/>settle the approach first"]
    Q -->|"Early feedback needed"| E["Draft PR<br/>name the question and the lines to read"]
    Q -->|"Diff too large"| S["Stacked PRs<br/>each one single-purpose"]
    D --> R["Then open a PR<br/>that meets the standard"]
    E --> R
    S --> R

The difference between a draft and a premature PR is that the draft tells the reviewer what to look at, and what to ignore. “Is this the right approach?” is a question a reviewer can answer in five minutes. “What is this PR doing?” is homework.

Make the Standard the Default

#

None of the seven expectations should depend on memory, because memory fails on exactly the days the standard matters most, the rushed ones. Encode it once and let the system carry it:

• A PR template with the four description questions already written out.
• Format and lint gates in CI, so reformatting noise never reaches a human-reviewed diff.
• A draft-first habit: every PR is born as a draft and only flips to ready when the checklist passes.
• Reviewer assignment by code ownership, so requests route to the subsystem’s owners instead of whoever is idle.

There is a quieter reason a senior engineer holds this line. A senior engineer’s PRs are the template the rest of the team copies, because people calibrate to what actually gets merged, not to what a wiki says. The first time the team watches its most senior member ship a rushed PR to quick approvals, the written standard is dead. If you want to change how a team reviews, change what its most visible engineers ship.

What to Do Next

#

Before you click “Request review” next time, walk the seven expectations in the list above one last time, in order. Then go a step further and audit your last three merged PRs: find the expectation you break most often under deadline pressure, and encode it once, as a template line, a CI gate, or a personal checklist item. A standard you re-derive from memory every time will erode; a standard encoded in the system survives your worst week. None of this requires talent. It is the difference between treating review as a service you consume and a contract you enter, and seniority is mostly showing up on the right side of that contract.

See also

#

• Reviewing code - the reviewer-side counterpart of this piece

Code review is a human-speed step inside a pipeline that now runs at machine speed. I have gathered every reason I can find to abandon it in the age of agentic software development, and together they are stronger than any argument for keeping it.

I have argued pieces of this case before, in Rethinking Code Review in the Age of LLMs and The Future of Code Review. This article puts every reason in one place, grouped by where it comes from: throughput, cognition, reliability, sociology, and safety, plus the reasons no reform can rescue the practice.

What changed

#

A coding agent is not autocomplete. Autocomplete typed faster, and the human still wrote the code. An agent takes a ticket, plans, edits across files, runs the tests, and opens a pull request, and it can do that several times a day, in parallel with other agents doing the same. When generation becomes a machine-rate activity, every human-rate step downstream becomes the constraint, and per-diff human approval is that step. Nothing else in the pipeline caps throughput the way review does. The queue is the tell: once you supervise enough agents, review items arrive faster than you can clear them, and the surplus waits on you.

The throughput reasons

#

1. Agents parallelized generation, and review is still serial. An agent fleet works across worktrees at the same time. Human review funnels all of that output through one reader at a time. The step agents made parallel, review re-serializes.

2. The queue math guarantees collapse. Review is a queue with an arrival rate and a service rate. Agent output raises the arrival rate, and a human cannot raise the service rate by trying harder. When arrivals exceed service, the queue grows without bound, and no amount of discipline fixes it (You Cannot Out-Review a Machine by Hand).

3. Review latency destroys the value of agent speed. An agent that finishes in twenty minutes and waits a day for approval delivers in a day and twenty minutes. The machine idles at the one station that cannot speed up. Buying speed at the generation stage and giving it back at the approval stage is paying twice for nothing.

4. Review cost scales with output, and gate cost does not. Every human review is rent, paid again on every pull request, forever. A check in CI is built once, maintained occasionally, and runs on every change in between. The more the agents produce, the more the rent costs, and the more a gate saves.

5. Mandatory review converts machine failure into human exhaustion. A misconfigured agent can open hundreds of pull requests in an afternoon. If every pull request needs a human, the agent’s failure mode becomes your week. Rate-limit the pipeline, not the people reading it.

6. Human-in-the-loop approval pairs machine-rate generation with human-rate approval, and pays for both. All-human development was internally consistent: people wrote at human speed and approved at human speed, so the pipeline was slow but never mismatched. Fully autonomous development is consistent too: machines generate and gates approve, end to end. Mandatory human review glues the two together: fast cheap generation upstream, slow expensive approval downstream. The fast stage produces work that waits, and the slow stage spends senior attention clearing what waited. You pay machine prices to produce and human prices to approve, and the pipeline still delivers at human pace.

The cognitive reasons

#

7. Reviewing agent code is verification, not review. Review works when reviewer and author share a mental model, so the reviewer can build on the author’s reasoning and ask what they meant. An agent has no intent to consult, so the reviewer reconstructs meaning line by line, alone. That is not review; that is re-deriving the code from scratch with extra steps.

8. Attention collapses exactly where agents guarantee volume. Studies of real review practice put the useful band of a diff around two to four hundred changed lines, and effectiveness falls off sharply beyond it (SmartBear, “Best Kept Secrets of Peer Code Review”). Agents produce volume, and volume guarantees you live beyond the cliff. The conditions that make review worth doing are the conditions agents make impossible.

9. The diff is the wrong unit of correctness. Review inspects a slice of code. Correctness is a property of the whole system: how the change behaves under load, against real data, alongside the other changes landing the same hour. Staging and load tests approximate a few of those properties; production is where all of them show up at once.

10. Plausibility defeats skimming. Agent code is trained on human code, so it looks like code. It has the conventional structure, the familiar names, the confident test coverage. A human skim pattern-matches “looks fine” and moves on. The better the model gets, the less a skim finds, because skimming works by noticing oddity, and agents are optimized to minimize oddity.

11. Review comments no longer land anywhere. With human authors, a review comment taught the author, and the lesson compounded over years. An agent does not carry the lesson out of the pull request. The loop that actually teaches the system is the specification and the test suite, so the comment is a cost with no memory.

The reliability reasons

#

12. Defect finding was never review’s real output. When Microsoft studied its own review process, only about fifteen percent of review comments related to defects, and most of those were minor (Czerwonka, Greiler, and Tilford, “Code Reviews Do Not Find Bugs”). The bulk of the value developers reported was code improvement and awareness, not bug catching (Bacchelli & Bird, “Expectations, Outcomes, and Challenges of Modern Code Review”). The one thing review is famous for is the thing it does least.

13. Review is a sample; a gate is a census. A human reads some of the lines, once, on one Tuesday. A check runs on every line, on every run, for as long as the codebase exists. When review finds an issue, the fix is one pull request; when a gate catches a class of issue, the fix is permanent.

14. A verdict that depends on the reviewer is not a verdict. The same diff gets approved at 9 a.m. and rejected at 5 p.m., approved by one lead and nitpicked by another. CI gives the same answer every time. Process decisions that matter should not hinge on who had coffee.

15. The approve click produces the feeling of safety. Most approvals are decided by CI status, author reputation, diff size, and the description, before the code is read (You Already Review Code Without Reading It). The signature certifies that a person was present, not that the code was examined. Feeling safe and being checked are different products, and review sells the first one.

16. Accountability theater allocates blame instead of preventing harm. The approving signature exists so that, after an incident, someone can be pointed at. In practice nobody blames the reviewer; they blame the author, the tests, or the process. A mechanism whose output is blame allocation does not need to sit between your agents and production.

The sociology reasons

#

17. The social benefits had a human on both ends, and now they do not. Mentoring juniors, building trust, sharing context, softening criticism: these justified review’s cost when two humans met at the diff. An agent is not mentored by comments, does not build trust through diffs, and has no feelings to manage. The functions that made review worth its cost had a human author as their subject, and the human author is gone.

18. Review is where bikeshedding lives. Naming debates, brace placement, and abstraction preferences consume senior hours while the change waits. When output is cheap to regenerate, nitpicking the diff is the wrong loop; improve the spec and regenerate instead. Gates never argue about tabs.

19. Approval is a permission slip, and permission is the bottleneck. What review actually gates is not quality but permission to merge. When agents can produce the change in minutes, the scarce resource is the yes. Queueing the yes is pure overhead: nothing is learned there, and little is checked that CI could not check.

20. Knowledge diffusion is the one real loss, and it has cheaper substitutes. Review did spread awareness of the codebase, and I count that as the strongest argument for keeping it. But the same awareness comes from spec review, design review, ownership docs, and rotation, where people learn decisions instead of skimming one diff. Buy knowledge where it is cheap; do not price it in approvals.

The safety reasons

#

21. Production is the ground truth review pretends to be. Google’s SRE organization reports that 70% of outages are due to changes in a live system (Google, “Site Reliability Engineering”). Most of those are configuration, data, load, and integration effects that no diff-reader can see. Canary deployments, feature flags, monitoring, and tested rollback observe the real system instead of predicting it. A reviewer guesses; a canary measures.

22. Reversibility beats pre-approval. Making changes hard to make is one way to stay safe; making them cheap to undo is another. Small, independent, backward-compatible changes with tested rollback paths cap the damage of any single mistake, including mistakes no reviewer would have caught. An undo button outperforms a gatekeeper.

23. Skimming misses security; gates do not. A tired reviewer scanning a diff will not spot a subtle injection or an import that quietly resolves to a lookalike public package. Static analysis, dependency policy gates, and a dedicated adversarial agent hunting the change will, on every pull request, at machine speed.

24. If review is worth doing, delegate it to a system. A reviewer agent reads the whole repository, never tires on the fourth diff, and when it finds a class of issue, writes the gate that catches that class forever. An ad hoc human reviewer catches what they happen to notice, once. Machine review at machine speed is the only review that scales with machine generation.

Why reform does not rescue it

#

25. Every reform keeps the cost and shrinks the benefit. Checklists, review SLAs, smaller pull requests, review budgets: each trims waste at the edges and preserves the ritual at the center. The math is unchanged, because per-diff human attention cannot scale to machine-rate output. Reforming review is spending effort to keep the bottleneck comfortable instead of removing the bottleneck.

26. The judgment moves upstream, where it always belonged. Abandoning review does not mean abandoning scrutiny. It means scrutinizing specifications, acceptance criteria, gates, and the small set of irreversible, trust-boundary changes that genuinely deserve slow human reading (The Merge Gate). Review the intentions and the mechanisms; stop reviewing the output.

What to do next

#

Measure the queue first. Count agent pull requests arriving per day and the hours you actually spend reviewing. If arrivals exceed service, you have already abandoned review; you just have not admitted it in policy.

Then make the default explicit. Low blast radius changes merge on green: CI, gates, and the reviewer agent, no human click. Reserve deliberate human reading for irreversible changes, security boundaries, and the gating system itself.

Convert every catch. Each time review or production surfaces an issue, encode it as a check before moving on. The list of checks is the review process you are actually running; the queue is just where its results used to wait.

Code review was the right process for software made at human speed. Agents ended that era, and the process should end with it.

See also

#

• Rethinking Code Review in the Age of LLMs - the full-length argument that reading machine-written diffs is the wrong tool, and what to do with the hours instead.
• You Already Review Code Without Reading It - the evidence that approvals are decided by signals rather than reading, which is the premise behind reasons 15 and 16.
• The Future of Code Review - the industrial version of this case: verification factories, the five levels, and what teams already run in production.
• You Cannot Out-Review a Machine by Hand - the queue math behind reason 2, applied to any machine-generated workload.
• Verifying Code Without Reading It - the replacement system: the checks, critics, and gates that do the work review was supposed to do.
• Rolling Out the Unread Review - how to ship that replacement system to a team that does not trust it yet.
• The Merge Gate - where a human gate still earns its place once per-diff review is gone.
• The Acceptance Gap - why acceptance, not review, is the gate that matters between an agent and production.

References

#

• Wikipedia, “Code review” - the origin of formal review in Fagan’s inspections, a process designed for human authors.
• SmartBear, “Best Kept Secrets of Peer Code Review” - the 200-400 line finding behind reason 8.
• Czerwonka, Greiler, and Tilford, “Code Reviews Do Not Find Bugs” (ICSE 2015) - the measurement behind reason 12; only about fifteen percent of Microsoft review comments related to defects.
• Bacchelli and Bird, “Expectations, Outcomes, and Challenges of Modern Code Review” (ICSE 2013) - what developers expect from review versus what it delivers.
• Google, “Site Reliability Engineering” - the finding that 70% of outages come from changes in a live system, behind reason 21.
• Latent Space, “Reviews Dead” - industry reporting on teams already dropping per-diff human review.

When I work with a coding agent, most of the wall clock time goes to waiting. The agent thinks and edits, I watch the spinner, then review the result, then queue the next task, and the whole loop runs serially all day. The biggest speedup available in agentic coding is not a smarter model, it is running more of the work at the same time. Almost every real codebase carries more independent work than one session can absorb: the bug in the parser, the new endpoint, the dependency upgrade, the flaky test. The hard part is not spawning extra sessions, it is keeping them from stepping on each other, and that is a git and workflow problem before it is an AI problem.

Why One Session Is the Slow Configuration

#

A single session is not literally a queue of length one, most harnesses let you queue or steer messages that the agent consumes at its own pace. But a queued message is not parallel work: the session still executes its queue one item at a time, so task two waits while task one runs, and the agent waits while you review. The model inside the session is not the constraint, the serialization is. The progression I use goes from one branch with one task, to one branch with several non-colliding tasks, to one worktree per task, and finally to a pool of worktrees fed with more tasks than there are worktrees. Shared branches are the cheap first step, git worktrees are the mechanism that makes concurrency safe once tasks start colliding, and an orchestrator is what you add when coordination itself outgrows your attention.

The progression I climb looks like this, one rung at a time:

Share a Branch When Tasks Cannot Collide

#

The configuration you already run is one branch with one task and one session. When your tasks provably cannot collide, the cheapest upgrade is to keep that single branch and add sessions to it, each working on separate files at the same time. Nothing to merge, no duplicated environments, and the moment a session finishes, its work is already on the branch. The failure modes are just as real: two agents editing the same file silently overwrite each other on disk, an agent’s context goes stale as files change under it, and simultaneous commits race on the git index. Last writer wins, and nobody notices until tests fail for reasons neither change explains on its own.

Sharing a branch moves the isolation problem from the filesystem into your head, so only use it when the tasks provably do not touch the same files. The rules that make it work:

• Partition by module before spawning, and state each session’s file scope in its prompt.
• Prefer additive tasks: new files, new endpoints, new tests rarely collide.
• Have each session commit early and often, scoped to its own paths, and stagger commits so index operations do not race.
• If two tasks genuinely need the same file, stop pretending and serialize them.

The decision rule I use has three tiers. If two tasks share no file and no interface, they are trivially parallel, put them anywhere. If they share an interface but not files, define the interface first, then parallelize. If they share a file, serialize. Most of the bad experiences people report with parallel agents are tier violations, not tool failures.

Isolate with Git Worktrees

#

Sooner or later a shared-branch batch produces its first silent collision, and that is the signal to graduate to worktrees. A git worktree gives you several working directories that share one repository. Each worktree is a full checkout on its own branch, so two agents can edit, build, and run tests without ever seeing each other’s half-finished changes. The command line story is short:

git worktree add ../myrepo-auth-fix -b auth-fix
git worktree add ../myrepo-api -b api-endpoint

Point session one at ../myrepo-auth-fix, session two at ../myrepo-api, and they are fully isolated at the filesystem level. git worktree list shows what is checked out where, and git worktree remove cleans up when a task lands. Because all worktrees share the same object store, branches created in one are immediately visible in the others, and git only adds a little per-worktree metadata under .git/worktrees.

Worktrees are the default answer because isolation is what lets you stop thinking about collisions. You stop rationing attention across “which files is the other agent touching” and spend it on the work instead. Worktrees also outlive their first task: keep a pool of them and route the next task into whichever one just freed up, and you are running the final configuration, more tasks than worktrees. The cost is environment duplication: each worktree needs its own node_modules or virtualenv, its own build artifacts, and its own port for a dev server. I pay that cost by keeping environment setup scripted and boring, so a new worktree is ready in a minute, and by assigning port offsets per worktree. If your setup takes an hour instead of a minute, fix that first, because a slow setup will kill the parallelism on its own. The second cost arrives at integration: parallel work postpones conflicts instead of eliminating them, so keep the tasks on disjoint modules or the merge becomes the new bottleneck.

Add an Orchestrator When Coordination Becomes the Job

#

With two or three sessions, you can be the coordinator. Past that, coordination starts eating the day you were trying to save, which is Amdahl’s law applied to your own attention: the serial fraction (decomposing, assigning, integrating, deciding) eventually caps the speedup no matter how many workers you spawn. The fix is to promote coordination into a role, the orchestrator, and let it own four jobs. It decomposes the goal into a task graph and marks what can run in parallel. It assigns subtasks to worker sessions, each in its own worktree. It enforces contracts between workers, and it integrates, merging finished branches in dependency order and resolving conflicts itself.

An orchestrator earns its place not by typing faster than the workers but by owning the contracts that make parallel work safe. The contract step is the one people skip, and it is the one that matters. Before any worker starts, the orchestrator writes down the interfaces the workers will build against: the API schema, the shared types, the module boundaries, the test contract. Workers then develop against a fixed interface instead of against each other’s moving output, and integration becomes mechanical instead of investigative. Pair this with critical-path thinking (the critical path method is the old, good version): start the longest task first, because parallelism cannot shorten the chain of dependent work.

You can be the orchestrator, run a dedicated session for it, or delegate it to a planning agent that fans out work and collects results, in the pattern I described in Scaling the LLM Agent Company. I still orchestrate small batches myself, because writing the task graph is where the actual judgment lives, and judgment is the one input the cheaper workers around it cannot supply. The failure mode to watch for is an orchestrator that decomposes badly: workers then block on each other, and you pay coordination cost for serial work.

More Ways to Buy Speed

#

Worktrees and orchestration are the structural moves, but several smaller changes compound with them.

Shorten the feedback loop first. An agent iterates at the speed of your test suite, so a ten-minute suite turns every edit-test cycle into ten minutes, and no amount of parallelism fixes a slow loop. Keep a fast test subset that agents run by default, parallelize the full suite, and make lint and typecheck instant. Speed of iteration is a multiplier on every session you run.

Tell agents when to verify, not just how. An instruction file that lists the lint, typecheck, and test commands is table stakes, and one that says when to run them is worth more. Left unsupervised, a diligent agent runs the whole suite after every small edit, and on a large project that habit converts hours of work into waiting. The instruction that pays is something like “make all your edits first, then run the full check suite once before you commit, and use targeted tests only while debugging a specific failure”. Verification is a batch job at commit time, not a reflex after every change. This is a pure instruction-file change: same commands, same rigor, a fraction of the wall clock time.

Write the context down once. Every session that has to rediscover your conventions burns time you did not budget for. A good AGENTS.md or equivalent, covering layout, conventions, commands, and the “never do this” list, turns that rediscovery into a file read, and better context also means fewer wrong turns per task (The Importance of Context When Interacting with LLMs).

Warm the environments. Prebuild dependencies so a fresh worktree is functional in seconds: cached package installs, a devcontainer, or a declarative environment. The parallel workflow dies quietly when every new checkout costs an hour of setup.

Route models by task. Use the cheap, fast model for exploration, searching, and summarizing, and the strong model for design and edits. An explorer session answering questions alongside a writer session doing edits is cheap parallelism that pays immediately.

Plan before you fan out. Run a planning pass that produces the task graph before spawning workers. A graph written up front is what makes fan-out fast and integration boring, and it is the artifact you review when something goes wrong.

Supervise asynchronously. Do not watch every session. Let them run to a blocker, checkpoint their state, and batch your decisions at fixed intervals, the pattern from Managing Many Concurrent LLM Agent Sessions. Synchronous supervision caps you at one session no matter what git says is possible.

Watch the review gate. Parallel agents outproduce your review capacity fast, and then review and integration become the wall (You Are the Bottleneck). Budget for it: batch your reviews, review outcomes (tests, recordings, benchmarks) before diffs, and treat rising integration time as the signal that your task boundaries are too coarse.

Profile where the time actually goes. Agent sessions write detailed logs by default, so the raw material for a time audit is already on your disk. A tool like AgentsView indexes those session files from every harness into one local archive with usage, cost, and history analytics (my research note on agentsview covers the details). Read the report the way you would read a profiler output: find the phases that consume the most wall clock time, then ask what instruction, script, or boundary would shrink the biggest one. Long working phases point at slow test loops or oversized tasks, heavy token spend on easy work points at wrong model routing, and sessions that stall waiting for you point at supervision that should be more asynchronous. Treat your agent workflow like a hot path in code: profile it, find the biggest cost, and cut that first. The workflow improves the same way code does, by measuring before optimizing.

Advanced Strategies

#

The techniques above are the baseline for a parallel workflow. The ones below are bigger investments, and they pay off once the basics are routine and the profiling data tells you where the remaining time goes.

Race N attempts and keep the winner. For tasks that are small but hard, run two or three attempts in parallel worktrees and keep the one that passes tests or benchmarks best, discarding the rest. The losers cost tokens, the winner saves a debugging session. A cheaper variant is session forking: at a real design decision, fork the session and try both options from the same context, then keep the branch with the better result.

Close the loop from CI back to the agent. When a check fails after the agent commits, route the failure straight back to the authoring session, or to a fresh session seeded with the failure context, instead of queuing it for a human. Batch the day’s failures into one repair pass so the full suite runs once for all of them. The goal is a pipeline where a human only looks at changes that already pass everything.

Cascade models instead of routing them statically. Start each task on the cheapest model that could plausibly succeed, and escalate to a stronger one only when a signal says it failed: tests red, low confidence, or a critic flag. Static routing pays strong-model prices on every task, a cascade pays them only on the hard tail.

Make the codebase legible to agents. Every convention an agent discovers by exploration is paid again by every session, so move conventions from documentation into mechanics: lint rules instead of style guides, generators instead of templates to copy, strict types instead of tribal knowledge. Design module seams deliberately so that future parallel tasks touch disjoint files by construction. A codebase machines can navigate without asking is the multiplier that applies to every session you will ever run.

Turn frequent operations into tools. If every session hand-rolls the same shell commands to query the schema, run a migration, or deploy a preview, encode those operations once as CLI commands checked into the repo. Prefer a plain CLI over agent-specific tool protocols: every harness already speaks shell, so a command written once works in every session, every worktree, and your own terminal too.

Share one code index across sessions. A prebuilt index (LSP, ctags, or embeddings) lets sessions query the codebase instead of crawling it, and the index is built once and reused by every parallel session. Exploration is often the largest single phase in an agent session, and a shared index attacks it directly.

Run a critic alongside every writer. A reviewer agent that reads the writer’s diff as it lands catches most defects before the human gate, and you review its verdicts instead of every diff. This is how you shrink the review wall without lowering the bar: the critic applies the checklist, the human applies judgment.

Eval your workflow like you eval models. Keep a set of golden tasks for your repo, fix this bug, add this endpoint, with known-good outcomes, and score candidate models, prompts, and tools against them before adopting anything. Adopting on vibes imports regressions silently, evals catch them before they cost you weeks.

Move the runtime off your machine. Local parallelism caps out at your cores, your disk, and your patience, so run sessions in ephemeral cloud environments that can be snapshotted and restored, one warmed environment per session. This buys isolation you cannot get locally: a session restored from a clean snapshot cannot be poisoned by another session’s half-installed dependencies.

Speculate on what comes next. While work runs, an idle agent prefetches for the likely-next tasks: summarizing the module a task will touch, pre-building the target, drafting the context file. When the task starts, its context is already warm, and the startup cost drops to near zero.

The Expiry Date on This Advice

#

Everything above optimizes the machine side of the loop, and the machine side is the side getting cheaper fastest. While models are slow and expensive, parallelizing them safely pays, which is what most of this article is for. Follow the trajectory, though, and the serial fraction of the loop stops being the agent and becomes you. The agent finishes a task in minutes, turns around, and waits, not for compute but for you to decide what it should do next. Once that is the failure mode, worktrees, orchestrators, and cascades stop buying wall clock time, because the queue the agents pull from is your capacity to specify and decide, the exact shift The Shifting Bottleneck describes. I treat the playbook above as advice for the current regime, and the part that survives is the part the machines cannot accelerate: knowing what is worth building and saying it precisely.

What to Do Next

#

This week, pick three genuinely independent tasks on your codebase and run them concurrently, on your existing branch if they share no files, or one worktree per task if they do. Time two things: the environment setup per worktree, and the integration at the end. If setup dominates, script it until it does not. If integration conflicts dominate, your tasks were not independent, and the fix is in how you draw task boundaries, not in the tools. Once three concurrent sessions feel routine, write your first explicit contract before spawning workers on shared interfaces, and add an orchestrator only when coordinating them takes more of your day than deciding what they should build. In my experience two to four concurrent sessions is the sweet spot for one person, and the binding constraint past that is never the model. Adopt the advanced strategies one at a time, and only when your profiling data says the basics have stopped moving your wall clock number.

See also

#

• Managing Many Concurrent LLM Agent Sessions - the human-side supervision problem once parallel sessions exist, and the batching patterns that keep it survivable
• Scaling the LLM Agent Company - the organizational version of the orchestrator pattern, where the orchestration layer replaces human management
• Who Resolves the Merge Conflict? - where the cost of parallel agent work surfaces, at integration time
• The Importance of Context When Interacting with LLMs - why written context cuts iterations per task, the per-session complement to per-workflow parallelism
• You Are the Bottleneck - the review capacity wall that parallel agents run into downstream
• The Shifting Bottleneck - why the constraint keeps moving up the decision chain, and where this advice expires once models get fast enough
• The Agentic Development Environment Landscape - the tooling layer that hosts and coordinates these sessions
• Scaling Yourself Horizontally - the leverage framing for why replication beats working longer

References

#

• git-worktree Documentation - the git mechanism behind isolated parallel checkouts
• Claude Code: Common workflows - documents the parallel-sessions-with-worktrees practice as a mainstream workflow
• Trunk Based Development - the integration discipline that shared-branch and frequent-merge workflows sit on
• Amdahl’s law - why the serial fraction (decomposition, integration, decisions) caps the speedup from adding agents
• Critical path method - why the longest dependency chain, not the task count, sets the minimum wall clock time
• Maurice Heumann, “235 Billion Tokens Later: Auditing What The AI Agents Really Did” - a session-log audit of a production multi-agent workflow that grounds the profiling advice, the cut-the-biggest-cost findings (idle waits, CI polling, redundant test runs), and the critic-agent claim that the reviewer’s model matters more than the worker’s

Planning a feature splits into two jobs: finding out what the questions are, and answering them in an order that lets each answer build on the one before it. The two jobs reward opposite working modes, which is why running them as one activity fails. When I planned linearly, writing the requirements first and the specification next, the questions surfaced late, after the artifacts they invalidated were already written. The method I use now runs the two jobs as two distinct phases: I iterate on every artifact of a feature in parallel until the big questions surface, then I make one ordered forward pass that settles each file in the sequence the SDLC defines.

The two phases and the switch between them fit in one picture.

The directory is the feature

#

Everything I plan lives in a .sdlc/features/N-feature/ directory, one per feature. A feature starts as a problem statement in its own file, because a feature whose problem cannot be written down is not ready to be designed. Around that seed the directory grows into the full artifact set the SDLC skill defines: needs assessment, feasibility, requirements, specification, tests, and the rest.

A mature feature directory carries the full artifact set the SDLC templates define, needs assessment, requirements, existing solutions, codebase analysis, feasibility, specification, plan, tasks, tests, and a review findings file paired with each, one purpose per file. On top of that standard set sit the files of my own that hold the directory together. README.md is the overview of the feature and the guide to how the other files should be consumed, which makes it the entry point an agent reads first. files-flow.md records which files depend on which in terms of content, and it matters enough to get its own section below.

files-flow.md turns consistency into a graph

#

Many files drift. A decision that changes in the requirements silently invalidates everything downstream of it, and my memory is not a mechanism I trust to find all of it. So every feature directory carries files-flow.md, a mermaid graph of how the files depend on each other in terms of content. An edge from X to Y means Y’s content is derived from X’s content, and the rule the graph encodes is mechanical: when file X changes, every Y that depends on X gets re-verified against the new X. The graph is documentation for me and a worklist for the agent at the same time, which is the only way a consistency rule survives contact with ten interlocking artifacts.

Phase one: iterate in parallel

#

The first pass over a new feature directory is deliberately chaotic. I write the problem statement, then jump into the requirements, the specification, and the component plans all at once, in whatever order the thinking wants to happen. Writing a specification forces questions the requirements never answered, and writing a component plan forces questions the specification never answered, so working the files together is the fastest way to find the holes. Iterating in parallel is a question-finding machine: the point is not to finish any file, it is to make every file betray what I do not know while the cheapest possible response is still to write the question down. Within a few passes I have the list of risks and open questions that would otherwise have surfaced at implementation time, when each one costs an order of magnitude more to fix.

Phase two: the forward pass

#

Once the large questions have answers, I switch modes. The iteration stops and the forward pass starts: problem statement, then requirements, then specification, then the plans and tests, in the sequence the SDLC skill defines. A colleague of mine pictures the sequence as a funnel that expands as clarity about what we are building accumulates. The problem statement is the narrow end, and each artifact downstream widens it, requirements expanding the problem, the specification expanding the requirements, plans expanding the specification. Walking the funnel in order works because each file gets finished before the next one begins, so every downstream file is written against an upstream that is stable rather than half-moved. By the time the pass reaches the component plans, most of the content is transcription, because the hard decisions were made during the parallel phase. The forward pass is cheap precisely because the parallel phase paid for it.

Why two phases instead of one

#

Linear planning discovers questions at the worst possible time, after the artifacts they invalidate exist. Parallel-only iteration has the opposite failure: it keeps re-litigating every file and never converges. The two-phase split gives each mode the job it is good at, and the switch between them is a deliberate decision, not a drift. My rule for switching is simple: when another pass over the files stops producing new questions, the questions are found, and it is time to answer them in order. None of this makes the order sacred, and an unknown piece of functionality is where I stay most open about how to work. The instinct is to proceed methodically, but when an LLM can explore a design space in minutes, the smarter sequence is usually reversed: use the model first to identify the risks, surface the questions, and lay out the options, and only then backtrack and write the relevant documents in order. Exploration is nearly free, so the failure mode to avoid is premature documentation, not wasted exploration.

What to Do Next

#

If you plan features as a pile of SDLC artifacts:

• Start every feature directory with a problem statement file and a files-flow.md, before the requirements exist.
• During discovery, write all the artifacts roughly and simultaneously instead of finishing them one at a time.
• Treat “a full pass produces no new questions” as the signal to stop iterating and start the forward pass.
• When any file changes, follow the files-flow edges and re-verify every dependent file before calling the change done.

See also

#

• Three Gaps My SDLC Pipeline Hit on a Machine Learning Platform - the stress test that produced files-flow.md and the propagation rule it encodes
• Every Decision You Change Pays Once Per File - the cost model behind writing the dependency edges down instead of recalling them
• Defects Flow Downstream - why a question found during parallel iteration is cheaper than the same question found at implementation
• My AI Workflow: The Skills Are the Part That Compounds - the skills pipeline these feature directories feed
• When a Closed Decision Reopens - why every decision lives in a file, and what happens to decisions that live only in conversation

References

#

• SDLC skill - the pipeline whose artifact sequence the forward pass follows
• Mermaid - the diagram syntax files-flow.md uses, readable by both humans and agents

Every engineer I know eventually hits the same wall: the amount of valuable queued work exceeds the hours in a day. The instinct is to scale vertically, to work longer, read faster, and switch contexts harder. That direction has a hard ceiling, and the ceiling is low. When you cannot scale vertically, you scale horizontally: you build systems that do things for you. The resource everyone names as the unscalable one is attention, and I want to push on that claim, because attention is only half the story.

Scaling Vertically Ends Early

#

Scaling vertically means adding capacity to the node itself: more hours, more speed, more skill. The day has twenty-four hours, working memory holds a handful of items at once, and energy refills at a fixed rate. You can buy maybe two or three times more effective attention by sleeping properly and working in focused blocks, which is real but constant-order. No amount of discipline buys a tenth of you. Vertical scaling tops out around a factor of two; everything past that has to come from replication.

Scaling horizontally means adding nodes instead of upgrading one. A node is a system that acts on your behalf while you are absent: a check, a script, a runbook, an agent, a colleague you taught. The question stops being “how do I do more” and becomes “what can act as me without me”.

A System Is a Decision Made Once

#

The obvious move is to automate tasks, the repetitive stuff. That is the low-grade version of scaling horizontally. What you are actually doing is building systems that make decisions you would otherwise make by hand, so that each decision gets made once instead of each time. A lint rule is a preference of yours, enforced on every change. A runbook is a decision procedure captured at the moment you understood the system best. A specification is your intent, written down once and executed against many times. An agent skill is a whole procedure of yours, replayable at any hour, in any number of instances. A colleague you coach is the most expensive system of all, the only one that eventually outgrows your judgment.

Andy Grove did the accounting decades ago in High Output Management: a manager’s output is the output of their organization plus the output under their influence. The same math applies to any engineer with systems. Your output is what you produce directly plus what your systems produce in your absence.

Building systems is an old menu: teach, hire, document, automate. What changed is the cost of building one. Teaching a person takes months and produces one system that generalizes. Writing an agent skill takes an afternoon and produces unlimited instances that never generalize. Cheap narrow systems for procedures, expensive general ones for judgment, and the current game is knowing which decisions belong in a system and which must stay with you. The scheduled tasks in my own repositories already work this way: triage, review, and daily curation are systems built out of decisions I once made manually, and they do not sleep.

The Most Expensive System

#

One item on that list behaves differently from all the others. A person you coach is the most expensive system to build and the only one that eventually outgrows your judgment. Every other system can only replay decisions you already made, so none of them can tell you that you are wrong.

The economics push the cheap layers toward machines. Teaching a machine your preferences takes an afternoon; teaching a person takes months. The rote layer of teaching, conventions, procedures, mechanics, migrates to machines for the same reason generation did: the cheap system wins on cost. What cannot migrate is the point of the expensive one. A person generalizes to situations you never saw, dissents when you are wrong, and eventually holds taste decisions in your stead, and no skill file does any of the three. Teaching people does not disappear; it moves up, from transferring procedures to growing judgment.

The risk runs the other direction. Judgment grows only through contact with real problems, and apprenticeship was where most people got that contact. If everyone teaches machines their current preferences and nobody teaches people, the supply of judgment that the next generation of systems is built from depletes. Cheap systems consume the very training ground that produces the general ones.

So Does Attention Scale or Not?

#

The claim I keep hearing, including from myself, is that attention is the only resource you cannot really scale. Three answers, in increasing order of usefulness.

In quantity, no. The stock is fixed: one serial consciousness, a small working memory, a day that does not extend, and a decision pipe that handles one thing at a time (Attention Engineering covers what that means in practice).

In quality, slightly. Focus, sleep, and single-tasking buy a real multiplier over a frazzled baseline. That factor of two is worth claiming, and almost nobody has claimed it. But a constant is not a curve.

In leverage, without bound. Attention is the only resource you cannot scale in quantity, and the only one whose yield per unit is unbounded. A test attends so that you do not have to; verification substitutes for supervision. A check written once removes a minute of checking on every future use, forever. A system built this year raises the return on every hour of attention you will ever spend afterward. The attention itself does not compound. The artifacts do, and the artifacts all live outside your head.

What never scales is the deciding itself. You can multiply what a moment of attention produces, but the moment of judgment, the taste call on whether a thing is good enough, stays serial and stays yours, which is the acceptance gap restated as a scaling law. So the precise version of the claim reads: attention does not scale, and that is exactly why the work is to stop spending attention on anything a system could check.

Scaling Horizontally Fails in Four Known Ways

#

Replication looks like a free lunch, and the bill arrives on a delay.

Systems drift. Every system is a snapshot of the decisions you made when you built it, and the world moves on. The runbook rots, the skill goes stale, the gate blocks a pattern that was bad two years ago and is idiomatic now. Someone has to tend the systems, and that someone is you, the maintenance burden The Codebase Gardener describes.

Errors correlate. A flaw in a system’s decisions repeats on every execution, in every instance, at once. A thousand agents running the same flawed instruction produce a thousand instances of the same mistake, which is why consistently wrong is a worse failure mode than inconsistently right (Scaling the LLM Agent Company). At that point you are not scaling your throughput; you are scaling your error surface.

The job converts. Scale horizontally far enough and you stop being the producer and become the governor of a system of producers. Attention moves from doing the work to reviewing outputs, pruning systems, and deciding what to build next. The constraint did not disappear; it moved up to you, the textbook behavior of a system under the theory of constraints. Govern badly and you industrialize your own mistakes at a speed no hand-made error ever reached.

The source depletes. Your judgment is the raw material the systems are built from, and judgment regenerates only through contact with real problems. Automate away all the doing and you cut off the supply of experience that made your systems worth building, the terminal worry of The Shifting Bottleneck. The systems are only as good as the freshest judgment that went into them, so a slice of attention must stay spent on hands-on work even when a system could do it.

Review the Result, Not the Change

#

Code review is where misallocated attention is easiest to see, so let me be specific about it. When a change arrives, the reflex is to open the diff and read the implementation. The question that deserves your attention is not what the change looks like but what it resulted in: the failing test that now passes, the before-and-after recording, the benchmark that moved, the error rate that dropped. The implementation is how the result was produced, and the how is increasingly the machine’s business.

Concretely, this means review discussions argue about outcomes: what the change does to behavior, to latency, to failure modes, to the rollback path. Style and implementation details are preferences, and preferences belong in the gates, where they run on every change instead of when a reviewer remembers to mention them (Verifying Code Without Reading It builds the full system). Read the diff itself only when the evidence is missing or the blast radius is large, the classification The Merge Gate argues for. And when the evidence is missing, treat that absence as the review finding, rather than reconstructing the answer by reading the code.

This is how one serial consciousness survives a fleet of producers. You audit results and sample implementation, because the day you read every diff is the day the systems outproduce your review capacity (You Are the Bottleneck).

What to Do Next

#

Audit the last two weeks of your work and list every recurring manual action. Anything done three times or more is a system waiting to be built, and the order matters: gates and skills first, one-off scripts second, docs third, memory last, because the earlier items compound and memory evaporates.

Prefer systems with an oracle. Automate the checkable, where correctness can be tested mechanically. The taste decisions, whether a thing is good enough or should exist at all, have no oracle and stay yours, so give them protected time on your calendar instead of letting them be squeezed out by reviewing more output.

Spend the freed attention upstream, on specifications and on deciding what should exist at all, not on reviewing more output faster. That reallocation is the entire point of scaling horizontally, and You Are the Bottleneck is what happens when you skip it and let the systems outproduce your review capacity.

Keep a deliberate budget of attention that never gets handed to a system: the taste decisions, plus enough hands-on work to keep your judgment regenerating. You are protecting the seed stock, not being inefficient.

Then measure yourself in output per unit of attention, not in hours, tasks, or sessions spawned. The number that defines a scaling engineer is how much ships per hour of focused judgment.

You will never get more of yourself. What you can decide is how many systems run without you, how fresh their decisions stay, and what the one serial consciousness behind all of them spends its scarce attention on.

See also

#

• Attention Engineering - the tactical layer of this argument: how to allocate the fixed attention across an agent workflow instead of wasting it on generation
• The Apprentice Problem - the pipeline consequence of teaching machines instead of people: where new judgment comes from once the junior work is automated
• You Are the Bottleneck - what happens when generation scales but acceptance does not, and the contract that drains the review queue
• The Shifting Bottleneck - the pattern behind source depletion: automating a layer moves the constraint to the layer above
• Solo Is a Team Size - the seat-by-seat version of the same question: which roles need a general copy of judgment (a human) and which need a narrow one
• Scaling the LLM Agent Company - the organizational version of replication and its failure modes, correlated errors first among them
• The Codebase Gardener - the maintenance cost of these systems: why they need tending or they rot
• The Acceptance Gap - where the taste decision lives and why it stays with you when everything else has been copied

References

#

• Andy Grove, “High Output Management” (Wikipedia) - the leverage accounting: your output includes everything your organization and your influence produce
• Theory of constraints - why elevating a constraint moves it instead of removing it, the mechanism that turns a scaling engineer into a governor
• Cognitive load - the research grounding why the quantity of attention is a fixed stock

Every senior engineer I know learned the same way: by doing junior work for years. The bug fixes, the small features, the boring refactors, the reviews where someone senior tore their code apart. That work was never just output. It was the training ground where judgment formed under supervision, with real feedback, at low stakes. Automate the junior work and you do not just lose the output; you cut the input to the pipeline that produces senior engineers. Nobody announces this. The economics do it quietly, one automated task at a time.

How Judgment Actually Forms

#

Judgment is not transferred by explanation. It is grown by contact with consequences. The Dreyfus model of skill acquisition describes the path: novice, advanced beginner, competent, proficient, expert, where each step up is driven less by rules learned and more by experience absorbed. The rules are the easy part. What separates a competent engineer from an expert one is the library of felt cases, the bugs chased at 2 a.m., the refactor that made things worse, the outage traced to a decision the engineer personally made.

Apprenticeship was never ceremony. It was the delivery mechanism for consequences. A junior shipped a small change, the change broke something, and the feedback arrived fast enough to leave a mark. Small blast radius, real stakes, tight loop. Deliberate practice works the same way in every field studied: repetition at the edge of ability, with immediate feedback, is the only known mechanism that builds expertise.

The junior work being automated is not adjacent to that mechanism. It is that mechanism.

The Economics Remove Exactly the Wrong Layer

#

The uncomfortable part is that automating junior work is correct, locally. When an agent fixes the small bug in an afternoon for cents, paying a junior to spend a week on it looks like charity. No single manager makes a bad decision. Every decision is rational, and the aggregate is a pipeline with its input cut.

The pattern is familiar from The Shifting Bottleneck: automate a layer, and the constraint moves up. But this time the constraint does not just move. It starves, because the layer above was grown from the layer below.

The danger is the delay. A pipeline with no input still ships output for years, from the inventory of already-formed senior engineers. By the time the shortage is visible in hiring metrics, the training ground has been gone for a decade. The apprentice problem is a slow-motion staffing crisis that no quarterly review will catch, because the seniors are still performing.

The Same Collapse, One Level Up

#

There is a structural precedent. Model collapse in code describes what happens when models train on their own output: the tails disappear first, the average looks fine, and the distribution narrows with each generation. An organization that stops training juniors runs the same loop on people. The seniors encode their judgment into systems and agents, the next engineers learn from those systems instead of from supervised contact with reality, and what they acquire is the smoothed average of their predecessors, rounded off a little more each generation. The rare cases, the exceptions, the reasons behind the rules are exactly what does not survive the transfer, and exactly what judgment was.

I am not claiming people are models. I am claiming the loop is the same structure: output consumed as input, without fresh contact with reality, degrades in the tails first.

What Replaces the Old Apprenticeship

#

The answer is not to ban agents from junior work, that battle is over and nostalgia is not a strategy. The answer is that apprenticeship has to become deliberate now that it is no longer incidental. Three moves cover most of it.

Make juniors the supervisors, not the supervised writers. There is still a mountain of work that needs a human mind: reviewing agent output, verifying claims against evidence, catching the plausible-and-wrong. Put the junior on that mountain, with a senior reading their verdicts. The feedback loop is just as tight, judging output and being judged on the judgment, and the skill being trained is the one that actually remains scarce. The new junior work is acceptance.

Reserve work for humans on purpose. A team that assigns every task to whichever worker is cheapest has decided, implicitly, not to grow anyone. Some tasks should be reserved for the person who would learn most from them, at a productivity cost the team accepts knowingly. Software engineering teams in the age of AI makes the general case for keeping friction that pays; this is the specific friction that pays in people.

Teach judgment directly, out loud. The old pipeline taught judgment osmotically, through years of proximity. The deliberate version is faster and demands more from seniors: decision reviews, where a junior predicts the call before hearing it; postmortems walked through live, not archived; the why behind every convention made explicit instead of encoded and forgotten. Encoding your judgment into a system, the move Scaling Yourself Horizontally argues for, and transferring it to a successor are not the same act, and only one of them renews the supply.

What to Do Next

#

If you run a team, trace one recent junior-level task end to end and ask who could do it next year for the first time. If the answer is nobody, because it will be automated, you have found a hole in the pipeline, and the fix is to route the learning part of that task somewhere it still exists.

If you are early in your career, stop competing with the machines on production and compete on acceptance. Build the record of catches, verdicts that held up, errors found in output everyone else approved. That record is the new seniority.

If you are senior, pick one person and start teaching out loud this month, decisions, not syntax. The foundations are a separate argument, and Learn the Foundation, Not the Syntax makes it, but foundations without felt consequences produce competence without judgment.

The question every organization is currently answering by default is: who is allowed to become senior next? Leaving that to the economics of task assignment is how the answer becomes nobody, slowly enough that no one notices until the last senior leaves.

See also

#

• Scaling Yourself Horizontally - the upstream piece: encoding judgment into systems, and the warning that cheap systems consume the training ground that produces general judgment
• Model Collapse in Code - the same degradation loop at the corpus level, output training output, tails disappearing first
• Learn the Foundation, Not the Syntax - what to teach when production is automated: mental models of execution, cost, and failure rather than syntax
• Software Engineering Teams in the Age of AI - the team-level case for keeping friction that pays, of which training juniors is the clearest instance
• The Shifting Bottleneck - the general pattern of constraints moving up when a layer is automated, here with the twist that the upper layer starves
• The Acceptance Gap - the acceptance work that becomes the new junior training ground, generation solved and judgment remaining

References

#

• Dreyfus model of skill acquisition - the novice-to-expert progression, where advancement comes from absorbed experience rather than rules
• Deliberate practice - the research consensus that expertise builds through repetition at the edge of ability with immediate feedback
• Apprenticeship - the historical delivery mechanism for learning through supervised real work

Picture a company where every system belongs to exactly one person. No colleague reviews their changes, no meeting syncs anyone on what they built, and no second person carries the context needed to touch it. A few years ago that description would have read as negligence. Today it reads like an efficiency proposal, because agents have absorbed most of what colleagues used to contribute during implementation. The model can work, but only for companies that answer one question before adopting it: what happens when the owner goes on vacation, or quits?

Why Single-Owner Systems Are Coming

#

The economics of coordination flipped before the model did. Brooks counted it in 1975: n people create n(n-1)/2 communication channels, and every channel taxes alignment. When implementation was expensive, that tax bought reliability, because colleagues caught each other’s mistakes while catching up on context. Now agents produce the code and verification pipelines judge it, so human review of generated changes has become the lowest-leverage gate in the loop, and the specification replaces the meeting as the unit of coordination. What remains of the channel tax is mostly cost.

Against that cost, a single owner buys three things teams struggle to produce at any price. Coherence, because one taste decides every abstraction instead of a committee averaging its members. Speed, because nothing waits on sync. Accountability, because when something breaks there is exactly one person who answers for it.

This is not hypothetical. A study of the Truck Factor, the minimum number of developers who must disappear before a project stalls, found many popular open source projects already sit at one. Critical infrastructure runs on bus factor one more often than any company would admit to running production that way. The difference is that companies now have an economic reason to stop pretending otherwise and a toolset for surviving it.

The Question Hides an Assumption

#

“What if nobody else knows the system?” assumes knowledge lives in heads. For most of software history it did, because writing it down served nobody’s daily work. Documentation rotted because the only people able to maintain it were busy maintaining the system.

Agents change the cost of the alternative. Decision records, runbooks, architecture maps, and executable specifications can now be produced and refreshed continuously as a byproduct of the work itself. The fleet that builds the system keeps its own paper trail current, the same way CI keeps tests green.

The metric stops being how many heads know the system and becomes how fast a competent outsider plus their agents can re-acquire it from artifacts alone. Call it re-acquisition time. Bus factor measured the redundancy of memory. Re-acquisition time measures the recoverability of understanding.

That inversion is why the model deserves a fair hearing. A team of five who never write anything down can be harder to take over than a single owner whose repository documents itself, because five heads of unspoken context is just bus factor five with better manners.

How a Company Runs on Owners of One

#

The mechanisms are organizational, not technical.

Ownership is conditional on legibility. An owner keeps the system as long as it stays handover-ready without them. Definition of done includes the artifacts: tests that read like specifications, decision records with alternatives considered, runbooks, an architecture map that reflects reality. Agents draft and refresh these continuously, so legibility stops being a chore and becomes a property of the pipeline. Think of it as source code escrow applied to understanding rather than code: the company holds the knowledge outside the person who operates it.

Vacations are load tests. Every owner takes a mandatory uninterrupted absence each year. During it, another engineer plus their agents must handle incidents and ship one scoped change using only the artifacts, with the owner unreachable. Score the takeover and publish the time it took. The drill is chaos engineering applied to the org chart: you inject failure into the ownership layer while the stakes are a minor feature, not a resignation letter.

Redundancy spend follows blast radius. Not every internal script deserves a second person. Classify systems by blast radius and cap how much revenue-critical surface may exceed a re-acquisition threshold, say two weeks. This is portfolio management: concentrate risk where you choose, hedge where loss would be unrecoverable, and know which is which.

Succession is scheduled, not emergent. Rotate owners on a cadence so every handover gets exercised while both parties still work there. For the few systems whose takeover would hurt most, name a shadow owner who runs the vacation drill against them quarterly. The handoff paragraph from Solo Is a Team Size (what the system is, why it exists, who inherits it) becomes a required field in the service registry rather than advice for solo operators.

Incentives reward survivable systems. Promotion criteria should include “your system passed your absence”, and managers should treat “only I can touch this” as a liability, not leverage. The irreplaceable engineer is not an asset the company enjoys; it is concentrated risk the company funds. Pay people to make themselves unnecessary and indispensability stops being a career strategy.

What Still Does Not Transfer

#

Some knowledge refuses to become artifacts. Taste, the reasons the roadmap bends where it does, the history of a negotiation with a key customer: deliberation leaves traces but rarely conclusions.

Two habits keep more of it from escaping. Record rationale at decision time, while the alternatives are still alive, because a decision record written six months later is fiction. Occasionally have the owner defend direction to a peer: not the code, the choices, so judgment gets exercised against a counterparty instead of echoing inside one skull.

Then accept what remains. Some re-acquisition friction is irreducible, the same way some latency is. Budget it like depreciation rather than promising zero, and nobody gets surprised when a departure costs three weeks instead of none.

What to Do Next

#

Pick your most critical system and measure its re-acquisition time this month. Hand it to another competent engineer plus their agents with a scoped feature request and no access to the owner. Whatever number comes back is your real exposure, and it is almost certainly larger than management believes.

Set thresholds by blast radius and drill vacations against everything above them. Change one line of promotion criteria to reward owners whose systems survive their absence. And when someone next argues a system needs a second head, ask whether they mean memory redundancy, which agents and artifacts now supply cheaply, or judgment redundancy, which only a second person supplies. The first is solved; budget for the second only where the stakes are directional.

A company can run on owners of one indefinitely. What it cannot survive is letting knowledge live in only one place. People operate the systems, the artifacts are the asset, and the company’s job is to keep the asset independent of any operator, including the ones it wishes it could keep forever.

See also

#

• Solo Is a Team Size - the solo-operator limit case of this model, and the source of the handoff paragraph turned registry field here
• You Are the Bottleneck - the acceptance-evidence contract that makes a fast single producer trustworthy enough to own a system alone
• Who Maintains the Slop? - who stays attached to agent-generated code once its author moves on, the maintenance half of the ownership question
• Software Engineering Teams in the Age of AI - the team-based counterpart, covering which processes stay worth their friction when colleagues remain in the loop

References

#

• Guido Avelino et al., “A novel approach for estimating Truck Factor” - the empirical finding that many widely used projects already run at truck factor one
• Bus factor (Wikipedia) - the classic formulation of the risk this model deliberately accepts
• Source code escrow (Wikipedia) - the established practice of holding operational knowledge outside the operating party
• Frederick Brooks, “The Mythical Man-Month” (Wikipedia) - the communication-channel math that made coordination expensive and single ownership attractive