The merge button grew an engine.
VS Code 1.136 describes Agent Merge as a preview that asks an agent to address review feedback, fix failed checks and merge conflicts, rerun workflows, and repeat until the pull request is ready to merge. The release does not say the agent silently presses the final merge button, and this garage will not blur that line. The important change is one step earlier: closure is now a persistent process, not a single suggestion.
The same release makes agent work easier to route across complicated cockpits. Multi-root workspace support is experimental; related chats sit in a hierarchy; rows expose status and pending approvals; notifications jump back to the session that needs attention. Even workspace-name resolution refuses to guess when names collide. Those are not decorative details. They are signs that the scarce resource is shifting from generation to supervision.
The loop should absorb toil, not dissolve authorship.
“Ready” has at least four witnesses.
A green test run proves that one configured proof path passed on one revision. Resolved comments prove that conversations were marked resolved. A clean merge base proves the patch can be applied. None of those alone proves the change is understandable, wanted, operable, or worth carrying next year.
So split the dashboard. Give the machine exact lanes for review feedback, CI, conflicts, and reruns. Then give the human a different job: inspect the changed behavior, the unresolved uncertainty, the rollback path, and the product claim. The human is not there to cosplay as a slower linter. The human is there because the repository cannot decide what the organization should mean.
Institutionalize the useful lap.
Benedict Evans argues that cheap tool creation does not remove the hard parts of change: discovering the right problem, coordinating across systems and people, and moving an improvised workflow into something with audit, security, maintenance, and accountability. That frame fits agent merge loops perfectly. A one-off bot fix is improvisation. A loop touching every pull request is infrastructure.
Once the loop is infrastructure, its contract belongs in the repository. Set the maximum repair laps. State which failures permit another autonomous attempt. Record the diff between laps. Escalate oscillation instead of hiding it. Require a compact handoff that says what changed, what passed, what remains uncertain, and who owns the final call.
Readable work is a control surface.
Bryan Cantrill’s “revolt of the reader” is about public prose and reader trust, not pull requests. The useful bridge is narrower: people recoil when they cannot tell what is real, who did the intellectual work, or whether the named author even read the output. A pull request can create the same trust debt when the machine leaves a wall of confident closure and no accountable summary.
Do not turn authorship into theater. If an agent did the repair laps, say so. If a maintainer inspected only the final delta, say that too. The handoff should be short enough to read and specific enough to challenge. Logs are evidence storage; the receipt is the map.
The garage policy.
- Cap the loop. A repeating failure is a signal, not permission to spend forever.
- Diff every lap. Keep the reason, changed files, checks run, and new failure state.
- Escalate oscillation. If a fix reopens an earlier failure, stop and hand back the wheel.
- Separate green from good. CI closure and merge cleanliness are machine witnesses; product fit and comprehension remain named decisions.
- Print the handoff. One readable receipt should point into the deeper logs without requiring archaeology.