祝融说。

34.1 Four-Phase Adoption: Pilot Phase → Standardization Phase → Rollout Phase → Optimization Phase

You have decided to roll out an AI coding methodology across your team. But you know this is not an "announce today, execute tomorrow" matter -- a wrong adoption approach can be worse than no adoption at all.

Introducing an AI coding methodology to a team changes not "which tools you use" but "how you work." Changing how people work is the hardest part -- it demands new habits, new processes, and a new way of thinking. If you roll it out to everyone at once, the likely outcome is: team resistance, uneven execution, diminished results, and then the conclusion that "this methodology does not work."

So you need to advance in phases. Each phase has clear goals and acceptance criteria, and the next phase can only begin once the previous one has met its bar.

Week 1          Weeks 2–3          Weeks 4–6         Week 7 onward
┌───────────┐   ┌─────────────┐   ┌─────────────┐   ┌────────────────┐
│ Pilot     │ → │ Standardize │ → │ Roll out    │ → │ Optimize       │
│ 1–2 people│   │ Set rules   │   │ Whole team  │   │ Keep improving │
│ 1 project │   │ Pilot checks│   │Assess impact│   │ Refine process │
└───────────┘   └─────────────┘   └─────────────┘   └────────────────┘

34.2 Goals, Practices, and Acceptance Criteria for Each Phase

Phase 1: Pilot phase (Week 1).

Goal: Validate the methodology on a small scale, accumulate experience, and surface early problems.

Why start small? Because every new methodology has a gap between the "ideal" and the "actual." The workflow you picture in your head will hit all kinds of surprises in real execution -- tool configuration issues, team misunderstanding, blind spots in the process. If you roll out to everyone at once, those surprises get amplified. Run it through on a small scale first, find the problems, revise the process, and then roll out -- the risk stays far more manageable.

Practices:

1. Select pilot participants: pick 1-2 developers who are enthusiastic about AI coding and technically strong;
2. Select a pilot project: pick a medium-complexity, non-critical business project (controllable risk);
3. Introduce the core methods: the six-step work method, and the three disciplines (blueprint, acceptance, rebuild);
4. Tool configuration: configure the AI coding tools, establish project directory conventions, and establish git usage conventions.

Key tasks in the pilot phase:

Acceptance criteria:

• □ Pilot participants can complete the six-step work method independently
• □ The pilot project produced a blueprint (CONTEXT.md)
• □ Every milestone has an acceptance record
• □ At least 5 issues from practice were collected

What the manager does: hold a weekly 1:1 with pilot participants to understand progress and issues; watch how the code quality of the pilot project changes; do not rush the rollout -- polish things on a small scale first.

Phase 2: Standardization phase (Weeks 2-3).

Goal: Build a unified team AI coding standard based on the pilot experience.

Why build the standard before rolling out? The mistake many managers make is letting the team start using the tool first and writing the standard only after problems appear. But once the team has formed the habit of "free use", establishing a standard meets resistance -- "we have always used it this way, why change now?" Building the standard before rollout looks slower, but it actually avoids the downstream cost of "changing habits".

Practices:

1. Review the pilot experience: which methods worked? which need adjusting? what problems came up? how were they solved? which standards can be standardized?
2. Write the standard documents: AI coding usage standard (which scenarios to use it in, which not to), blueprint template (the standard structure of CONTEXT.md), acceptance checklist (functionality / architecture / security dimensions), commit conventions (commit message format);
3. Toolchain configuration: configure team-level settings for the AI coding tools, build a shared library of blueprint and acceptance templates, configure git hooks (optional).

Sample standard document:

# Team AI Coding Standards (Draft)

## Scope of Use
- ✅ Routine CRUD features
- ✅ Writing unit tests
- ✅ Code migration and refactoring
- ⚠️ Core business logic (write manually before AI optimization)
- ⚠️ Security-sensitive code (authentication, encryption, payments)
- ❌ Architecture decisions

## Before Coding
- Produce a CONTEXT.md blueprint.
- The blueprint must include the tech stack, data model, API contracts, and milestones.
- At least one colleague must review the blueprint.

## After Coding
- Inspect every completed milestone.
- Inspection must cover functionality, architecture, and security.
- Do not commit code that has not passed inspection.

What the manager does: organize the review meeting; review the standard documents; make sure the standard is "executable" rather than "pinned to the wall".

Phase 3: Rollout phase (Weeks 4-6).

Goal: Roll the methodology out to the whole team and make sure most members can use it correctly.

