Most engineering teams adopting Claude Code are stuck. Not stuck meaning they’ve abandoned it — stuck meaning individuals use it inconsistently, the gains haven’t compounded, and nobody can quite articulate why the tool that felt transformative in a demo feels merely useful in practice.
The problem isn’t the tool. It’s that Claude Code adoption follows a predictable maturity curve, and most teams mistake Stage One progress for Stage Two readiness.
Understanding the curve doesn’t just explain why adoption stalls. It tells you exactly where to intervene.
Stage One: Individual Experimentation
Adoption almost always begins the same way. One or two engineers start using Claude Code on their own initiative — usually the people already paying attention to AI tooling. They report back positively. Word spreads. A few more engineers try it. Within weeks, you have a team where some people are using Claude Code daily and others haven’t installed it yet.
This stage feels like progress, and it is. But the value being generated is entirely individual.
Each person has developed their own mental model of what the tool is — one engineer thinks of it as a smarter autocomplete, another is using it for full-feature implementation, a third uses it primarily for test generation. None of these mental models are wrong, but they’re incompatible. There’s no shared language for talking about Claude Code, no shared conventions, and no shared configuration.
The key characteristic of Stage One: value is real but non-transferable. If the engineer who figured out how to use it effectively for code review leaves, their knowledge leaves with them.
Stage Two: The Stall
At some point, often following a positive trial period or a directive from leadership, teams move to formalise adoption. Someone creates a CLAUDE.md file. Claude Code gets added to the onboarding checklist. Usage becomes expected rather than optional.
This is where most teams get stuck, and it’s worth understanding precisely why.
The configuration gap
Claude Code’s defaults are designed for individuals. A team has different requirements: shared conventions about which files the tool should and shouldn’t touch, what commands it should seek permission for, how it should interact with your specific codebase. Without a properly configured CLAUDE.md and settings file, every engineer is still effectively running a different tool. The file exists, but it’s either minimal (“use TypeScript, follow our style guide”) or has become a dumping ground for every instruction anyone has ever thought to add, with no coherent structure.
The mental model gap
Because Stage One was individual, the team enters Stage Two with half a dozen different mental models. Some engineers are using Claude Code as an autocomplete replacement. Others are running it autonomously on larger tasks. Some are comfortable with multi-step agentic work; others find the idea of Claude Code touching their filesystem unsettling. Without a shared definition of what good usage looks like, these differences quietly undermine adoption. The engineers who haven’t figured it out feel behind; the engineers who have feel like evangelists without an audience.
The measurement gap
Teams in Stage Two almost never have a clear definition of success. Is Claude Code working? Probably, but nobody can say by how much or for what specifically. Without measurement, the tool exists in a state of perpetual “seems useful”, which is fine until a senior engineer raises concerns about code quality, or an incident gets attributed (fairly or not) to AI-assisted development, and there’s no data to have a proper conversation.
The ownership gap
In Stage One, there’s no need for anyone to own Claude Code. In Stage Two, nobody does. Configuration drifts. The CLAUDE.md file becomes outdated. New engineers join without proper context on how the team uses the tool. The gap between your best Claude Code users and the average widens rather than narrows.
The result is an organisation where Claude Code is technically adopted but the gains remain individual rather than compounding. Teams can spend months in this state, believing they’ve adopted Claude Code when they’ve really only adopted it individually.
What Moving to Stage Three Requires
Stage Three is standardisation. It’s the point where Claude Code stops being a tool that individuals use well and becomes something the team uses consistently.
The transition requires four things.
A real CLAUDE.md
Not a list of preferences, but a document that gives Claude Code meaningful context about your codebase: its architecture, its conventions, the things it should always do and the things it should always ask about. A CLAUDE.md written for a team reads differently from one written for an individual — it anticipates the variation in how different engineers will invoke the tool and provides guardrails that work across all of them.
Shared custom commands for your actual workflows
The most underused feature in team Claude Code adoption is custom commands. When your team has a /review command that embeds your actual code review criteria, a /test command that knows your testing conventions, or an /incident command that follows your runbook, you’ve encoded institutional knowledge into the tool. New engineers get your team’s standards automatically rather than having to absorb them over months.
Named ownership of the configuration
This doesn’t require a dedicated role, but it does require a named responsibility. The person who owns your Claude Code configuration reviews it as the codebase evolves, updates commands when processes change, and onboards new engineers on how the team uses it. Without this, configuration becomes a communal file that nobody is responsible for and gradually stops reflecting how the team actually works.
A shared definition of good usage
This is the least technical requirement and often the hardest. Teams need an explicit conversation about what they expect Claude Code to do autonomously, what they expect engineers to review, and where the human judgement layer sits. The teams that make this transition well tend to have had this conversation deliberately — in a structured session with the whole team — rather than hoping it emerges from usage over time.
Stage Four: Production Pipelines
For teams that successfully navigate Stage Three, Stage Four becomes available: Claude Code as infrastructure rather than just a developer tool. This means dedicated agents for specific, scoped tasks — code review agents, documentation agents, test generation agents with real coverage targets. It means hooks that automate pre- and post-commit workflows. It means MCP integrations that connect Claude Code to your internal systems: your issue tracker, your deployment pipeline, your monitoring stack.
Stage Four is where the compounding gains that were promised in the demos actually materialise. But it’s only reachable through Stage Three. Teams that try to jump from Stage Two to Stage Four — deploying agents before establishing shared conventions — tend to create more problems than they solve.
Where Most Teams Are Right Now
The majority of organisations adopting Claude Code are somewhere in Stage Two. They have adoption without standardisation. The tool is being used, the value is uneven, and there’s a growing gap between the engineers who have figured it out and the rest of the team.
This is largely a coordination problem rather than a technical one. The engineers who are stuck aren’t less capable — they simply don’t have shared context, shared configuration, or a shared definition of what good looks like. Getting a team aligned on these things is often the highest-leverage intervention available, and it’s why the Stage Two-to-Three transition responds so well to structured onboarding: working through configuration, commands, and mental models together rather than individually tends to compress what might otherwise take months of drift into something a team can resolve in a day.
For organisations that want to accelerate this transition, Zartis runs Claude Code workshops: hands-on sessions where engineering teams build their shared configuration, establish conventions, and leave with a repeatable workflow rather than a collection of individual habits. The format exists because the maturity curve is consistent enough that the intervention can be, too.
The Practical Test
If you want to know where your team sits on the curve, three questions are usually enough.
- Does your CLAUDE.md reflect how your team actually works today, or is it the version someone wrote six months ago? If it’s the latter, you’re in Stage Two regardless of how long you’ve been using the tool.
- Do you have custom commands that encode your team’s conventions? If not, or if they exist but engineers don’t use them, Stage Three is still ahead of you.
- Could a new engineer joining tomorrow understand how your team uses Claude Code from your shared configuration alone? If the answer is no, the knowledge lives in individuals rather than in the system — and Stage One adoption is still the ceiling on your gains.
The maturity curve isn’t a criticism of teams stuck at Stage Two. It’s the normal progression. The value in naming it is that it tells you what the next step actually is, and that it’s closer than it might feel from the middle of it.