Skip to content

C.O.D.E.S. team collaboration

Charter · Onboard · Decide · Educate · Sync

C.O.D.E.S. is the team-level practice. The other seven frameworks describe what an individual developer does at a desk; C.O.D.E.S. describes what a team does together so that the individual practices compound rather than scatter.

Without C.O.D.E.S., AI assistants become solo behavior. Each developer discovers their own prompts, their own workarounds, their own near-misses, and the team rediscovers the same lessons three times. With C.O.D.E.S., one developer's lesson becomes the team's lesson within a week.

Why teams, not individuals, are the unit of measurement

DORA's 2024 Accelerate State of DevOps report measured AI-tool impact at the team level, not the individual level. Individual flow rose; team-level throughput and stability dropped1. The intervention point that reconciles the two is team coordination, which is what C.O.D.E.S. is for.

When does C.O.D.E.S. apply?

Continuously, but with a clear initial sprint:

  • Day 0 of any AI adoption. Even a one-team pilot needs the Charter and the Sync rhythm before the first prompt.
  • Whenever a new team adopts that wasn't in the previous wave.
  • After any significant tool change (new vendor, new model, new agentic capability).
  • As a quarterly cadence for teams already in a steady state, to prevent the rhythm decaying.

The five parts

C. Charter

Each team has a one-page AI working agreement. It is small, because it is meant to be read.

The team charter answers, at minimum:

  • What we use. Which AI tools are approved (per the vendor standards). What we use them for and what we don't.
  • What we don't paste. The data classes that never go into a prompt, regardless of tool. (Maps to the data handling policy.)
  • How we share prompts. The location and ownership of the team's prompt library; the format conventions.
  • How we review. The depth of V.E.R.I.F.Y., S.E.C.U.R.E., and C.L.E.A.R. by tier; who reviews whose work.
  • How we surface failures. Where AI-related defects, near-misses, and surprises get logged so the team learns. (See pilot scope for the running-log pattern.)

The team charter does not replace the organizational charter. It operationalizes it for the team's actual workflow.

A team charter that fits on one page will be read. One that does not, won't.

O. Onboard

When a new joiner (engineer, designer, PM) joins a team that uses AI assistance, they need a structured onboarding to the team's practice, not just the company's AUP.

A minimum onboarding sequence:

  1. Read the team charter and the AUP.
  2. Walk through the prompt library with a peer. Live, not asynchronous.
  3. Pair with a senior team member for one full S.C.A.F.F. → V.E.R.I.F.Y. → C.L.E.A.R. cycle on a real change.
  4. Sit in on the team's weekly sync (see below) before they contribute prompts of their own.
  5. Submit one PR with the prompt visible in the description, so the reviewer can check both the prompt structure and the verification.

This sequence takes one to two days. It saves weeks of "why does our team's prompts not look like the prompts I used at my last job?" confusion.

D. Decide

