Team practices

On Wednesday, August 18, the whole web team came to the Portland boardroom, along with Rosa and, for the first half hour, Malik. The topic was what had come up in every session so far without being settled: how should a team, not just one developer, work with Copilot? Individual skill matters, but most of the value and most of the risk come from shared habits. When four people each use the tool their own way, the codebase ends up with four styles, four levels of review and four views on what is acceptable. This lesson covers writing team guidelines, sharing instructions and prompts, review norms, pairing and learning, onboarding, managing cost together, and keeping the guidelines alive.

Why team practices matter

Copilot changes how code is produced, and teams need to agree how to absorb that change. Questions that never came up before now need answers. Is it acceptable to commit code you could not have written yourself? Who reviews agent pull requests? Which tasks should go to agents and which should not? When is it fine to paste an error log into chat, and when does the log contain something that must not leave the company? Without shared answers, each person decides alone, usually under time pressure.

The first course gave Tidewater its policies: which features are on, which repositories allow the coding agent, which files are excluded, which MCP servers are allowed and what the budget is. Policies set the boundaries. Team practices are how people work inside them.

A short guidelines document

Priya drafted Tidewater's Copilot guidelines in the session, with the team editing live. She asked Copilot Chat to propose an outline from the notes of the previous ten sessions, then the team rewrote each section in their own words. The finished document was one page, kept in the admin repository and linked from the contributing guide.

The disclosure rule caused the most discussion. Lena asked whether she had to mention every accepted completion. The answer was no: the rule covers significant assistance, such as an agent writing most of a change or chat generating a whole module, so that reviewers know where to look harder. Small completions are part of normal editing.

Sharing instructions and prompts

Lessons 3 and 7 showed how instructions files and prompt files turn individual habits into shared ones. At team level the important step is ownership. Tidewater made .github/ a code-owned folder, so changes to copilot-instructions.md, path-specific instructions, AGENTS.md and prompt files need a review from Priya or Dmitri. Each prompt file names an owner in a comment at the top. When someone finds a prompt that works well, the habit is to turn it into a prompt file in a pull request, rather than sharing it in chat where it is lost.

.github/
  copilot-instructions.md          # owner: Priya
  instructions/
    data.instructions.md           # owner: Owen
    templates.instructions.md      # owner: Lena
  prompts/
    write-tests.prompt.md          # owner: Dmitri
    explain-module.prompt.md       # owner: Lena
    changelog-entry.prompt.md      # owner: Dmitri
    onboarding-plan.prompt.md      # owner: Priya
AGENTS.md                          # owner: Priya

Named owners mean someone notices when a file goes stale. Lena owned the templates instructions because she did most of the template work, and Owen owned the data instructions, which was his first time owning anything in the repository. He said it made him read the file properly for the first time.

Review norms

The review checklist from lesson 9 became a team norm with three additions. First, Copilot code review runs on every pull request in trailcheck as a first pass, and its comments must be answered (applied or dismissed with a reason) before a person reviews. Second, agent pull requests are reviewed by someone other than the person who assigned the task, so a second pair of eyes sees the framing as well as the result. Third, review comments about AI-assisted code focus on the code, not on whether AI was used; "this query is built from strings" is useful, "did Copilot write this?" is not.

Agreeing which work goes to agents

The team found it helpful to agree, in broad terms, which kinds of work suit agents and which do not, so that nobody had to argue it out task by task. Good candidates had a clear definition of done that tests could check: adding a field through several layers, writing missing tests for a module, updating code for a library's new version, or fixing a bug with a failing test already written. Poor candidates needed judgment the agent could not have: anything touching the volunteer data, design decisions about how a feature should behave, changes to security settings, and any guidebook text. Between those, the rule was to ask whether a new colleague could do the task from the issue alone. If yes, it could go to an agent; if the colleague would need a conversation first, so would the agent, and the conversation should happen before the task was assigned.

Pairing and learning

