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

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

The directory is the feature

#

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

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

files-flow.md turns consistency into a graph

#

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

Phase one: iterate in parallel

#

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

Phase two: the forward pass

#

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

Why two phases instead of one

#

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

What to Do Next

#

If you plan features as a pile of SDLC artifacts:

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

See also

#

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

References

#

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

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

Scaling Vertically Ends Early

#

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

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

A System Is a Decision Made Once

#

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

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

The leverage accounting, as I run it today, looks like this:

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

The Most Expensive System

#

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

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

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

So Does Attention Scale or Not?

#

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

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

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

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

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

Scaling Horizontally Fails in Four Known Ways

#

Replication looks free, and its costs arrive later.

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 reproduce your own mistakes at machine speed, faster than any hand-made error.

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

Review the Result, Not the Change

#

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

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

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

What to Do Next

#

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

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

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

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

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

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

See also

#

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

References

#

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

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

How Judgment Actually Forms

#

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

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

The loop the old apprenticeship closed looks like this:

flowchart TD
    X[Agent automates the junior work] -->|input cut| A[Junior ships a small change]
    A --> B[Change meets real consequences]
    B --> C[Feedback arrives fast enough to leave a mark]
    C --> D[Judgment grows a case richer]
    D -->|next task is a little harder| A

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

The Economics Remove Exactly the Wrong Layer

#

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

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

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

The Same Collapse, One Level Up

#

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

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

What Replaces the Old Apprenticeship

#

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

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

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

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

What to Do Next

#

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

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

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

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

See also

#

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

References

#

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

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

Why Single-Owner Systems Are Coming

#

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

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

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

The Question Hides an Assumption

#

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

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

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

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

How a Company Runs on Owners of One

#

The mechanisms are organizational, not technical.

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

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

The drill is a script, and it reads best written as one:

sequenceDiagram
    participant C as Company
    participant O as Owner
    participant A as Artifact set
    participant S as Successor and agents
    C->>O: Mandatory uninterrupted absence begins
    O-->>C: Unreachable for the duration
    S->>A: Handle incidents and ship one scoped change
    A-->>S: Tests, decision records, runbooks, architecture map
    S-->>C: Scored takeover
    C->>C: Publish the re-acquisition time

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

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

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

What Still Does Not Transfer

#

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

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

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

What to Do Next

#

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

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

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

See also

#

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

References

#

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

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 Report Is a Snapshot

#

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.

What Continuous Research Is

#

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.

Here is the loop as a machine:

flowchart LR
    TF[Topic file, written by you] --> L[Scheduled loop with a budget]
    CP[Checkpoint, the last researched date] --> L
    L -->|reads only the new material| U[Incremental update per run]
    U -->|advances the checkpoint| CP
    U --> KB[Versioned knowledge base]
    KB --> B[Brief, the current state]
    KB --> LG[Dated update log]
    KB --> SN[Source snapshots]
    B --> DG[Diff between versions, the weekly digest]

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.

The Knowledge Base Is the Product

#

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 follow from 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 Wiki Half Already Exists

#

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.

This Does Not Contradict Pull-Based Learning

#

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.

What Goes Wrong

#

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.

The Bottleneck Moves to Topic Selection

#

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.

What to Do Next

#

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.

See also

#

• Keeping Up With AI Is a Losing Strategy - the pull-based consumption strategy this article extends: the agent keeps up so you can consume on demand
• Loops as Files - the scheduling format a research loop is written in, including the budget frontmatter that keeps the loop affordable
• The Shifting Bottleneck - the constraint-moving pattern that puts topic selection at the top of the research stack
• Managing Many Concurrent LLM Agent Sessions - the per-run state file and digest patterns that make multiple research loops supervisable

References

#

• 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
• Anthropic, “Claude takes research to new places” - the agentic multi-search, citation-backed research model, and its scope limits per query
• Shi et al., “Deep Research: A Systematic Survey” - the four-component decomposition (planning, acquisition, memory, generation) that shows exactly where continuity is missing
• Claude Code documentation, “Scheduled tasks” - evidence that the scheduling primitive for agent loops already ships in mainstream tooling
• 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.

Your Fleet Is Already a Team

#

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.

Encode the Practices Before Adding Headcount

#

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.

When It Makes Sense to Be a Human Team

#

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.

Here is how I now run the seat decision for every opening on the team:

