Most engineering organizations already have Claude Code in the building. What they do not have is any agreement about how it is used, which is a different problem from adoption and needs a different fix.
The usual state of play: a few engineers are enthusiastic and fast, a few tried it and drifted back, and nobody can describe the team’s approach because there is not one. Prompts live in individual scratch files. Nobody has shared a skill or a subagent. There is no agreed position on whether AI-written code needs a different review posture, so each reviewer invents one.
That is not a training gap in the usual sense. Those engineers can use the tool. What is missing is a standard, and standards do not emerge from individual practice — they have to be written down and argued over once.
What changes for an individual
Worth stating plainly so the team-level claim is not overstated. An engineer working with Claude Code gets meaningfully faster at a specific band of work: navigating an unfamiliar codebase, writing the test before the implementation, mechanical refactors across many files, reading a stack trace back to its origin, and producing the kind of documentation that otherwise never gets written.
They do not get faster at knowing what to build, and the sharpest engineers tend to notice that the bottleneck simply moves. That is a real gain, but it is bounded and it accrues to the person rather than the organization.
What changes for a team, if you let it
Shared skills instead of private prompts
The prompt an engineer refined over three weeks to handle your migration pattern is worth more to the other eleven engineers than to its author. Packaged as a skill, it becomes part of how the team works and survives that person changing projects. Left in a scratch file, it leaves with them.
Subagents for the work nobody wants to own
Review passes, dependency audits, test-coverage sweeps, migration checks. These are valuable, repetitive, and consistently deprioritized. Handing them to a subagent that runs on a schedule changes them from a task someone must volunteer for into something that happens.
MCP connections to the systems you actually run
The difference between a useful assistant and an impressive demo is usually access. An agent that can read your issue tracker, query the staging database and see CI output is working with the same information the engineer has. One that cannot is guessing politely, and its output has to be treated accordingly.
Hooks that make the standard enforceable
A convention nobody checks is a suggestion. Hooks let the team encode the parts that matter — formatting, forbidden imports, a required test run before a commit — so the standard holds without a human remembering to enforce it in review.
The distinction that matters
Individual fluency makes engineers faster. A shared standard makes the team faster, and only the second one survives people leaving.
The review question you have to answer
Every team adopting this eventually argues about whether AI-assisted code should be reviewed differently. It is worth having the argument deliberately rather than discovering that four reviewers quietly settled on four answers.
The position we generally land on: the review bar does not change, but what reviewers look for shifts. Generated code tends to be locally plausible and globally naive — it fits the file and misses the constraint that lives two directories away. It also tends to be over-general, solving a version of the problem broader than the one in front of it.
The related question is authorship. Someone has to be able to explain the change, and "the model wrote it" is not an explanation. Making that expectation explicit removes an awkward conversation later.
How to tell whether it is working
Seat count and message volume tell you almost nothing. More useful: how many skills the team shares and how often they are used, whether subagents run on a schedule without anyone triggering them, whether a new joiner can find the standard written down, and whether time-to-first-commit for that new joiner has moved.
That last one is the honest measure. If a new engineer reaches a useful contribution meaningfully faster than they did a year ago, the standard exists and is doing work. If not, what you have is a group of individually faster engineers, which is worth something but is not the thing you were told you were buying.
The failure mode to watch for
The common way this goes wrong is volume. Output rises, review capacity does not, and the queue becomes the bottleneck within a few weeks. What follows is predictable: review quality drops to keep pace, and the team ships more code it understands less well.
This is a throughput problem rather than a tooling one, and it has to be answered deliberately. Some teams cap work in progress. Some route generated changes through an automated first pass so human review starts from a shorter list. Some decide that certain categories do not get AI assistance at all, because the review cost exceeds the writing saving.
Any of those is a reasonable answer. Not choosing one is not, and the teams that struggle are usually the ones that let the change in without noticing it moved where the constraint sits.
Where Focus20 fits
The Claude Code track turns inconsistent individual usage into a repeatable engineering workflow: skills, subagents, MCP integrations, hooks, and an agreed position on testing and review — written against your codebase rather than a generic syllabus. The same engineers then stay to build the agents and workflows it makes possible.