GUIDE · TEAM ENABLEMENT
How to Train an Engineering Team on Claude Code
Most Claude Code rollouts fail at the same point: everyone gets access, a few people go deep, and the rest go back to what they were doing. The gap is not the tool. It is that nobody taught the team how the work changes. This is the ten-session arc I run to close it, delivered weekly on the team’s own repository.
IN SHORT
Training an engineering team on Claude Code means changing how the team works, not issuing licences. A trained team has shared conventions committed to the repository, agreed review habits for generated code, and at least one workflow it now runs through the agent by default.
A licence is not training
The distinction that matters is between a team that has Claude Code and a team that uses it. Access takes an afternoon. Changing how ten engineers work takes a structured programme, because the hard part is not the commands. It is the judgement about when to reach for an agent, how much autonomy to hand it, and what you refuse to let it near.
Nearly everything published about Claude Code is written from one person’s seat: how I use it, my configuration, my workflow. That is useful and it is not the same problem. A room of engineers at different levels, with different habits and different parts of the codebase, does not learn the way one motivated individual does. This guide is about the room.
I ran this arc with the IT team at an Ahmedabad real estate group across ten sessions. The work later extended to their Sales team on a separate track, and a second entity in the group is now onboarding.
The ten-session arc
Each session runs on the team’s own repositories with live demonstration rather than slides. The order matters more than it looks: capability comes before configuration, configuration before autonomy, and autonomy before anything is allowed near production work.
WHAT EACH SESSION COVERS AND WHAT THE TEAM LEAVES WITH
| Focus | What the team leaves with | |
|---|---|---|
| Session 1 | Claude foundations | A working mental model of what the model does well, where it fails, and why prompting is a skill rather than a trick. |
| Session 2 | Claude Code itself | First real runs in the terminal. The shift from chat to an agent that reads and edits files. |
| Session 3 | Repository onboarding and CLAUDE.md | A CLAUDE.md committed to their own repo, so conventions are shared rather than personal. |
| Session 4 | UI and frontend work | Front-end changes driven through the agent, where output is visual and review is immediate. |
| Session 5 | Skills and plugins | An understanding of what can be packaged and reused rather than retyped each time. |
| Session 6 | Custom skills | Skills built for their own stack and their own recurring tasks. |
| Sessions 7 and 8 | Spec-driven development | The spec, plan and task loop, so larger changes stay reviewable instead of arriving as one opaque diff. |
| Sessions 9 and 10 | Live coding on real work | Everything above applied together on actual tasks, with the accumulated setup in place. |
Why it runs on your repository, not a sample project
A sample repository teaches the commands and hides the problem. Real codebases are the reason teams struggle with agentic tools: inconsistent conventions, undocumented decisions, files nobody wants to touch, and history that explains why something is written the way it is.
Running every session on the team’s own code means the friction shows up during the session, while I am in the room, rather than the following week when everyone is alone with it. It also means the CLAUDE.md written in session 3 is the one they keep using, not an example they will have to redo.
The trade-off is that the sessions are less tidy. Something will not work the way it did in preparation. That is the point, because that is what the following Tuesday looks like.
Why weekly, and not a two-day intensive
The arc runs one session a week over roughly ten weeks. A compressed bootcamp covers the same material and produces less change, because the week between sessions is where the learning actually happens.
Engineers try something on real work, hit a wall, and bring the wall back. Those questions are better than anything I would have planned, and they are only available if there is a gap. A team that sees all ten sessions in three days has no gap, and returns to a normal week with nothing rehearsed.
It also spreads the cost of attention. Ten weeks of one session is absorbable alongside delivery. Three consecutive days is a delivery outage.
What the team keeps
The deliverable is not the sessions. It is what survives them: a CLAUDE.md in the repository, custom skills built for their stack, and a documented workflow the team agreed to rather than one I imposed.
This is the part most training leaves out. A workshop transfers knowledge to whoever was in the room that day. Committed conventions and reusable skills transfer it to whoever joins next, which is what makes the change durable rather than personal.
FREQUENTLY ASKED
Common questions
How long does it take to train an engineering team on Claude Code?
The arc I run is ten sessions, one a week, over roughly ten weeks. Teams are productive on straightforward work well before the end, usually after the repository onboarding session, but the later sessions on spec-driven development and custom skills are what make the change stick rather than fade.
Can this be compressed into a shorter programme?
It can, and I would push back on it. The week between sessions is where engineers apply things to real work and hit the problems worth discussing. Compressing the arc removes that gap and produces a team that has seen the material rather than used it.
Does the training run on our own codebase?
Yes. Every session runs on your repositories with live demonstration rather than slides. A sample project teaches the commands and hides the real difficulty, which is applying an agent to a codebase with existing conventions and history.
What does the team actually have at the end?
A CLAUDE.md committed to your repository, custom skills built for your stack and recurring tasks, and an agreed workflow. Those outlive the sessions and carry to people who join later, which a workshop on its own does not.
Do engineers need prior AI experience?
No. The first session covers foundations, including where the model fails, so nobody is guessing. What they do need is comfort in a terminal and familiarity with the codebase, because the sessions run on real work from early on.
Is this the same for a non-engineering team?
No, and it should not be. The arc above assumes people who read and write code. Business functions get a separate track built on their own tasks, which is how the same engagement later extended to a Sales team.
Written by Keyur Patel, an AI engineer in Ahmedabad with 12 years building software and production AI on Claude, currently an AI Tech Lead and AWS Certified AI Practitioner. I have used Claude Code and Cursor on production repositories for two years and I teach both to engineering teams.
Updated