flowchart TD
    S[A seat to fill] --> Q1{Does the work have an oracle}
    Q1 -->|yes, correctness is checkable| A[Agent seat]
    Q1 -->|no, it is judgment| H[Human seat]
    S --> Q2{Does the context fit in one head}
    Q2 -->|yes| A
    Q2 -->|no, the product outgrew one head| H
    S --> Q3{Are the stakes affordable and reversible}
    Q3 -->|yes| A
    Q3 -->|no, a one-way door| H

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 the seat decision 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.

What to Do Next

#

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 applies, 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.

See also

#

• Software Engineering Teams in the Age of AI - the design of the small human team that remains once seats are filled for dissent instead of hands
• The Prompt Is the Source Code - the specification as the management artifact of an agent fleet, the first practice a solo operator imports
• You Are the Bottleneck - the review contract that turns acceptance from opinion into check, and the queue math once generation is cheap
• Who Resolves the Merge Conflict? - the oracle versus no-oracle split inside a single pull request, the same line that decides human versus agent seats
• Who Maintains the Slop? - the ownership question for generated code: who stays attached after the fleet produces it

References

#

• Fred Brooks, “The Mythical Man-Month” (Wikipedia) - the channel-counting math that human seats must now pay for against agent seats that coordinate at near-zero cost
• Google re:Work, “Guide: Understand team effectiveness” - Project Aristotle’s finding that psychological safety, the capacity for dissent, is the top predictor of team performance
• Groupthink (Wikipedia) - what absent dissent does to group decisions, the dynamic a solo fleet embodies when no seat is assigned to it

OpenChamber 1.19.0 was released today, which makes this a good moment to take stock. I have used it almost daily since February 8. Along the way I have opened 99 issues, and since April 16 I have had 29 pull requests merged. I am still using it every day not because it is polished, but because its core loop is worth the friction, and because when the friction gets bad enough, I can fix it myself.

What I use it for

#

OpenChamber is an app built around OpenCode: sessions, worktrees, chat, files, and terminals in one surface. My usage is narrow and deep. I run multiple agent sessions in parallel against the same repositories, and I let OpenChamber own the worktree management. Each session gets its own checkout and its own branch, and I steer all of them from one place. Six months of this setup adds up to roughly 2,430 sessions across 61 projects, 54,000 messages, and 3.8 billion tokens, on models that moved from GLM 4.7 to GLM 5.3.

Because OpenChamber is always open, it also works as a scratchpad. When a thought hits, I switch to the right project, write down a few lines, and let a session have a go at it. The 99 issues I mentioned were mostly built that way: I describe the problem, and the session turns it into a detailed issue, sometimes with a follow-up comment containing code investigation. An idea that would have died as a passing annoyance becomes an artifact, within minutes, inside the same window.

Input is also drifting away from the keyboard. I use Handy, a speech-to-text tool, more and more to talk to the agent, which speeds up iteration. And sometimes it is simply how the work continues while my hands are full, eating.

Iterating on ideas got a lot faster once trying a third approach meant spawning one more session instead of doing the stash-and-switch dance by hand. That single property is why I adopted OpenChamber and why I have not stopped. It is also the last part I would give up.

The reliability tax

#

The hardest part of these six months has been that the chat, the one component whose entire job is to hold a long-running conversation, was sometimes unreliable. The causes were varied. Sending a message to a session whose worktree was still being created blocked until the post-creation commands finished, so a message sent at the wrong moment just sat there. At other times the connection between OpenChamber and OpenCode dropped, and a few breakages were regressions in OpenCode itself that surfaced downstream in OpenChamber.

The text editor had its own stretch of problems. It glitched, and it regularly refused to open files it decided were outside the workspace or project, even when they were not. Both classes of problems got addressed over the months.

What still bothers me

#

My main gripe today is the terminal implementation. Terminal sessions end up closed on their own, which is exactly the failure mode a tool like this should never have, because a terminal holds state you cannot reconstruct. On Linux, opening the terminal sidebar sometimes shows nothing at all, and the workaround is creating another terminal.

The editing experience is my other daily friction. The early glitching got fixed, but typing and file navigation in the built-in editor remain clunky next to VS Code. OpenChamber also ships as a VS Code extension, which I have never tried, because the point of OpenChamber for me is steering agents from one surface, not living in two. The practical cost is that I keep an editor open to review diffs before commits and to look at code from time to time, which is exactly the habit I should be trying to break.

Two smaller issues have simply persisted for months. Project selection and filtering in dropdowns remain weak across the app. And the file matcher behind the @ helper is still really bad, which is annoying in a tool where pointing an agent at the right file is a core interaction.