The rollout phase needs team-wide training, pair practice, and effect assessment; Chapter 35's team-training plan is authoritative for tiered audiences, listen-to-do ratio, materials and environment, follow-up cadence, and evaluation. This chapter only places those arrangements in the Weeks 4-6 adoption timeline.

Common problems and responses:

What the manager does: organize training; monitor rollout progress; handle resistance; assess effectiveness.

Phase 4: Optimization phase (from Week 7 on).

Goal: Establish a continuous improvement mechanism so the methodology keeps evolving within the team.

Why is continuous improvement necessary? A methodology is not "designed once"; it is "optimized gradually through continuous use." Your team, your projects, and your tech stack all change, so the methodology has to change with them. A method that worked a quarter ago may no longer fit now. So you need an "audit -- review -- improve" loop:

1. Regular audits: a monthly code quality audit that checks architecture drift rate and standard compliance;
2. Review meetings: a monthly project retrospective discussing "what went well? what needs improvement?", and updating the standard documents;
3. Knowledge base building: collect best-practice cases, build a common-issues FAQ, and hold regular sharing sessions;
4. Field Notes channel: establish shared spaces with access based on client authorization and content sensitivity. Members promptly record shareable facts, context, and evidence links; a rotating maintainer groups related notes and arranges trial validation before admitting them to the knowledge base;
5. Bootcamp-style training camp: start with a suggested quarterly cadence, organizing recent retrospectives, validated practices, and new tools into half a day to a day of hands-on work. An owner arranges topics, environments, and exercise assessment. These frequencies and durations are adoption suggestions from this textbook; see Section 35.5 for operations.

Assign operational responsibility during optimization: register an owner, version, and last validation date for each tool, playbook, and template. Review quarterly and revalidate earlier when relevant environments change; mark invalid assets as unavailable or archive them. A cycle should produce at least one asset update validated through a trial, with feedback records. Post counts and training attendance alone are insufficient.

Metrics:

What the manager does: establish the audit mechanism; host the review meetings; drive continuous improvement; maintain the Field Notes channel and the bootcamp cadence, so the knowledge loop turns from individual habit into team mechanism (the "why" behind these two mechanisms and the FDE's personal duties are covered in Chapter 29).

34.3 Key Success Factors for Adoption

Why do so many methodology adoptions fail? The following five factors answer that question -- they are the most critical success factors, and none can be missing:

1. Executive support: if the manager does not understand the methodology's value, the team will not take it seriously. A single sentence from a manager -- "this process matters" -- outweighs any amount of training;
2. Pilot first: rolling out to everyone directly carries too much risk; a pilot validates the methodology's effectiveness at the lowest cost;
3. Executable standards: many standards fail because they are too "ideal" -- "every milestone must pass acceptance 100% before committing" may be impossible in practice. The standard should be "what we can actually do today", not "the ideal state";
4. Proper training: do not assume team members can teach themselves. Training is not "handing out a document and expecting everyone to read it on their own", it is "walking people through the work together";
5. Continuous improvement: the methodology is not set in stone; it needs constant adjustment. A process that worked a quarter ago may no longer fit now.

34.4 Common Problems and Responses (resistance, acceptance as a formality, etc.)

Problem 1: Resistance. Team members worry that AI will replace their jobs. Response: emphasize that AI is a tool, not a replacement; show how AI coding reduces repetitive work and lets people focus on more valuable work; invite the resistant members into the pilot -- seeing the actual effect is more convincing than any persuasion.

Problem 2: Acceptance as a formality. Acceptance becomes a "checkbox exercise" -- done to complete the process rather than to actually inspect the code. Response: provide an acceptance template to lower the barrier; spot-check the actual quality of acceptance records; link acceptance results to code quality data, so teams going through the motions can see their own low acceptance pass rate and high rework cost.

Problem 3: Standards executed at a discount. The standards are written in the documents, but execution drifts. Response: managers lead by example and follow the standards themselves first; check standard compliance during code reviews and standups; fold standard compliance into performance evaluation.

Problem 4: Polarization. A few people use it very well, while most are still on the fence. Response: turn the "users who do it well" into internal evangelists and have them share success cases openly; distill their practices into team templates; give pilot members a "mentoring" role during the rollout phase.

Problem 5: Tool bottlenecks. Inconsistent tool configuration and account-permission issues block usage. Response: resolve all toolchain issues during the pilot phase; establish team-level tool configuration standards; assign a dedicated person to maintain the tools.