# Works with agents alongside a team

> Competency coding-with-agents/works-in-team

Page: https://schubergphilis.github.io/ai-training/competencies/coding-with-agents/works-in-team/
License: CC BY-SA 4.0, https://creativecommons.org/licenses/by-sa/4.0/

*Coding with agents* · competency `coding-with-agents/works-in-team`

**Taught in:** the [Coding with agents](https://schubergphilis.github.io/ai-training/coding-with-agents/) course

**Draws on:** [Agents in a team](https://schubergphilis.github.io/ai-training/topics/coding-with-agents/team/), [Plan, implement, verify](https://schubergphilis.github.io/ai-training/topics/coding-with-agents/workflow/)

## 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](https://schubergphilis.github.io/ai-training/coding-with-agents/attribution-and-review-norms/)

### 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](https://schubergphilis.github.io/ai-training/coding-with-agents/attribution-and-review-norms/), [Enforcing the team's rules with hooks and CI](https://schubergphilis.github.io/ai-training/coding-with-agents/ci-and-hooks/)

### Keeps specs and tickets where the team and the agent can both reach them (base)

| Claim | Why | Example |
| ----- | --- | ------- |
| Specs and tickets go into the team's tracker, and the learner keeps none of them only in a private note or a chat. | Work that is only in one person's notes is invisible to the rest of the team and to every agent session. | The learner turns the plan from a chat into three tickets, each linking the spec, before any agent starts on them. |
| The learner records which ticket blocks which with the tracker's own links. | The tracker then marks blocked tickets, so a person or an agent picking up work can skip them (Creating issue dependencies, GitHub documentation). | The ticket for the login page is marked as blocked by the token ticket, and the agent asked for the next open ticket takes the token one. |
| The agent reaches the tracker through a command-line tool with credentials that allow only what it needs. | A command-line tool costs little context, and narrow credentials limit what a wrong command can do (Best practices for Claude Code, Claude Code documentation). | The agent's token can read tickets and add comments, and it cannot delete tickets or change the project's settings. |

Served by: [A backlog and standards the agent can read](https://schubergphilis.github.io/ai-training/coding-with-agents/backlog-and-standards/)

### Turns recurring review findings into written standards or automated checks (base)

| Claim | Why | Example |
| ----- | --- | ------- |
| When the same review finding comes up again, the learner adds it to the team's standards file. | A rule written down once is read by every reviewer and every agent, and a finding repeated in comments is forgotten (How Claude remembers your project, Claude Code documentation). | After the third comment about logging personal data, the learner adds the rule to the standards file with an example of what to log instead. |
| A rule that a linter or a hook can check moves out of the file and into the check. | A written rule is advice the agent may miss, and a check runs on every change (Best practices for Claude Code, Claude Code documentation). | The rule "no print statements in library code" becomes a lint rule, and the line in the standards file is deleted. |
| Reviewers block a change only for a rule in the file or a failed check, and mark other points as suggestions. | A review that blocks on personal preference makes the standard unclear and the rules in the file worth less (Code Review Developer Guide, Google Engineering Practices Documentation). | A reviewer writes "Nit: I would name this differently" and approves, because naming is not covered by the file. |

Served by: [A backlog and standards the agent can read](https://schubergphilis.github.io/ai-training/coding-with-agents/backlog-and-standards/)

### 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](https://schubergphilis.github.io/ai-training/coding-with-agents/parallel-sessions/)

### 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](https://schubergphilis.github.io/ai-training/coding-with-agents/ci-and-hooks/), [Writing down how the team uses agents](https://schubergphilis.github.io/ai-training/coding-with-agents/team-practice/)

## 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 |

## References

- Creating issue dependencies, GitHub documentation, https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/creating-issue-dependencies
- Best practices for Claude Code, Claude Code documentation, https://code.claude.com/docs/en/best-practices
- How Claude remembers your project, Claude Code documentation, https://code.claude.com/docs/en/memory
- Code Review Developer Guide, Google Engineering Practices Documentation, https://google.github.io/eng-practices/review/