Fixing it yourself changes the math

#

This is where the 29 pull requests matter. A bug in a closed tool is a wall: you file it, you wait, and meanwhile you work around it. A bug in an open tool you already run every day is just a task, and the more it bothers you, the faster it jumps your queue. My 99 issues and 29 merged pull requests are the same friction recorded twice, once as a complaint and once as a fix.

Merging is the part I control least. Getting a pull request adopted in the main repository sometimes takes real effort, and some of mine are still sitting open. Since I find those changes useful regardless, I maintain a local branch where I apply my unmerged pull requests and run ahead of upstream. The tool I use daily is therefore slightly my own build: official releases plus the fixes I was not willing to wait for. It is a small patch queue, the same idea as a distro carrying packages ahead of upstream, and it comes with the same obligation to rebase and drop patches once they land for real.

The path a fix takes from annoyance to the build I actually run looks like this:

flowchart LR
    F[Friction in daily use] --> I[Issue filed]
    I --> P[Pull request opened]
    P -->|merged upstream| U[Official release]
    P -->|still open| B[Local patch branch]
    B -->|rebased and dropped once upstream lands| U

The relationship with the tool changes as well. I am no longer only a user deciding whether to stay or leave. I am a stakeholder: when a release like 1.19.0 ships with fixes from a handful of outside contributors, I read the notes looking for my corners of the app. That is a much better position than complaining in an issue tracker.

Should you use it

#

If you run one agent at a time in a terminal, you probably do not need OpenChamber yet. If you juggle several agents against the same repositories, parallel sessions plus automatic worktree management alone justify the setup cost, and idea iteration gets visibly faster. Go in expecting rough edges. Then check whether the edge that would bother you most is one you are willing to fix yourself, because that question decides what kind of experience you will have.

See also

#

• My AI Workflow - where OpenChamber sits in my overall setup and why the skills are the part that compounds
• Managing Many Concurrent LLM Agent Sessions - the supervision problem that running parallel sessions creates
• Verifying Code Without Reading It - the argument behind the diff-reading habit I should be breaking

References

#

• OpenChamber - the repository I have been using and contributing to
• OpenChamber 1.19.0 release notes - the release that prompted this retrospective
• OpenCode - the coding agent OpenChamber is built around
• git worktree - the mechanism behind per-session isolation

A counterparty who uses LLMs to generate changes, documents, and requests has a throughput you cannot match by hand. If they then forbid you from using LLMs to review that same work, they have not raised the quality bar; they have rigged the queue. You will fall behind, and the falling behind is the point.

The Setup

#

The pattern is specific. On their side, a model drafts the pricing changes, the proposals, the redlines, the spec revisions, the follow-up questions, faster and in greater volume than any human would produce alone. On your side, the same work arrives as items to read, reconcile, and answer. And somewhere in the engagement letter, the process doc, or the spoken rule, there is a line: review must be human, no AI.

The asymmetry is not accidental. One side of the pipeline is unbounded. The other is capped at the speed of a single person reading.

The rigged pipeline looks like this:

The Math Is the Problem

#

Review is a queue. Items arrive at the producer’s production rate and leave at your review rate. If production rate exceeds review rate, which it must when one side uses a model and the other does not, the queue grows without bound.

The only tool that could lift your review rate to match is the one being banned. A model can triage a hundred documents, flag the three that matter, and summarize the rest in the time it takes you to open the first one. That is exactly the capacity the rule removes from your side. Forbid the reviewer’s LLM and you have not protected quality; you have guaranteed the reviewer loses the race.

This is not a question of effort or discipline. No amount of reading faster, staying later, or caring more will close a gap between a human’s reading speed and a machine’s generation speed. The two rates are different categories.

The Rule Is Never Applied to Production

#

Every time I ask what justifies the rule, I get the same reasons. Quality. Confidentiality. “I want a real human looking at this.” Trust.

None of those reasons are applied to the producer. If quality required a human, the producer’s output would be human-written too. If confidentiality forbade a model, it would forbid the model on both sides. A rule that binds only the reviewer is not a rule about quality; it is a rule about leverage.

The tell is the asymmetry itself. A counterparty who genuinely believed human attention was the safeguard would insist on it for the work they send you, not only for the work you send back. When the standard runs in one direction, the standard is a tactic.

Flood Is an Old Tactic; LLMs Made It Cheap

#

