When most commits are written with an agent, the lead's work changes in kind. The lead writes less: they decide, set the rules, and check.
On the platform where I work, that has been the case since 2026. What is missing then is not speed: it is a frame. This note says which one, and presents the tool that holds part of it: gwm, written by my colleague Kylian Bardini.
Written rules
An agent does not guess what a team takes for granted. The rules that matter are written down, and not negotiable: what is never done, and why.
They are written to be read by the agent and by a new colleague alike. A rule a newcomer would not understand, the agent will apply badly.
A role per agent
An agent that does everything does everything by halves. One agent hunts silent failures, the ones that raise no error; another reviews. Each has its brief, and its work is judged on what it finds.
A workspace per agent
Several agents working in the same folder step on each other. Git has the answer in one word: the worktree, a working copy of the same repository, on another branch, in another folder.
Each copy still has to be ready to use. That is what gwm does.
The tool: gwm, one workspace per task
gwm is a Git worktree manager written in Rust by Kylian Bardini (GitHub), under a free licence. Its documentation is thorough; here is what matters when leading agents.
| What it does | Why it matters when leading agents |
|---|---|
| Creates the worktree and the branch, and runs the project setup | The agent starts in an environment that works |
| Copies the files that are needed, with guard rules | A secrets file does not follow into every copy |
| Links the worktree to its issue or pull request | Each piece of agent work has a subject and a trace |
| Shows which agent is working in which worktree | The lead sees at a glance who is doing what |
| Lets a removal be undone | A cleanup mistake does not cost a day |
Its documentation says the guard rules come from a real incident: database credentials that went along in a copied .env. It is the same kind of rule as those in Three failures that said nothing: it exists because something went wrong once.
First use: this site
I installed gwm on this site's repository on 6 October 2026 (version 1.10.0, the Windows binary published with the release). With no configuration at all, the first gwm list already saw which agent was working in which folder.
Setting it up exposed a risk I had not seen: the local .env points at the production database, and gwm's Laravel preset copies that file into every worktree. A rule of a few lines stops it: when the file holds the remote database's address, gwm starts again from the .env.example template, which points at a local SQLite database. An agent working in a worktree can no longer write to the live site.
Then a real task: one page of the site made thirty queries to the database, half of them repeats. gwm create opened the worktree, installed the dependencies and filled the local database from the content, in a little over three minutes, unattended. The fix and its tests started from there; the page went down to sixteen queries. gwm pr wrote the pull request's body from the commits, and gwm remove put the worktree away once it was merged.
Two things to know on Windows: the setup commands run through sh, so gwm has to be launched from Git Bash; and in the configuration, regular expressions are written between single quotes. gwm doctor flagged the second mistake at once.
Tests that say no
An agent does not know what it broke elsewhere. The tests know for it. On the platform, they run once per house: an agent cannot break one site while fixing another.
This site gave an example the same day. The first version of the fix kept a list it had already read; a test that unpublished an article found it unchanged. The test said no, and the fix was reworked before it went live.
Written decisions
Nobody will remember what was settled in a session, an agent least of all: it starts from nothing each time. Decision notes become the team's memory, and the first thing an agent reads.
What the lead keeps
An agent proposes; it does not decide alone on what commits the team. On this site, the agent opened the pull request; I merged it. The lead keeps what goes to production, what touches the data, and the rules themselves.
Funding the tool
gwm is free software, built on personal time. In Free software at work I argued that a company using free software should fund it. gwm accepts sponsorship through GitHub Sponsors; reporting a bug or sending a fix helps just as much.
What I take from it
- Leading agents means writing: the rules, the roles, the decisions.
- One agent per workspace, and a workspace that never sees production.
- The tests say no in the lead's place; the lead keeps what commits the team.