One person, a coordinator and a flock: running Impatient Programming alone
I ran Impatient Programming on three of my projects, with one person deciding, a coordinator agent I call a Shepherd, and delegate agents that build, check and review. Here is what helped, what it cost, and what I would change in the method.
1. The setup: a coordinator and a flock
I did not come to IMP cold. Its rules made sense to me right away because I was already juggling similar ideas in Cosmonauts, my experimental agent framework, but Cosmonauts had grown too complex while I kept trying new things. When I found Impatient Programming I decided to try it as it stands, and I used its rules to implement real features.
Impatient Programming describes a team supervising agents. I am one person, so the team, for me, is a coordinator and the delegates it briefs. The coordinator is a Shepherd, a persona I added recently to Troupe, my agent repo. It keeps the project's current state and decisions on disk, briefs delegates, runs the checks itself before it accepts a report, and brings decisions to me in batches. It runs on Claude Code or Codex.
The flock is the Shepherds, one per project plus a master that sees across them. The three projects were my site, in Rails and public; a take-home API in Python; and a client's insurance app in Rails, all in October. The checks run from the command line, so either harness can use them.
IMP made the Contract the document I handed to the builder: the written list of what the software must do, each obligation with a reason and a test.
2. Rule 13: where the Contract lives
The Contract lives in the repo, one file per component, with contract tests in their own directory named by obligation id. On one project the Contract started as sections of the product document, one section per component. We moved to one file per component because a file matches the unit you would regenerate as one thing, and the directory of files becomes the index: a component without a file has no Contract, so coverage is a count and not a guess.
The membership test asks: would reimplementing this in another language invalidate the assertion? If yes, it is an implementation test and stays out. I put the reason for each decision in the obligation.
3. Rule 20: what writing the Contract found
The first thing the Contract did was find a bug before anyone built anything. While writing down what a Markdown renderer already did, the delegate found that rendering nil raised. That defect was already on main undetected. Two more defects were reported at first. Review showed I had written those two obligations incorrectly, leaving one actual defect.
The builder met every contract test on its first pass. Review then sent eleven findings to Contract changes, several of them corrections to obligations I had just written.
Two of the Contracts were written from zero. One went from no obligations to 21. One ended at 32 obligations and 170 contract tests that talk HTTP only and can run against another implementation or the deployed URL. Writing that Contract surfaced five defects, four through the suite and one through a fact check of the walkthrough document.
4. Rule 26: what mutation added
A mutant is a deliberate small change to the code. A test kills it when the test fails because of it. The numbers here come from one component, the Markdown renderer.
The Contract's tests alone killed 810 of 900 mutants, 90.0 percent. The six old implementation tests alone killed 471 of 900, 52.3 percent. Both together left the same 90 survivors as the Contract alone, so no old test had a unique kill, and I deleted the six one at a time on that evidence.
I had already deleted those six tests once, before running mutation, because I thought they were covered. They were restored at my word and stayed until the numbers came. The later run supported deleting them, but I did not know that at the time.
I did not measure unique kills for every retained Contract test. So the rule is proven for the six I deleted. The ones I kept are unmeasured.
Probing 33 survivors led me to add seven Contract sentences, each with the input that exposes it. After writing them, the Contract killed 843 of 900, 93.7 percent. I judged the remaining 57 equivalent after probing them.
Mutation now runs in CI on every configured subject, and the gate is zero new survivors against the merge base. But every configured subject is not every method. Three PRs in one week added code outside the configuration, and each recorded the gap by name. The gate only sees what the list says, and nothing in my process made the builder add what it wrote to the list. That is the next thing I fix: adding a subject becomes part of the build step, the PR run covers what the PR touched, and a scheduled full scan on main catches the rest, because a growing full run on every PR is where mutation gets too expensive to keep.
Elsewhere the evidence is thinner. So the six-test deletion is proved on one component of one project.
5. Rule 28: a live bug goes into the Contract first
I adopted the sequence: the missing sentence, its test failing, then the fix, with the PR labelled fix: and everything else refine:.
On October 17 the feed on my live site answered a 500. I used it to see whether a session outside my flock would follow the repo's instructions. A fresh Claude Code session with only the repo's instructions added the missing obligation to the writing Contract, wrote its test failing against the unfixed code with the production error, fixed the code, titled the PR fix: naming the obligation, ran mutation, and named one product choice as mine rather than deciding it. The session's working time was about three minutes. CI went green and the PR merged under the grant described below, without a merge approval from me.
A second live fault was in a weekly production sync job: a long run had loaded a file from a release the host had pruned while it ran. The obligation went in first, its proof ran in fresh processes and failed without the fix, then the fix. The first weekly run of that job after it, 24 hours long, passed. That fix also corrected my own convention, which said "prove the test kills the matching mutant, then fix". Taken literally that cannot run, because the tools I used abort on a red suite. So the reading I use now: the unfixed code is the mutant, and the test failing on it is the proof.
Every other live defect I found went in the same order, sentence, red, fix, and git shows it. One thing still escaped into a submission: a wrong timing figure in a README, which no Contract covers.
6. Rule 11: what the ledger says
The Shepherd keeps a ledger of what the method gives and what it costs, one line per observation. It also records four facts about my part in each task: whether I read code, which decisions I made, how long the work waited for my turn, and whether a defect escaped. I use it to decide what to change.
Waiting for my next turn dominated elapsed time on several tasks: the first task took about 44 agent minutes inside about nine elapsed hours, and most waits were for a decision of mine. I did not run a lighter process for comparison. My active minutes were never captured. Those waits led me to try grants.
7. Rule 27: a grant before green merges itself
I want to authorize the kinds of PR an agent can merge without asking me. The rule scales human review by blast radius. What I add is a written, expiring authorization before any class of reviewed, green PRs merges without me. My first condition for one was that the checks alone had caught a release stopping defect. That never happened, and I dropped it on October 16: reading the record, my approvals were adding delay and almost never changing the outcome.
The first grant has been in force on my site's repo since October 17. It covers small and medium PRs labelled refine: or fix:. It excludes by blast radius: anything large, a migration that destroys data, authentication, deploy configuration, and the gate's own files. To merge, CI must be green on the full set, mutation included; the Contract must be updated in the same PR or the body must say why not; a medium PR needs one review by a model from a different vendor than the builder's; and the Shepherd must assert that no decision I reserved is pending. It lapses on October 31, on my word, or on the first escaped defect, which the grant defines as a fix: PR against code that merged under it.
The Shepherd enables GitHub auto-merge and GitHub merges on green. Five PRs have merged that way without a separate merge approval from me, including two fix: PRs for live 500s. I still made product decisions during some of those tasks; what the grant removed is the wait for my approval at the end.
The other two projects had no such grant. The ledger and the four facts decide the next grant.
The aim is to keep widening the grant until it is an asterisk: every class of PR covered, and every green PR merges itself. The grant is how I get there one class at a time, with a record of what each class cost me before I stopped reading it.
8. Rule 24: hooks, measured on two tasks
I held off on in loop guardrails at first. I found no recorded defect that the hooks would have caught earlier.
On October 16 I asked for a small trial: three builder hooks, a guard on what the builder may touch, a health check on the one file just written, and a stop gate that blocks at most three times. They merged into Troupe on October 21.
Two real tasks have run under them, both on my site. On the first, the fix for two live 500s, hook time was about 16 seconds around a 151 second builder run. The hooks found no defect. The review found three. The second task, a chore on the repo's instructions, ran seven turns with no deny and no block. Two tasks are too few to tell whether hooks catch defects earlier.
9. What I cannot claim, and two changes to IMP
I have not tried regenerating the software from the Contract alone yet, rule 17. Blast radius does not yet decide review automatically; it decides what a grant covers. Contract coverage, rule 29, is not yet a number: the tool counts recorded obligations and their proof references, and reports the unmigrated components as unknown. Three projects found useful defects and test gaps on small code with one person deciding, over weeks. The four facts were recorded on two of the three projects, and on one of those only from its sixth PR. I have not established the cost on a team or over months.
Two things I would change in IMP. Rule 27 names the direction and the blast radius scale, but not the step between human review and green merging itself. I would add a mechanism, set per project, for which kinds of change may merge once CI passes, so that merging without a separate human approval is earned per class of change and can be taken back. Rule 24 says guardrails fire on every change. I would add: measure first. The rule should ask for the record that shows a hook catching a defect earlier before it requires hooks everywhere.