Overwhelming a reviewer with volume is one of the oldest leverage moves in negotiation and review. Bury the clause, exhaust the reader, let fatigue do the accepting. It used to cost real effort to produce that volume, which capped the abuse.

LLMs removed the cap. Producing fifty variations, fifty justifications, and fifty follow-up questions now costs minutes and cents. The producer can flood at marginal cost while demanding the reviewer meet each item with marginal human effort. That is not a process; it is a denial-of-service on your attention, presented as a quality standard.

What Review Becomes on a Flood

#

Once the queue exceeds what a human can read carefully, the review degrades in one of two directions, and both favor the producer.

You triage, skimming for flags, and the unflagged majority passes unread. Or you tire, and you rubber-stamp. Either way, the work ships with less scrutiny than a smaller, human-paced batch would have received. The flood does not get reviewed more rigorously for being human-reviewed; it gets reviewed less, because humans have a finite attention budget and the producer is spending it for them.

The irony is precise. The rule meant to guarantee careful human review is the rule that guarantees there is not enough human attention to go around.

Push Back on the Symmetry

#

The fix is not to read faster. It is to refuse the asymmetric pipeline.

If they produce with a model, you triage with one, or the queue is illegitimate. Say it out loud, early, before the volume arrives. A review process is only fair when both sides have comparable tools on the queue.

Make the producer carry the cost of their own volume. Require a summary with every batch, written by them, stating what changed and what it means. Require structured, machine-checkable submissions instead of free-form documents. Cap the intake per day the way you would cap any rate-limited service. If the volume is genuine, the producer can absorb the cost of making it reviewable; if it is tactical, the requirement exposes the tactic.

And if the rule forbidding your LLM is non-negotiable, name it for what it is. It is a one-sided throttle, and agreeing to it is agreeing to lose on the schedule.

The Principle

#

Review is not a virtue test. It is a throughput match between two sides of a pipeline. Whoever sets the tooling asymmetry sets the outcome, and a reviewer forbidden the only tool that matches the production rate has already lost.

See also

#

• Keeping Up With AI Is a Losing Strategy - the same production-versus-consumption asymmetry, applied to reading the field; this piece applies it to a single adversarial counterparty
• Rethinking Code Review in the Age of LLMs - why line-by-line review of machine-generated work is low-leverage, the exact assumption the flood-and-forbid tactic exploits
• The Acceptance Gap - why “produced” is not “accepted”; the gap is precisely where a flood-and-forbid tactic hides items you never truly reviewed
• The Shifting Bottleneck - the constraint-moving pattern; here the bottleneck is deliberately pinned on the reviewer and frozen there

References

#

• Information overload - the long-standing name for the underlying problem, here weaponized rather than accidental
• Denial-of-service attack - grounds the metaphor: exhaust a finite resource (reviewer attention) by overwhelming it with cheap requests

Your coworker opens pull requests faster than you can read them. Every morning the queue is longer than when you left. Their work piles up behind your name, and everyone can see whose approval is missing. You are not the bottleneck. The process that routes every change through one human reader is the bottleneck, and no amount of reading faster will fix it.

The setup is now ordinary. More than one in five code reviews on GitHub already involve an agent, and a developer driving an LLM can open ten plausible pull requests in the time it takes you to properly review two. The gap between arrival and departure is not a temporary spike. The gap is the new steady state, and it needs a structural answer from both sides of the queue.

The Math Ends Badly on Its Own

#

Review is a queue. Changes arrive at your coworker’s production rate and leave at your review rate. When arrival exceeds service, the queue grows without bound, which is the whole story of your inbox.

The failure is one queue with a single server:

The instinctive response is to raise your service rate: read faster, review longer hours, take fewer breaks. Queueing theory says why that response fails even when it works. Kingman’s formula says that waiting time grows with variability divided by spare capacity, so as your utilization approaches one hundred percent, waits explode nonlinearly. A reviewer at eighty percent capacity has a manageable queue. The same reviewer at ninety-seven percent, which is what “keeping up” actually demands, has waits measured in days. A process that only functions when you are never tired, never in a meeting, and never sick is not a process; it is a countdown.

There is a second failure hiding behind the first. An overloaded reviewer does not stop reviewing, the reviewer degrades first. You skim. You approve what the tests already cover. You rubber-stamp the fourth pull request of the evening. The queue does not just grow, it silently stops protecting anything, because code merged by a rubber stamp feels reviewed without being reviewed. Rubber-stamped merges are worse than a visible backlog: the backlog at least admits the work is not being checked.

The Reframe

#