When the team makes a prompt decision that other teams might benefit from (a Failure-modes clause that prevented an entire class of defect, a Context block that fit the team's domain unusually well) the team records it as a Decision Record.

The Decision Record format is the same as the template. Tag it as prompt-pattern so it is searchable.

This is how prompt patterns spread without becoming folklore. Two years into AI assistance, the difference between teams that have an artifact-based prompt history and teams that have a tribal one is substantial.

Recording prompt decisions as Decision Records also gives the audit trail something to point to in regulated environments: the team did not just adopt a prompt; the team decided to adopt it, with a documented rationale.

E. Educate

Training is recurring, not one-time:

  • Initial training at adoption: 4 to 8 hours per developer (see the training-needs assessment).
  • Refresher every six months, scoped to what has changed: models, capabilities, AUP clauses, near-misses.
  • Just-in-time when a new capability lands (e.g., a new agentic feature). Short, focused, before the capability is enabled in production.
  • Cross-team rotations so a team's hard-won lessons don't stay inside the team.

Training is internal-led for AUP, policy, and team-specific practice. It is vendor-led only for product mechanics. Do not let a vendor explain your AUP; see Phase 1: Pilot.

S. Sync

The team holds a weekly 30-minute AI sync. It is the smallest recurring meeting that keeps the practice alive.

A standard agenda:

Time Topic
0–5 Wins from the past week: one prompt that worked unusually well, one verification catch that mattered.
5–15 Failures and near-misses: every AI-adjacent defect, hallucination, or surprising output, with what was learned.
15–25 Prompt-library updates: new entries, deprecations, edits.
25–30 Open questions, decisions to capture as DRs, escalations to the wider AI governance forum.

The discipline is failures and near-misses get airtime. A team that surfaces only wins is a team where the failures will surface as incidents instead.

The Sync is also where the team compares AI-assisted outcomes: which tasks the assistant accelerated, which it didn't, where the quality showed up. Those comparisons feed the team's metrics dashboard and the program-level retrospective.

How C.O.D.E.S. composes with the other practices

Practice What C.O.D.E.S. adds
S.C.A.F.F. The team's prompt library and the conventions for it.
V.E.R.I.F.Y. The depth-by-tier mapping the team has agreed on.
S.E.C.U.R.E. The list of surface areas the team has flagged for the security pass.
S.H.I.E.L.D. The team's understanding of why the platform controls exist (and so why not to evade them).
C.L.E.A.R. Reviewer rotation, reviewer-author pairing, the standing reviewer questions.
R.E.F.A.C.T. A queue of named refactors with owners; review of refactor success.
D.O.C.S. Named documentation owners per area; cadence for last_updated review.

C.O.D.E.S. is the connective tissue that turns the per-change practices into a team practice rather than a folder of individual habits.

Sizing guidance

Sizing guide

  • Small (< 50). Charter is one page. Sync is a 15-minute addition to an existing standup or weekly. Prompt library is a single Markdown file in the repo.
  • Mid (50–500). Each team has its own Charter and Sync; cross-team prompt-pattern sharing happens at a monthly forum. Onboarding is part of the joiner pack.
  • Enterprise (500+). Charter is a template each team instantiates; cross-domain Sync at the engineering-org level every two weeks; named "AI practice lead" per domain. Onboarding is a tracked module.
  • Regulated. The Charter references the AUP and the data-handling policy clause by clause. Decision Records are mandatory for prompt patterns that affect Tier High/Critical paths.

Common collaboration failures

Failure Pattern Fix
Solo prompts Each developer keeps their own prompt habits, no sharing Make the prompt library load-bearing: visible in PR descriptions, reviewed in Sync
Wins-only Sync Failures and near-misses don't get airtime Make failures the first agenda item, not the last
Vendor-led training The team learns the vendor's tool but not the company's AUP Internal-led AUP training; vendor-led only on mechanics
Charter-as-shelfware One-page charter that nobody re-reads Reference it in every PR template; refresh quarterly
No onboarding for joiners New joiners reinvent prompts and re-learn near-misses Pair on one full cycle before they fly solo

Anti-patterns

Don't

  • Don't let AI use stay solo. A team in which each developer learns AI assistance independently is a team that pays the learning cost N times. Share patterns, fast.
  • Don't skip the prompt library. "We'll just remember good prompts" is the most common version of we'll relearn the same lesson every quarter. The library is the team's memory.
  • Don't let the Sync become a status meeting. It is a learning forum. If it becomes status, kill it and start a new one with the original purpose.
  • Don't outsource AUP training to the vendor. Vendors do not know your AUP and have no incentive to enforce it. Internal-led.
  • Don't onboard joiners with a link-dump. Pair them through one full S.C.A.F.F. → V.E.R.I.F.Y. → C.L.E.A.R. cycle. Otherwise the team's practice doesn't transfer; only the tool does.

Next

  1. Google Cloud / DORA, "2024 Accelerate State of DevOps Report", Oct 2024. [primary] ↩