Engineering / AI

Week Four: The Autopilot Started Maintaining Itself

189 pull requests opened, 163 merged, and hands-free merges rose to 31% while the reviewer got stricter, not looser. Throughput halved, which taught me the week's real lesson: an autonomous coder is bounded by its backlog, not its capacity.

Givi Pataridze · Jul 27, 2026 · 7 min read

This is the third post about Autopilot, the system where AI agents pick issues off a board, implement them, fix their own CI, argue with an adversarial AI reviewer, and merge while I sleep. The first post told the story. The second delivered the numbers readers asked for, and ended with a testable claim: the fully autonomous merge rate, then 21%, would grow, because the gates would get deeper rather than looser.

A week later I owe you the verdict on my own prediction. Then I need to tell you what the system did to my job this week, because it was not subtle.

The scoreboard, week over week

Same methodology as last time: every autopilot PR carries a label, all numbers come from the GitHub API, and you could reproduce them with one gh command.

Lifetime, four weeks in production: 189 pull requests opened, 163 merged.

This week against last week:

And one number I did not expect to be writing about: two days this week the system shipped nothing at all.

The bottleneck moved into my chair

Throughput halved, 97 PRs down to 47. The system did not get slower, dumber, or more cautious. It ran out of work.

I spent this week building the system instead of feeding it. Fewer issues written, fewer epics broken down, and on two days the sweep sessions polled the board, found nothing ready, and correctly did nothing. An autonomous coder is demand-constrained, not supply-constrained. Capacity stopped being the limiting factor the moment the loop closed; now the limiting factor is how fast one human can decide what should exist and write it down clearly enough to be buildable.

This is the honest counterweight to every scary claim about autonomous coding, including mine. The machine does not invent product. It amplifies a backlog. An empty backlog amplifies to nothing, and a vague backlog amplifies to confident nonsense with excellent test coverage. Deciding what to build was always the hard part; the autopilot just removed everything that used to hide that.

Escalations grew, and that was the design working

Sixteen PRs carried the needs-human label this week, up from six, alongside 7 new escalation issues the agents filed for me. That looks like regression until you read what they are.

Almost every one is a restricted path: CI workflow files, IAM roles, DNS credentials, secrets provisioning, deploy configuration. This week's work happened to be infrastructure-heavy (a custom-domain epic that touches DNS providers, certificates, and CI), so a larger share of diffs landed in exactly the territory where the deterministic policy layer refuses to let any AI approve anything, no matter how confident the reviewer feels. The system also keeps filing tickets on me for things it is not allowed to touch: provision this secret, apply this IAM grant, confirm this prod rollout.

Four weeks in, the pattern from last week has only sharpened. The machine escalates at the boundary of its permissions, almost never at the boundary of its competence. I have become a person who processes tickets filed by his own software, and every one of those tickets is something I would never have delegated anyway.

The week the system took over its own operations

Now the real story. Every previous post described a system that autonomously changes product code. This week, most of the changes were the system operating itself.

It deploys its own updates now. The receiver gained a daily self-updater: it picks the latest tagged release, enters a maintenance window, waits for live agent sessions to drain, runs its own migrations, restarts, and verifies its own health before declaring success. I used to be the person who updated the machine that ships the code. That job existed for exactly three weeks before being automated away like everything else.

Naturally, the updater immediately walked into the two most classic self-update bugs in the genre, and I am contractually obliged by this series to report them. First, I had just put the operator dashboard behind Basic Auth, so the updater's health probe started receiving auth challenges and concluded the freshly updated receiver was dead. Protecting the system broke the system's ability to know it was alive. Second, the update script originally ran from inside the very git checkout it was updating, meaning a pull could swap the script's own code out from under it mid-run. It now copies itself to a temp location before touching anything, like every self-updating program eventually learns to. The garbage collector that collected nothing has worthy successors.

The dashboard became a control plane. Config changes hot-reload from the panel without a restart. New work can be filed straight from a web form, which means the backlog no longer requires knowing the CLI, or anything about how the system works at all. There is a per-project countdown to the next sweep and a structured report of what the last sweep decided and why. What started as a six-column status table three weeks ago is now the cockpit the name Autopilot always implied.

Autonomy climbed from PRs to features. Until now the unit of autonomous work was one issue, one PR. This week the epic flow landed: sub-issues merge into a shared epic integration branch, each sub-PR auto-merging under a consent I grant once for the whole epic, sub-issues close themselves as their pieces land, and when the last one is in, the system finalizes the epic branch for promotion on its own. I used to approve features one PR at a time. Now I approve a feature once, at the start.

Releases got their own reviewer. Repos now declare branch roles, and a PR promoting dev to prod is classified at webhook time and reviewed with a dedicated release review rather than a code review, with a guard that catches PRs pointed at the wrong base entirely. The scariest merge in any repo, the one that ships everything at once, finally has a review process that understands it is not a feature diff.

And the reviewer is no longer married to the coder's vendor. The reviewer identity is now configurable per project: Claude, Codex, Gemini, or Kimi, each with its own model and settings. This matters beyond flexibility. When the same model family writes and reviews the code, they can share blind spots, the same training data producing the same confident mistake twice, once in the diff and once in the approval. Cross-vendor review is monoculture insurance: the author and its adversary can now come from different lineages. I know of large human organizations that have not figured this out for their own review culture.

What is left of me

Tallying the series so far: post one, I stopped being the clipboard between GitHub and a model. Post two, I stopped being the person who starts the machine each morning. This week I stopped being the person who deploys it, updates it, merges its sub-PRs, and translates requests into its intake format.

What remains is a short list with sharp edges: write the backlog, answer the permission-boundary tickets, read the release reviews, and own whatever escapes. Four weeks of data say the list is still shrinking, but its last items are not automation targets. They are the job.

The fraction will keep growing. The backlog is refilled. And somewhere in the next few days, the system will update itself, note the new version in its own dashboard, and get back to work without telling me. I find that I have stopped finding that strange, which might be the most honest metric in this whole post.

ai-agentsclaude-codeautomationgithub

Enjoyed this? Get the next one.

Get new posts delivered to your inbox.

Subscribe

Get new posts delivered to your inbox.