10 - Adopting Claude Across a Team

🎁 One engineer on your team gets incredible results from Claude Code and everyone else gets garbage. What does that person know that the others don't, and how do you copy it?

The gap is rarely talent. It's setup and habits. The person getting good results has a tuned CLAUDE.md, a few saved commands, and knows what not to hand the model. This lesson is about making that the default for everyone, not a secret one person carries.

Shared Conventions

The single biggest lever is checking your Claude setup into the repo. CLAUDE.md, custom slash commands, and MCP config all live in the project. Commit them, and every teammate who clones the repo inherits the same context, the same shortcuts, and the same guardrails.

your-project/
  CLAUDE.md                  # project memory: build cmds, conventions, gotchas
  .claude/
    settings.json            # shared hooks + permissions
    commands/
      ship-check.md          # /ship-check: team's pre-PR checklist
    agents/
      reviewer.md            # a shared code-review subagent

Without this, everyone re-teaches Claude the same facts about your codebase, and half of them do it badly. With it, a new hire's first prompt already knows your test command and your naming conventions. Treat CLAUDE.md like a README that the AI actually reads.

Spreading What Works

Good prompts are reusable. When someone finds a workflow that lands, turn it into a shared slash command so it stops living in one person's head.

<!-- .claude/commands/fix-flaky.md -->
Find the flaky test in the failing CI run, reproduce it locally by running it
20 times, identify the race or timing assumption, and fix it. Show the repro
before and after. Do not weaken the assertion to make it pass.

Run reviews on how the team uses AI, not just the code it produces. A quick "what's working, what's wasting time" in a retro surfaces the habits worth copying. The engineer who stopped one-shotting and started planning first will save everyone a week if you let them explain it.

When Not to Use AI

The maturity signal isn't using Claude for everything. It's knowing where it's the wrong tool. Some work has no cheap verification loop, and that's exactly where AI output is most dangerous, because it looks right and no test will tell you it isn't.

Reach for Claude:      Do it yourself:
- bug with a repro     - security-critical crypto / auth logic
- test coverage        - a schema migration you can't roll back
- mechanical refactor   - the core architecture decision
- boilerplate           - anything you can't review or verify
- codebase questions    - taste calls (API shape, product UX)

The rule that scales: if you can't review the output or write a test that catches it being wrong, don't ship what the model wrote. Use it to explore, then make the call yourself.

From Tool to Product

At some point an internal workflow gets run so often that it should stop being a person typing prompts and become a feature. That's the jump from Claude Code (a tool you drive) to the Claude API (something you build with).

Signals it's time to build it as a product feature:
- the same prompt runs dozens of times a day
- non-engineers need it (support, sales, ops)
- it needs to run on a schedule or react to events
- the output feeds another system, not a human reviewer

A "summarize this ticket" prompt you run by hand is a tool. The same thing wired into your helpdesk, running on every new ticket with structured output your code can parse, is a product. When you hit that line, the skills move from this course to building with the API directly.

Measuring Impact

Don't measure lines of code generated. That number goes up when quality goes down, and it rewards exactly the wrong behavior. Measure the things you actually care about.

Weak signal:            Real signal:
- lines AI wrote        - PR cycle time (open → merged)
- prompts per day       - review comments per PR (fewer surprises)
- % code "AI-assisted"  - time to first fix on incidents
                        - onboarding time for new hires

If cycle time drops and review quality holds or improves, adoption is working. If PRs are getting bigger and reviewers are rubber-stamping, you've automated the production of code nobody understands. Track the outcome, not the activity.

Key Takeaways

• Check CLAUDE.md, .claude/commands/, .claude/agents/, and MCP config into the repo so the whole team inherits the same setup
• Turn winning prompts into shared slash commands instead of leaving them in one person's head
• Review how the team uses AI in retros, not just the code it ships
• Don't ship what you can't review or test; skip AI for security-critical, unverifiable, or taste-driven work
• A prompt you run dozens of times a day is a signal to build it as a Claude API feature
• Measure PR cycle time, review quality, and onboarding time, never lines of code generated

🎁 You've got the practice down: driving Claude, reviewing its output, and rolling it out safely. Ready to build AI features into your own product instead of just using the tool? That's exactly what AI Engineering Concepts picks up.