The useful lens here is the theory of constraints. A system’s throughput is set by its constraint, and the prescribed moves are to exploit the constraint (spend constraint time only on work only the constraint can do), elevate the constraint (add capacity or automation), and subordinate everything else to the constraint (upstream steps keep the constraint fed with work worth its time).

Read that list again with names attached. The constraint is you. Exploiting the constraint means your reading time goes only to changes that genuinely need human judgment. Elevating the constraint means automated gates absorb what does not need your eyes. Subordinating to the constraint means your coworker’s job changes: keep the queue full of cheap-to-judge, high-value changes instead of merely full.

Guilt is the wrong response to being the constraint, and so is heroics. Bottleneck is a role in a system, not a verdict on a person, and roles can be redesigned. The question stops being “how do I review faster” and becomes “what should be allowed to arrive at this queue at all, and how should the queue drain”.

What Your Coworker Should Do

#

When generation is cheap, producing more changes is trivial and producing mergeable changes is the actual work. Your coworker’s job is no longer to produce changes; the job is to produce changes that are cheap to say yes to.

Measure time-to-merge, not pull requests opened. A pull request that sits for a week is not output, it is inventory, and inventory that waits long enough rots into rebase conflicts and stale specs.

Concretely, every pull request should arrive with four things.

A specification written before the code. Acceptance criteria that existed before generation started, not a description reverse-engineered from the diff afterward. Reviewing a plan takes minutes; reviewing an unexplained implementation takes an hour, and the plan is where your disagreement is cheap.

Evidence that the change works. A failing test turned green by the fix, a before-and-after recording, a benchmark. A fix is not fixed until something independent of the model says so, which is the acceptance gap in miniature. Evidence converts your review from “verify by hand” to “check the verification”, and those tasks differ by an order of magnitude in cost.

An annotation of the risk. A self-review pass that flags the dangerous hunks, states the blast radius, and says which parts the coworker is unsure about. The risk annotation is the single highest-leverage habit of the four, because it tells you where your scarce attention belongs and proves a human actually read the output before demanding that you do.

A summary that enables a thirty-second judgment. What changed, why, what could break, how to roll it back.

Beyond per-PR discipline, two structural commitments matter more.

Respect a work-in-progress limit. At most two or three open pull requests at a time. When the cap is reached, the surplus capacity goes to writing tests, improving gates, and sharpening the next spec, not to opening a fourth PR that will age out in the queue. The most productive use of a fast producer’s spare time is reducing the review burden itself: gates, encoded conventions, and tooling that make every future change cheaper to judge, not just the producer’s own.

Stay attached after merge. Bugs in generated code route back to the generator for a window of time, because the person who captured the benefit of fast production should carry the first round of the cost.

What You Should Do

#

Your side of the contract is to stop being a per-diff reader and become the designer of how the queue drains.

Classify instead of read. A README typo and a schema migration are both pull requests and do not need the same gate. Compute blast radius and reversibility per change, auto-merge the low-risk class on green, and hold only the risky minority for human eyes. The majority of a flood is routine, and routine work is what machines are for.

Encode your recurring comments. Every review comment you have written more than twice is a gate you have not built yet. Complexity limits, dead code detection, coverage thresholds, forbidden dependency classes. Each encoded check is a category of attention you never spend again, and a category of queue pressure that disappears permanently.

Move your attention upstream. Review the spec before the code is generated, not the diff after. Ten minutes on a plan prevents an hour on a wrong implementation, and your disagreement lands while it still costs a conversation instead of a rework.

Match your coworker’s tools. Your coworker generates with a model; you triage with one. Running a first-pass review that flags anomalies, summarizes each diff, and ranks the queue by risk is not cheating, it is symmetrical. A pipeline where one side is machine-accelerated and the other is capped at human reading speed is broken by construction, whether the asymmetry is malicious or accidental.

Batch reviews into fixed windows. Two scheduled review blocks a day, instead of interrupt-driven approval sessions. Predictable service beats heroic bursts because Kingman’s formula punishes variability itself, and every interruption you remove shrinks the waits more than the raw time saved suggests.

Make the queue visible. Arrival rate versus service rate, time-to-merge, queue depth, on a dashboard both of you see. Numbers turn a feels-bad conversation (“you are slow”, “you flood me”) into an engineering conversation (“our arrival rate is triple our service rate, so we change one of them”).

What You Agree On Together

#

The fix is a contract, not a truce.

