Works with agents alongside a team
Coding with agents · competency coding-with-agents/works-in-team
Taught in: the Coding with agents course
Draws on: Agents in a team, Plan, implement, verify
Learning objectives
Attributes agent work honestly in commits and reviews (base)
| Claim | Why | Example |
|---|---|---|
| Commits and pull requests say that an agent wrote the change, in the form the team agreed on. | Reviewers read agent-written and human-written changes differently, and they need to know which one they have. | The commit trailer names the agent and model, per the repository's convention, on every agent-authored commit. |
| The learner takes responsibility for the change as its author, and the attribution does not shift blame to the tool. | The person who submitted the change is accountable, and the tool is not. | In the review the learner writes "I asked the agent for this and I checked it", instead of "the agent did this". |
| The learner keeps the attribution form the project asks for, including what it forbids. | Some projects need a certificate of origin only a person can sign, and an agent's sign-off is not valid. | The learner adds the assisted-by trailer and leaves out Signed-off-by because the project says only humans certify. |
Served by: Saying what the agent did, in the commit and the review
Follows the team's review and CI norms for agent changes (base)
| Claim | Why | Example |
|---|---|---|
| Agent-written changes go through the same review and CI gates as any other change, and the learner does not bypass them because "the agent tested it". | The gates exist for changes from anyone, and an agent's tests are part of the change under review. | The learner waits for CI and a reviewer's approval on the agent's pull request instead of merging it themselves. |
| The learner sizes and labels agent changes so reviewers can read them. | A reviewer who receives a 3000-line agent diff either skips it or blocks it. | The learner splits the generated change into three pull requests and marks them as agent-assisted in the title, as the team asked. |
| The learner reads and follows the team's agent instructions file before starting, and proposes changes to it instead of working around it. | The file is the team's shared agreement, and a session that ignores it makes changes the team rejects. | The instructions say "no new dependencies without an issue", so the learner opens the issue first. |
Served by: Saying what the agent did, in the commit and the review, Enforcing the team's rules with hooks and CI
Runs several agent sessions without losing coherence (expert)
| Claim | Why | Example |
|---|---|---|
| Each parallel session works in its own checkout or worktree on its own branch, with a task that does not overlap the others. | Two agents editing the same files produce conflicts that cost more than the parallelism saved. | The learner briefs one agent on the API change and another on the documentation, in two worktrees, and merges the API first. |
| The learner keeps a written list of what each session is doing and what state it is in. | A person can follow only one session closely at a time, and a forgotten session is a session that finished the wrong way. | A short note per session: branch, task, next check-in, and whether it is waiting on the learner. |
| The learner integrates often and in a fixed order, and rebases the rest. | Parallel branches drift, and the longer they live the harder they merge. | Every afternoon the learner merges the finished branches into main and has the remaining sessions rebase before they continue. |
| Shared resources (ports, databases, the stash, credentials) are either per session or left alone. | Sessions that share a port or a stash interfere with each other without any visible conflict. | The learner tells each agent not to start the dev server, because the port is shared, and to run the build instead. |
Served by: Running several agent sessions in worktrees
Sets the team's practice for agent use (expert)
| Claim | Why | Example |
|---|---|---|
| The learner writes the team's agent practice down where the team and the agents read it: what agents may do, how work is attributed, how it is reviewed. | Unwritten practice is a different practice per person, and the agents follow none of them. | The repository's AGENTS.md says what the CI gate is, what a commit trailer looks like, and which directories agents may not touch. |
| The practice starts from the mistakes the team has seen and changes when the mistakes change. | A practice written from imagination guards against the wrong things. | After two incidents of agents committing generated lockfiles, the team adds a hook and a line in the instructions, and removes a rule that never triggered. |
| The learner makes the practice checkable by tooling where possible. | A rule enforced by a hook is followed every time, and a rule in a document is followed by whoever read it. | A lint hook checks the commit message format, and CI checks the attribution trailer. |
Served by: Enforcing the team's rules with hooks and CI, Writing down how the team uses agents
Alignment
| Framework | Code | Asks | Objectives here |
|---|---|---|---|
| AI Fluency 4D (Dakan and Feller) | Diligence | Use AI responsibly, transparently and with accountability for the result | attributes-honestly |
| Brilliant Coding with AI | BLD-4, BLD-5 | Organize and oversee a workflow | runs-parallel-work |