Team Practices & Adoption

These rules apply regardless of which tool produced the change, and every other page in this sub-section assumes them:

When an AI assistant materially helped write a commit, this repository records that with a Co-Authored-By trailer in the commit message, the same convention GitHub uses to credit multiple human authors. It is a line of the form Co-Authored-By: <name> <email>, placed on its own line, normally at the end of the commit message body:

This repository’s own history carries exactly this shape — for example the merge commit that added the sibling LLM Foundations & Prompting sub-section ends its message with a Co-Authored-By trailer naming the Claude model that helped write it. git log on any branch of this repository shows the pattern in practice:

A trailer records assistance, not a disclaimer of review: it sits alongside the human author’s own name, which is what makes the golden rule above ("you own the diff") checkable later — git blame and git log --author still resolve to the person who reviewed and merged the change. GitHub’s own commit guidance documents the trailer format itself — one Co-authored-by: name <name@example.com> line per co-author at the end of the commit message (git matches trailer keys case-insensitively, so Co-Authored-By works the same) — at Creating a commit with multiple authors or on behalf of an organization.

Re-deriving the same prompt, instruction file or agent workflow on every project wastes the exact context an assistant needs most. This account’s own catalog of reusable Claude Code skills, agents and prompt guides — covering the issue-to-plan-to-code-to-PR-to-release flow, docs updates and more — is published as AI Catalog, and is the concrete example of what a shared library looks like once a team has one: named, versioned, documented workflows that any repository (including this one) can install and invoke by name, instead of every author reconstructing the same prompt from memory. Authoring that kind of library — writing instruction files, prompt files, skills, agents, hooks and plugins yourself — is out of scope on this page and belongs to Customizing AI Workflows; here the point is narrower: once a library exists, point new team members and new prompts at it before writing from scratch.

Bringing a new team member up to speed on AI-assisted work is largely the same problem as bringing them up to speed on the codebase, with three additions specific to the tools:

Two families of numbers are useful once a team has enough AI-assisted history to compare against: an acceptance rate (how often a suggestion or an agent’s proposed diff is kept, not overwritten or reverted) and a cycle time (how long a task takes from start to merge). Both are metrics to instrument and watch trend over time on your own team’s data — this page does not give target numbers, because a credible acceptance rate or cycle-time figure depends entirely on the team, the codebase and the task mix it was measured on, and a number quoted out of that context is not transferable.

Cycle time overlaps with the wider DORA metrics research program (https://dora.dev/), which studies the capabilities that drive software delivery and operations performance across the industry — change lead time, deployment frequency, and failure/recovery measures among them. DORA’s own findings are the reference point for why cycle time matters (faster, safer delivery correlates with these capabilities), not a source of numbers to copy; read the current metrics on https://dora.dev/ rather than treating any fixed list as permanent, since the research program itself has evolved which metrics it reports.

Beware vanity metrics: "lines of code generated" or "suggestions shown" say nothing about whether the code was correct, reviewed, or ever merged, and can rise even as delivery gets slower if they encourage keeping every accepted-then-reverted suggestion. A metric is only useful if it is measured alongside outcome, not volume — pair an acceptance-rate or cycle-time number with defect rate, review turnaround, or one of the DORA measures above before drawing a conclusion from it.

GitHub Copilot ships its own usage-metrics dashboards and a REST API covering adoption, engagement, acceptance rate, lines of code, and pull-request lifecycle data at the enterprise, organization, repository and user levels (GitHub Copilot usage metrics); the REST endpoints themselves are documented at REST API endpoints for Copilot usage metrics. Claude Code’s own cost and usage visibility is covered, links only, on Managing Context.

Org-level policies control which Copilot features, models and agents are available to a team and are managed from organization or enterprise settings, documented at GitHub Copilot policies for enterprises and organizations; the equivalent Claude Code controls are managed settings, which an organization deploys to every developer’s machine and which Claude Code applies above user, project and local settings, so they can pin permission and sandbox defaults a developer cannot override — documented at Claude Code — Deploy managed settings. The permission modes and sandboxing those settings pin are covered on Securing AI-Assisted Development.

IP and licensing risk from AI-generated code centers on two questions: did a suggestion reproduce someone else’s licensed code, and is the origin of a given change disclosed. GitHub Copilot’s public code filter (also called duplication detection) checks completions against public code on GitHub and, in Block mode, suppresses a suggestion that matches or nearly matches it; in Allow mode it instead shows the matching public repositories so a reviewer can check the license before keeping the suggestion — Finding public code that matches GitHub Copilot suggestions. Attribution — the Co-Authored-By trailer above, plus whatever your own team or organization policy requires in a PR description — is what makes an AI-assisted change traceable later, the same way a human co-author’s name is.

Responsible use of an AI coding assistant is narrower here than the general responsible-AI literature, but two points are specific to day-to-day development: don’t let an assistant’s confident tone substitute for the verification the golden rules above require, and don’t feed it data it isn’t cleared to see — content exclusion and training opt-outs (named, links only, on Securing AI-Assisted Development) exist for exactly that reason. GitHub’s own responsible-use documentation for each Copilot surface — Responsible use of GitHub Copilot features — is the authoritative source for what a given feature is and isn’t intended to do; the AI Security & Responsible AI sub-section goes into this in more depth; see Responsible AI Practices.