Define merge-ready: the checklist a pull request satisfies before it even enters your queue. Set the WIP limit at your sustainable service rate, and treat the limit as the throttle that keeps arrival below service. Agree on the escalation path for the small set of changes (the irreversible ones, the trust-boundary ones) that deserve synchronous human attention while your coworker waits. Agree on where surplus producer capacity goes when the queue is full, because idle generation capacity pointed at more PRs is how the problem restarts.

Then change what you both measure. The unit of team output is merged changes, not opened pull requests, and every metric that rewards opening over merging rebuilds the queue you just dismantled.

What to Do Next

#

Tomorrow, your coworker attaches the four things (spec, evidence, risk annotation, summary) to every new pull request, and you classify the existing backlog into auto-merge-gate versus needs-my-eyes, resolving nothing yet, just sorting.

This week, set the WIP limit and move your two most-repeated review comments into CI.

This month, make spec review the meeting that replaced diff review, and put time-to-merge on the dashboard next to queue depth.

The queue was never a verdict on how fast you read. The queue is a design decision your team made without noticing, and a decision made by accident can be made on purpose.

See also

#

• You Cannot Out-Review a Machine by Hand - the same queue math in its adversarial form, where the tooling asymmetry is deliberate rather than accidental
• The Merge Gate - how to classify changes by blast radius so only the risky minority needs a human approval
• Rethinking Code Review in the Age of LLMs - the case that judgment belongs upstream in specifications and gates rather than downstream in diffs
• The Acceptance Gap - what counts as independent evidence that a change works, the evidence your coworker should attach to every pull request
• Who Maintains the Slop? - why the generator must stay attached to the code after it merges, the ownership window this article’s contract requires

References

#

• Kingman’s formula - the queueing result that explains why waits explode as utilization approaches one hundred percent
• Theory of constraints - the exploit, elevate, subordinate framework applied to the reviewer as the constraint
• Queueing theory - the general study of arrival and service rates, the model underneath the review queue
• GitHub Blog, “Agent pull requests are everywhere” - the data showing agent-generated pull requests are already a large fraction of reviews

A skill file is not done when it ships. The first version of a SKILL.md is a hypothesis: that this sequence of steps, sent to a model, will produce the result you want. Hypotheses get tested every time the agent runs, and most hypotheses fail in small ways you only notice on the fifth or tenth run. A skill is a depreciating asset, and the only thing that keeps it paying off is a deliberate loop you run on it after it ships: notice the failure, explain what happened to a fresh agent session, iterate with the agent on a patch, verify the patch, and periodically shrink the whole library back down.

The rest of this piece is that loop, in the order I run it.

Why skills decay

#

Three forces pull at a skill from the day you write it, and any one of them is enough to make a good skill go stale.

The model changes underneath it. A skill that was necessary to spell out every step for last year’s model is over-specified for this year’s model, and the over-specification starts to fight the model instead of helping it.

The task drifts. The repo layout moves, the tool’s CLI changes, the team’s convention evolves, and the skill keeps calling the old path.

And your own understanding improves. Six months after writing the skill, you know a shorter, cleaner way to express the same instruction, but the file still holds the first, clunkier version.

A skill that nobody touches is a skill that is quietly getting worse, because the world around it is not standing still.

Keeping Up With AI Is a Losing Strategy makes the same argument about filters: the asset you built at the last model generation may be miscalibrated for the current generation, and you will not notice because the failure is silent. Skills fail silently the same way. The agent still produces output. The output is just a little more wrong, a little more verbose, a little more off, and you compensate for the drift in your head without ever feeding the fix back into the file.

The loop

#

I run the same five-step loop on every skill, whether I noticed a failure today or I am doing a monthly sweep. The order matters, because each step is cheap only if the previous step ran.

My part of the loop is the noticing and the judgment. The diagnosing and the patching belong to the agent, and the split is the point: I explain, the agent analyzes, and the skill gets fixed without me becoming the bottleneck the loop exists to remove.

The cycle, and the split of labor inside it, looks like this.

flowchart LR
    S1[1. Notice the failure] -->|correction becomes a session| S2[2. Fresh session diagnoses]
    S2 -->|diagnosis picks the patch| S3[3. Iterate to a small patch]
    S3 -->|patch the skill, not the output| S4[4. Verify against the failed run]
    S4 -->|still failing| S1
    S4 -->|periodic sweep| S5[5. Shrink or delete]
    S5 -->|model catches up| S1

1. Notice the failure

#

A skill only improves when one of its failures gets explained, and most failures never get explained.