Copilot can either speed up learning or replace it, depending on how it is used. Tidewater adopted two practices. Pairing with Copilot in the room: once a week, two people work on one task together with Copilot, talking through each suggestion before accepting it. This spreads good prompting habits quickly, and it is where Lena picked up most of what Dmitri had learned in the first course. Learning mode for newcomers: for their first months, newer developers use chat to explain anything they accept that they could not have written, and keep completions off while designing. The GH-300 guide lists accelerating learning as a benefit; these practices make sure the learning actually happens.

The team also agreed to keep some skills deliberately in practice. Once a month, each developer takes a small task, such as a bug fix, and does it without Copilot. Priya presented it as maintenance, not purity: if the service were unavailable for a day, or a task fell in an area where Copilot was weak, the team still needed to work well.

Onboarding

The partner publisher's liaison developer was due to join in September, and the eight-seat expansion approved in the first course would add the editors' trial team and Malik. The team used this session to prepare an onboarding path for new Copilot users, drawing on both courses.

The last step closes a loop. New people notice what experienced users have stopped seeing, so their questions are a cheap way to improve the guidelines.

Managing cost together

Since June 2026, chat, agent and code review usage draws on a shared pool of AI credits, while completions and next edit suggestions are included. Cost is therefore a team matter: one person running many long agent tasks uses credits everyone shares. The first course set a budget alert at 20 US dollars of extra usage and a hard stop at 30. In this session the team agreed habits that keep usage reasonable without rationing it.

pool = 4 * 1900          # credits from four Business seats
weekly_use = {"Priya": 1450, "Dmitri": 1900, "Lena": 1150, "Owen": 600}
month_estimate = sum(weekly_use.values()) * 4.3
over = max(0, month_estimate - pool)
print("pool:", pool)
print("estimated monthly use:", round(month_estimate))
print("extra credits:", round(over), "=", round(over / 100, 2), "US dollars")
share = {name: round(use / sum(weekly_use.values()) * 100) for name, use in weekly_use.items()}
print("share of use, in 100:", share)

pool: 7600
estimated monthly use: 21930
extra credits: 14330 = 143.3 US dollars
share of use, in 100: {'Priya': 28, 'Dmitri': 37, 'Lena': 23, 'Owen': 12}

The figures in the example were a deliberate "what if": Dmitri had taken his heaviest week of agent experiments during this course and assumed everyone used credits at a similar level all month. The real pilot months had used about 8,900 credits a month in total, close to the pool. The exercise showed how quickly heavy agent use could change the picture, and led to three habits: keep agent tasks small and bounded; start a new chat for each task so context stays short; and check the credits page on Mondays. Nobody was asked to stop using agents. The team wanted to notice early if a habit was getting expensive.

Rosa added one more practice for the expansion in September: when the eight-seat pool arrived, the team would compare the first month's usage with the pilot's and with this session's estimate, and adjust the budget alert if the new users' pattern turned out lighter or heavier than assumed. Budgets set once and never checked tend to be either too tight, stopping useful work, or too loose, hiding waste.

When something goes wrong

Guidelines also need a plan for mistakes. Sooner or later someone will paste a log containing a token into chat, merge an agent change that breaks a page, or find a suggestion that matched code under an incompatible license. Tidewater's guidelines said what to do: tell Priya or Rosa straight away, without blame; for a leaked secret, revoke it first and then investigate, as the security course taught; for a bad merge, revert first and fix second; and write a short note afterwards about what would have prevented it. The note goes into the quarterly review, which is how the guidelines learn from experience.

Keeping the guidelines alive

Guidelines decay like documentation. Copilot features change monthly, and a rule written in August may be wrong by December. Tidewater put a review of the guidelines on the agenda of the quarterly Copilot review that Rosa would run, with three standing questions: which rules were broken, and why; which new features need a rule; and which rules no longer apply. Changes go through a pull request to the admin repository like any other change.