A refactor is the job you most want to hand to coding agents and least want to trust them with: every change is a chance to break something that worked.
On 17 October 2026 we refactored Clawdline with Clawdline, on one machine, in one day. About two dozen Claude Code Sessions did the work. One person made the decisions. The agents did not need to be trusted, because no agent ever approved its own work.
The first plan was rejected, and it should have been
The day started with an architecture review: six read-only Sessions each read one part of our own code. The coordinating Session turned the worst-looking findings into five Board items.
The person read the first item and rejected all five of its steps. The reason was short: nobody would notice the difference. The plan was ranked by how wrong the code looked, not by what it cost anybody.
The person then set the criteria themselves: how fast the daemon runs, and how many places the same logic is written in. Every proposal now needed a number, and the first one changed the plan. Nearly half of the daemon’s own CPU went to rebuilding a frozen list of 817 tasks every two seconds. Those tasks belonged to an app that had been retired a month earlier.
One Board item per goal, one step per landing
The work lived on the Board: one item per goal, such as remove the code and data nothing uses, with a list of steps under it. Each step was small enough to review in one sitting and to undo with one revert.
Three Board rules mattered that day:
- An item does not start implementing without acceptance criteria. The coordinating Session forgot them once, and the Board refused to move the item until they existed.
- A Plan cannot be claimed by an agent. Turning a Plan into work, or cancelling an item, is an action the person takes on the Board. Scope stayed with the person, because no agent could change it.
- A step is done when it is verified, not when it is written. Its commit has to be on
main, and the person has to sign off.
The Session that writes the code never reviews it
Each step went through the same pipeline. Every Session in it had a built-in role and its own private checkout.
| Role | What it did | What it could write |
|---|---|---|
| Coordinator (the architect role) | Checked facts against the code, wrote each brief, merged, installed, measured | Only it could merge to main |
| Implementer (backend, performance or minimal-change role) | Made one step’s change and ran the focused tests | Only the paths it declared up front |
| Reviewer (code-reviewer role) | Read the diff and reran the checks in a throwaway checkout | Nothing |
| Test writer (test-automation role) | Wrote tests that pin the current behaviour before anything changes | Test files only |
| The person | Set scope, chose the irreversible steps, ran the end-to-end checks | — |
That day used 12 implementer Sessions, 10 reviewers, one audit and one measurement run. Each implementer notified the coordinator when it finished. Implementers that wrote the same files ran one after the other; read-only work ran in parallel.
Reviewers found what the tests could not
The reviews changed what shipped, because each finding named the file and line the reviewer had checked.
One reviewer found that a change could stop the phone’s Session list from updating for up to four minutes while the phone was still connected. The tests passed because none of them covered a connected phone that the relay had briefly counted as gone. The fix went in before the merge.
Another reviewer checked a guard test by writing eight ways to get around it. The guard caught none of them. A third reviewer saw that an equivalence test never exercised the incremental path on its own. A green test is only evidence once you have seen it go red. For each fix, a Session made the bad change on purpose and confirmed the new test failed before trusting it. Once, the first attempt put the bad change in the wrong place, and the test stayed green.
Every landing was installed and measured before the next one
After each merge, the coordinating Session installed a dev build on the same machine. It backed up the database before any step that changed stored data. It then measured the daemon again.
The person was out most of the afternoon, so the end-to-end checks became one list of eight items
for their return. Nothing reached main on an agent’s word alone. A reviewer’s
verdict, a green local check and an install that started cleanly all came first.
Mistakes were caught by somebody other than the Session that made them
The squad did make mistakes. The worst was ours. The coordinating Session moved an old configuration folder to the Trash. That folder still held credentials that scheduled jobs from another project were reading. A Session working on that project noticed its job failing. It put the files back and sent the coordinator a message. No person was involved.
Twice, the problem came from elsewhere. The interface switched to English because another
Session’s copy contained a menu path the daemon’s text validator rejected; a test now catches that
before a commit. Later, a push was refused because CI on main was red. The coordinator reran the
failing test locally and reran only the failed job, and pushed once both were green.
What Clawdline gave us that a terminal full of agents would not
The person spent the day on decisions, not on supervision. Breaking the work down, implementing, reviewing, merging, installing and measuring were all done by Sessions.
- Scope stayed with the person. The Board let agents plan and execute, but only the person could turn a Plan into work or cancel it.
- Work kept moving while nobody watched. The person was out all afternoon. The Board held each step’s state, finished Sessions notified the coordinator, and every landing left a record.
- Every change had a second reader and a number. That is why a day’s work could delete 4,383 lines and cut CPU to a tenth without the person reading every diff.
The workflows guide covers dispatch, review and landing in order. Why “done” has four meanings explains the landing check, and work you can cancel covers how a dispatched Session can be stopped early. Round two: bugs reported from a phone.