The default behavior after a bad run is to fix the output by hand, move on, and forget the skill was ever wrong. The hand fix is the failure mode, because the next run will produce the same bad output the same way, and you will apply another hand fix.

I do not keep failure notes, and I do not stop to work out what went wrong. When the agent produces something I have to correct, I open a new agent session and explain what happened: the bad output, what I expected instead, and which skill produced the run. The explanation is the whole capture. Explaining takes a minute, needs no template, and the session holds the failure so my head does not have to.

The rule is simple: if I had to correct the output, the skill has to hear about the correction.

The rule is the encoding loop from My AI Workflow turned outward. There, the rule was that every time I caught myself remembering to do something, the reminder became a skill. Here, the rule is that every time I catch myself correcting the agent, the correction becomes a session about the skill that produced the output. Both rules turn a private, forgettable moment into a durable, improvable artifact.

2. Explain it to a fresh session

#

The session has to be new, and the newness is doing real work. The session that produced the bad output is the worst investigator of the bad output, because the agent in that session is attached to the reasoning that went wrong. A fresh session reads the skill the way a new maintainer would, with no stake in the run that failed.

My message states what happened, not why. The bad output, what I expected instead, and anything about the run that surprised me. Then I let the session read the skill and tell me what went wrong, and the diagnosis lands on one of a handful of causes.

The skill was missing context the model needed. It referenced a file that was not in scope, or assumed a convention that was never stated.

The skill was over-specified. It pinned a step-by-step recipe that the current model does better on its own, and the pin is now producing worse output than letting go.

The skill was ambiguous. Two reasonable readings of the same instruction exist, and the model picked the wrong reading.

The skill called the wrong tool, or called the right tool the wrong way.

Or the failure was not the skill at all. The model was weaker than the skill assumed, the input was bad, or I asked for the wrong thing.

The diagnosis matters because each cause gets a different patch. Missing context gets added. Over-specification gets cut. Ambiguity gets rewritten with one clear reading. A wrong tool call gets corrected. And a failure that is not the skill’s fault gets parked, not patched, because editing a skill to compensate for a bad input is how skills accumulate defensive cruft they do not need.

Most skill decay is over-specification, not under-specification, and the instinct to add more instructions is usually wrong. The model is almost always more capable than the day the skill was written, and the smallest patch that fixes the failure class is very often a deletion.

3. Iterate to a patch

#

The agent writes the patch, and I iterate with the agent until the patch is right. My job in the session is judgment, not authorship: keep the patch aimed at the failure class, and keep the patch small.

The patch edits the SKILL.md, not the output.

The discipline is to patch the failure class, not the failing instance. A patch that fixes one bad run without addressing the kind of bad run is a patch that will be re-applied, in a different form, to the next bad run, and to the bad run after that. The skill accumulates special cases and never gets cleaner.

Each iteration should end with a smaller diff, not a bigger one. Add the one missing piece of context. Rewrite the one ambiguous sentence. Delete the step the model now does on its own. A small patch is easy to review and easy to revert if the patch makes things worse; a large patch that tries to fix the skill end to end is almost always a sign the diagnosis was incomplete.

The patch is also where the skill gets shorter, not just longer. If the session cannot make the failing skill better without also making the skill longer, the session is probably patching a symptom.

4. Verify

#

A patched skill is another hypothesis, and a hypothesis that is not tested is a guess.

The cheapest verification is to re-run the skill against the run that failed, and to read the new output for the specific problem the session was asked to fix. If the explanation captured the failure well, the check takes a minute.

For skills whose output can render, the pattern from Teach Your Agent Skills to Use Tools That Render pays for itself here. A skill that emits a diagram, a table, or a diff is a skill I can verify by looking, and looking stays cheap when reading the prose would bury me. A skill that emits only paragraphs is a skill I can only verify by reading, and reading is the bottleneck that started the whole problem.

For skills that touch code, the verification runs the project’s own checks. The linter, the type checker, the test suite. The skill does not need its own separate verification when the repository already runs these checks, the same way The Codebase Gardener leans on objective signals from the tools rather than on a human re-reading every diff.

A skill without a verification step is a skill that drifts back to broken the moment you stop looking.

5. Shrink or delete

#

Shrink-or-delete is the step most people skip, and also the step that matters most over the long run.

Every skill is a bet that the model cannot do the task reliably on its own. The models keep getting better. The bet that was correct when the skill was written is incorrect now for some percentage of the library, and that percentage grows every model generation.

