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.
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.
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.
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.
Figure 1: the split. Each area gets its own three-person rotation over half the services, and the other area’s primary is the escalation target.
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.
Figure 2: the cadence trade-off side by side, and the deciding variable: how heavy a single shift is.
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.
Figure 3: context freshness across the rotation cycle. The 6-week whole-system cycle crosses the action threshold before every shift; the 3-week half-system cycle refreshes before that happens.
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.
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.
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.
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.
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 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.
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"]
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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”.
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.
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.
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.
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.
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).
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.
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
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.
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 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.
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.
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.
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.
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
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?
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.
“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.
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.
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.
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.
Deep research agents changed who does the reading, not how often it happens.
You type a question, the agent browses for up to half an hour, you receive a cited report.
Then the world moves, and the report starts decaying on the day it was written.
Ask the same question next month and the agent starts from zero, with no memory of what it already told you.
The report was never the product. The product is a knowledge base that stays current, and the way to get one is to put research on a loop.
I call this continuous research: declare the topics you care about, schedule an agent to re-research them on a cadence, and let it maintain a versioned knowledge base whose updates you read like diffs.
The human stops being the researcher and becomes the editor of a small research department that never sleeps.
The current wave of research agents is genuinely good at the finding part.
ChatGPT’s Deep Research autonomously browses the web for five to thirty minutes per query and returns a structured, cited report.
Claude’s Research runs multiple searches that build on each other and explores angles you did not ask for.
A recent survey of deep research systems formalizes what these tools do into four components: query planning, information acquisition, memory management, and answer generation.
What the survey’s framing makes visible is where the continuity breaks.
Query planning, acquisition, and generation all live and die inside a single run.
The only component that could span runs, memory management, is scoped to the session.
These products treat memory as scratch space for finishing one answer, not as the durable asset.
So the structure of the interaction is: one question in, one report out, everything forgotten.
The run lengths are capped in minutes and the queries are metered by the month, because a long autonomous browse is expensive.
The output is a document, and a document is a snapshot.
None of this is a flaw in the tools.
It is a flaw in the unit of work.
A report answers a question once, but most questions that matter to your work are recurring, and recurring questions deserve a maintained answer, not a fresh one every time.
The definition I use: continuous research is a scheduled agent loop that incrementally maintains a versioned knowledge base about topics you have declared, so that your current understanding is a system property rather than an activity.
Four pieces, each of which already exists on its own.
The first is the topic file.
One markdown file per topic stating the scope, the questions worth answering, the canonical sources, and what a meaningful change would look like.
This is an editorial artifact, written by you, and it is the part that encodes taste.
It is the same move as a skill file: the judgment goes in a file, versioned, rather than in a prompt you retype.
The second is the loop.
A schedule, a budget, and a skill that knows how to research one topic, in the format Loops as Files describes.
The scheduling primitive is no longer exotic: coding agents can already be run on a schedule, and a GitHub Actions cron or an agent runtime does the rest.
The third is the incremental update.
Each run advances a checkpoint, the last date the topic was researched, and the agent reads only what is new since that date.
arXiv monitoring works exactly this way: fetch what appeared since the last processed date, summarize, advance the checkpoint.
This is what separates continuous research from naively re-running a deep research query every week: the run is a delta against a base, not a rebuild from scratch.
The fourth is the knowledge base itself, which is the product the other three pieces serve.
A continuous research knowledge base is a directory per topic, in git, containing three kinds of files.
A brief, rewritten each run, holding the current state of understanding.
A log of dated updates, so the history of the topic is readable as a timeline.
Snapshots of the sources, so every claim in the brief can be traced to the page it came from, even if that page moves or dies.
The properties fall out of the format.
The brief answers “what is true now”, the log answers “what changed”, and the diff between the last two versions of the brief is your weekly digest, generated as a byproduct rather than assembled by hand.
The git log of the knowledge base becomes the changelog of your own understanding.
I keep the research directories of this blog in this form, agent-written briefs with per-topic folders and source snapshots, and the pattern is the same one behind my public specification workspace, where a weekly drift check re-derives specifications for open-source projects I depend on from their upstream code and commits the diff.
That workspace is a continuous research system pointed at code repositories instead of the web, and it has held up well enough to recommend the pattern in general.
The comparison worth making is to continuous integration.
A one-shot research report is a local build: correct at a moment, unverified the next day.
Continuous research is CI for knowledge: the build runs on every tick, and breakage, meaning drift between your knowledge base and the world, shows up as a diff instead of as a surprise in a meeting.
The LLM-maintained knowledge base now has a name and a following.
Andrej Karpathy’s LLM Wiki idea file, published in April 2026, describes the same shift from deriving to maintaining: instead of a retrieval layer that reassembles knowledge from raw chunks on every question, the agent incrementally builds and maintains a persistent wiki of interlinked markdown pages.
His architecture has three layers: immutable raw sources, an LLM-owned wiki, and a schema file that tells the agent the conventions to follow.
The schema is my topic file under another name, and his append-only log matches the update log my knowledge base layout uses, which suggests these choices are convergent rather than arbitrary.
The part of his framing worth keeping is the economics: humans abandon wikis because the maintenance burden grows faster than the value, and the LLM is the first maintainer that does not get bored.
He traces the pattern back to Vannevar Bush’s Memex, where the unsolved part was exactly who would do the maintenance.
What the idea file leaves out is the clock.
The wiki’s operations fire when you fire them: you drop a source, the agent ingests it; you ask a question, the agent answers and files the answer back.
The wiki compounds, but only when you feed it.
Continuous research is the same artifact with the human trigger removed: the loop finds the new sources on a schedule, advances the checkpoint, and ingest stops being a thing you remember to do.
The implementation side is converging too.
llm-wiki, a plugin for Claude Code, Codex, and OpenCode built on the pattern, ships parallel research runs, a librarian pass that scores articles for staleness, and an audit that traces outputs back to raw sources.
Even there the runs are invocation-driven: the librarian can tell you the wiki has gone stale, but a human still decides to refresh it, and watched-source variants are being worked out in the idea file’s comment thread.
The wiki gives research a place to accumulate, and the loop gives it a reason to stay current; neither half works alone.
In Keeping Up With AI Is a Losing Strategy I argued that you should consume information on demand, when a real task requires it, instead of on a schedule driven by fear.
Continuous research does not reverse that position.
It removes the reason the position was painful.
The asymmetry that made keeping up impossible was that production compounds while your reading speed does not.
Continuous research moves the consumption to a system whose reading speed does scale.
The agent keeps up so that you can consume on demand.
Your behavior barely changes.
When a task arrives that touches a topic you track, you open the brief and read the current state, prepared in advance by something that reads at machine speed.
You are still pulling.
What changed is that the thing you pull from is your curated, current base instead of the raw web on a deadline.
The reading you do take on is bounded and small: the weekly diff, a screen or two of what actually moved.
That is a digest you would pay for, and here it is a free byproduct of the loop.
The failure modes are the ones every autonomous system grows, plus one that is specific to durable documents.
A hallucination filed into the knowledge base is worse than one in a chat window.
A wrong claim in a conversation scrolls away.
A wrong claim in a maintained document accumulates authority every day it survives, and every later run that reads the brief inherits it.
The defenses are mechanical: every claim carries a link, every link is verified by the run that writes it, sources are snapshotted, and anything you intend to act on gets spot-checked by you.
OpenAI itself warns that deep research outputs hallucinate, and outside reviewers note that verifying a generated analysis can itself take hours; in a continuous system that verification is amortized across runs and spent on the diff, not the whole report.
Topic rot.
A topic file written last year encodes last year’s questions.
The tracker keeps diligently researching things you no longer care about, because caring is not an event the scheduler can see.
The defense is treating the topic list like a backlog: prune it on a schedule, and treat a brief you have not read the diff of in a month as a candidate for deletion.
Hoarding.
A knowledge base that grows faster than you read it is procrastination with extra steps.
The question to ask is blunt: what is the value of keeping a knowledge base whose content you never consume?
None, because the value of the base is realized when you read it, not when the agent maintains it.
An unread topic is all cost, compute, diff noise, and the illusion of being informed.
If the diff sits unread for four consecutive weeks, the topic is not informing decisions and should be cut, exactly the discipline a reading funnel demands.
Cost runaway.
An autonomous web-browsing loop on a timer is a direct line from “it seemed useful” to a surprising invoice.
The budget belongs in the loop’s frontmatter, with a cap on runs per day and cost per run, and the runtime should enforce it rather than warn about it.
This is the same argument as the budget field in Loops as Files, with the stakes unchanged.
Once the finding, reading, and filing are automated, the constraint moves, in the way The Shifting Bottleneck describes for every other layer agents absorb.
Deciding what to track becomes the bottleneck, and it is the most human layer of the whole stack.
A topic file is a small statement of identity: these are the questions I need current answers to, these are the sources I trust.
That is editorial judgment, and it is the part that compounds.
The agent will never be better than your topic file at knowing what matters to you, which means the file deserves the same care you would give a skill you plan to run for years.
The practical corollary: start with topics that inform decisions you actually make, where staleness has recently cost you something.
Tracking “large language models” is unusably broad and will produce mush.
Tracking “context window pricing across providers, monthly” produces a brief you will open before every infrastructure decision.
Pick one topic that decays quickly and that a real, recurring decision depends on.
Write its topic file: scope, questions, canonical sources, and what a meaningful change looks like.
Create the directory, with a brief, a log, and a snapshots folder, and seed the brief with one deep research run you verify by hand.
Schedule a weekly loop with a budget, and have each run advance the checkpoint, update the brief, and commit the diff.
Read only the diff.
Then leave it alone for a month.
If the diffs were worth the minute they took to read, add the second topic.
If they were not, the experiment cost you one directory and a few dollars of API spend, and you learned where your real information needs are, more cheaply than any course could have taught you.
The goal is not a bigger pile of reports.
The goal is never having to research anything from zero again.
ChatGPT Deep Research - what one-shot deep research concretely is: autonomous 5-30 minute browsing runs, monthly query quotas, and the vendor’s own hallucination warnings
Karpathy, “LLM Wiki” - the idea file that named the artifact half of the pattern: compile knowledge once into an LLM-maintained wiki, plus the maintenance-economics argument
llm-wiki - a productionized version of the LLM Wiki pattern for Claude Code, Codex, and OpenCode, including the librarian staleness pass and provenance audit
Wikipedia, “Memex” - Vannevar Bush’s 1945 vision of a personal, curated knowledge store, the pattern’s oldest ancestor
arXiv usage statistics - the production side of the asymmetry: why one-shot research cannot keep up with the volume of new material
One person directing a fleet of agents now produces more working software in a week than a small team produced a decade ago.
Every alignment meeting, every argument about conventions, every wait for a review starts to look like pure overhead.
The question I ask myself is whether working in a team still makes sense at all.
The question assumes that going solo means leaving teams behind.
It does not.
A solo operator running a fleet of agents is already working in a team, one human and N machines, with assignments, reviews, conventions, and all the coordination that implies.
The real question is not team or no team.
The real question is when a seat at that table should be filled by a human.
What would I actually do all day if I went solo?
I would write specifications, which are prompts, and delegate them, which is task assignment.
I would review what comes back, request changes, and resolve conflicts between agents working on the same files.
I would maintain conventions that every agent must follow and correct the ones that drift.
That is not a person quietly coding alone.
That is a team lead doing team lead work for a team that happens to be made of agents.
Now audit which functions this team already covers, and which have no seat assigned.
Execution is fully covered.
Agents turn a specification into working changes, at any hour, at any scale.
Give the fleet my worst idea and it returns that idea implemented fluently, with tests, in minutes.
That is the fleet doing its job well; reviewing the idea was never its job.
Direction would have a single seat, mine, and execution would treat whatever leaves that seat as settled, which is exactly what execution should do.
The same property appears in prose, as What the Author Brings When the Model Writes observes: the model can produce anything, which is why the deciding is separate from the producing.
The reasons behind past decisions would live in one head, mine.
The agents would hold exactly the conventions I encode, and the why would survive only if I wrote it down, which would make the whole operation one node until the records make it more.
The node does not need to fail dramatically.
The node just needs to take a vacation.
And the review of my own direction would run through the same head that chose it.
My errors would pass my own review at a rate that should terrify anyone who has reread their own writing a day later.
The overhead I would escape by going solo is the delivery mechanism for direction review, shared memory, and second eyes.
It would not disappear; it would convert into gaps that surface later and cost more.
The first move is not to hire.
The first move is to import the team practices that make any team function, because applied to a fleet they are what make solo work at scale.
Write the specification before the code, because the prompt is the source code, and the fleet executes the specification it is given, no more and no less.
Encode conventions as gates and skill files that execute on every change instead of review comments that depend on someone remembering to say them, the move The Codebase Gardener argues for and Bringing Everyone to the Same Level describes as institutional memory that runs itself.
Demand evidence with every delivery, a failing test turned green, a recording, a benchmark, so that acceptance stops being a matter of opinion and starts being a check, the contract You Are the Bottleneck asks of any fast producer.
Write decisions down, one paragraph each, so the why survives outside your head.
A fleet with specs, gates, evidence, and records is a team with a functioning culture.
Most of what made teams feel like overhead was the delivery cost of these four things, and agents let you pay that cost once, in code, instead of forever, in meetings.
Now the original question can be asked precisely: when does a seat need a human?
Brooks made the accounting fifty years ago: n people create n(n-1)/2 communication channels, and every channel taxes alignment.
The economics changed.
An agent seat executes without needing alignment and pays no channel tax; a human seat pays the full tax and must contribute enough direction, memory, and accountability to cover it.
A human seat has to earn its place against near-free, and it earns it in the three roles the fleet does not perform.
Three conditions cover most of the cases.
The work has no oracle.
An agent can verify against a check: tests that pass, a spec that matches, a conflict with a mechanical resolution.
When correctness is machine-checkable, fill the seat with an agent and sleep well.
When the work is direction, intent, or taste, when the question is whether the thing should exist, there is no oracle, only judgment.
An agent executes the plan it is given; a human can question the plan itself.
Who Resolves the Merge Conflict? draws the same line inside a single pull request: mechanical conflicts go to the bot, semantic ones need someone who holds intent.
The context exceeds one head.
A real product accumulates more surface than any single person holds, and past some size the single node becomes the constraint no matter how fast the fleet executes.
A second head is replication: another copy of the why, the failure modes, and the customer reality, which is why the node can finally take a vacation.
Below that size, the second head mostly duplicates what you already know, and the channel tax buys little.
The stakes need a counterparty.
Some decisions are irreversible or expensive enough that one confident brain, machine-amplified, should not make them alone.
A name beside yours on the decision is not ceremony; it is a second signature on the one-way doors, and it is also what accountability requires when something eventually breaks.
Accountability is a role agents do not hold: an agent executes, and a person answers for what was decided.
Ownership has no seat.
Add the three conditions together and the sum is ownership: deciding what the work is, remembering why it exists, and answering for it.
In a company, ownership survives the owner: when someone is away or leaves, the work is reassigned, and someone else takes responsibility for keeping it functioning.
The company is the container that keeps ownership continuous; individuals are stewards who hold it for a while and pass it on.
A solo setup has no container.
The owner and the person are the same thing, so absence does not reassign the work; it orphans it.
The fleet keeps executing, patches, deploys, alerts handled, but execution is not ownership.
A system can keep running and still be abandoned, because ownership means someone answers for it, and no agent holds that role.
The partial answers are all transfer artifacts.
Decision records, runbooks, and specifications make the why inheritable, so a successor can pick the work up without the owner’s head.
Opening the source turns the community into a container of last resort.
Naming an inheritor, even informally, converts the orphan case into a handoff waiting to happen.
None of these fully solves it.
Ownership continuity for the solo operator is still an open problem, and pretending the fleet solves it is how systems get abandoned while they are still green.
Notice what this does to hiring logic.
Teams used to add humans for hands, and hands are now near-free, so the remaining reasons to add a human are direction, memory, and accountability.
Google’s Project Aristotle found that the strongest predictor of human team effectiveness is psychological safety, which is precisely the capacity for dissent to occur.
The finding reads as a warning here: a human seat without safety produces agreement instead of judgment, and agreement is a contribution the fleet already supplies.
And the solo fleet is the limiting case, groupthink with an n of one, a team where dissent holds no seat at all.
The human team that remains is therefore small, three to five people owning a domain end to end as Software Engineering Teams in the Age of AI argues, but the staffing question inverts.
Do not ask how much the candidate can produce.
Ask where the candidate will disagree with you, and whether that disagreement will be right often enough to pay its channel tax.
If you run a fleet, or are weighing one, audit it as a team this week.
Trace the path your worst current idea would take through it, station by station, and count the places where the plan itself can be challenged.
If the count is zero, you have found the gap, and it is in the design, not in the agents.
Then decide deliberately where judgment enters.
If your work has an oracle, is reversible, and fits in one head, stay solo and stop feeling guilty about it; the fleet plus encoded process is a real team.
If any of the three conditions bites, no oracle, context overflow, one-way doors, buy a human seat in whatever dose makes sense: a paid reviewer for the consequential changes, a community that will tell you the idea is bad while it is still cheap to kill, a co-founder for the direction itself.
For everything you own, write the handoff paragraph: what it is, why it exists, who inherits it.
The paragraph converts ownership from a property of your presence into an artifact, the same move as every other practice in this piece, and it is the closest thing solo work currently has to succession.
And if you build a team, staff it for the disagreements.
You were never choosing between working alone and working with people; you were deciding, seat by seat, what each kind of worker is for.
Agents are for the work.
Humans are for the judgment that decides what the work is for.
Google SRE Book, “Being On-Call” - the standard that on-call quality is a designed property, including page load limits and post-shift recovery.
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.