When a skill’s failures have stopped, and the agent produces the right output from a prompt alone, the skill no longer justifies the cost of keeping it. The skill is scaffolding around a capability the model now holds on its own, and the right move is to take the scaffolding down, not maintain the skill.

My AI Workflow makes the same argument: the skills are a temporary scaffold for the gap between what the model can do today and what the model will do on its own tomorrow, and a good chunk of the work is knowing which scaffold to take down next.

Shrinking applies within a single skill too. A step that the model now does reliably on its own is a step that should leave. An instruction that only existed to work around an old model limitation is an instruction whose time is up. A skill that has not been shortened in six months is almost certainly carrying dead weight from a weaker model generation.

Deletion is not loss. Deletion is the most positive outcome a skill can have, because deletion means the model grew into the capability the skill was propping up.

The review sweep

#

One failure at a time is too slow a pace to keep a library healthy, the same way one pull request at a time is too slow a pace to keep a codebase clean.

I run a periodic sweep over the whole library, the same way The Codebase Gardener describes raking a codebase instead of chasing every leaf. The sweep is a small set of questions asked of every skill, not the deep rewrite of any one skill.

Which skills have I not edited in three months? Skills untouched for three months are the most likely to have decayed, because the world moved and the skill did not.

Which skills reference files, tools, or paths that no longer exist? Broken references are the cheapest bug to find and fix.

Which skills overlap with each other? Two skills that do almost the same thing should become one, because the duplication will drift and one will go stale while the other gets maintained.

Which skills did I not run at all this month? A skill that is never invoked is either redundant or forgotten, and both states are reasons to consider deletion.

Which skills did I run but correct every time? Skills that need correcting every run are the candidates for the next session.

A sweep takes an hour and pays for a quarter, because each finding is an iteration the per-failure loop would have taken months to surface.

Skills about skills

#

The loop has a recursive quality worth naming, because the recursion is where the compounding really lives.

The act of iterating on a skill is itself a repeatable task, and repeatable tasks become skills. I run a review-skills pass that does the sweep described above. I run an improve-skill pass that takes a single skill and proposes high-value, low-risk patches to the skill. The failure session from step 2 is the same move, held by hand: I supply the failure and the judgment, the agent supplies the analysis and the patch.

The recursion is the real multiplier. Once the iteration loop is itself a skill, the library improves itself at the pace the agent can run, not the pace I can read. I still make the calls, because deciding which patch lands and which skill gets deleted is a judgment the model does not yet make well. But the surface I have to hold in my head shrinks every time an iteration step is encoded, and the part I do myself narrows to the calls that genuinely need judgment.

The end state matches what The Self-Evolving Repository describes for codebases, applied one layer up: a library of skills that observes its own failures, proposes its own patches, and shrinks itself as the model grows, with the human left only at the checkpoint that needs taste.

What to Do Next

#

Pick one skill you have already run more than five times. Find the last run where you corrected the output. Open a new agent session, paste the bad output, and explain what you expected instead. You have just run steps 1 and 2 of the loop.

Then let the session read the skill and propose the diagnosis: missing context, over-specification, ambiguity, or the wrong tool call. Push the session until the patch is small and makes the skill shorter, and re-run the skill against the run that failed. You have just run steps 3 and 4.

If you cannot remember the last time a skill failed, you are either very lucky or, more likely, you have stopped noticing. Run a sweep instead. Open every skill, ask when the skill was last edited, and assume anything over three months old has decayed. You will be right more often than not.

And every quarter, ask which skills you can delete. The library that only grows is the library that is losing, because the library is carrying scaffolding for problems the model has already solved.

The goal is not a large library. The goal is a small library that is exactly the size of the gap between the model and the work, and a library that shrinks every time the model catches up.

See also

#

• My AI Workflow: The Skills Are the Part That Compounds - the case that skills are the durable asset, and the encoding loop this piece turns outward onto the skills themselves
• Teach Your Agent Skills to Use Tools That Render - the verification step of the loop, made cheap by rendering output instead of writing more prose
• The Codebase Gardener - the sweep pattern, applied there to a codebase and here to the skill library
• The Self-Evolving Repository - the end state when the iteration loop on skills is itself automated
• Keeping Up With AI Is a Losing Strategy - the argument that any filter built at one model generation must be re-audited, which is exactly what the skill sweep does

References

#

• tomzx/agents - the skills library this loop is run against, including the review-skills and improve-skill passes that operationalize the sweep and the patch
• Agent Skills format - the open skill format that makes each skill small enough to iterate on independently