What happened when 200 engineers got Claude Code access with zero training

Last year we rolled out Claude Code to our entire engineering organization — roughly 200 people across 30 teams. No training. No guidelines. Just licenses and a Slack message that said "it's available, go try it."

Here is what actually happened.

The 10/60/30 split

Within six weeks, a pattern emerged that I have since heard repeated at four other companies:

• 10% became power users. These were the engineers who had already been experimenting with ChatGPT and Copilot on personal projects. They dove in immediately, built custom CLAUDE.md files, and started using worktrees and subagents within the first week. By week three they were the informal support team for everyone else.
• 60% tried it once or twice and then mostly stopped. They opened it, tried a vague prompt like "refactor this function," got a mediocre result, and concluded it was not ready for real work. They were not wrong — without context about what works and what does not, the first experience is often underwhelming.
• 30% never opened it. Not hostile, just busy. They had a backlog, a way of working that was functional, and no obvious reason to change.

The cost nobody talks about

The 10% power users became a bottleneck. They were fielding 15-20 DMs per day: "how do I get it to understand my repo," "it keeps hallucinating import paths," "is it safe to paste our internal API schema." Their actual feature work slowed down. We had created a new kind of tech debt — knowledge debt — concentrated in a handful of people.

Meanwhile, the 60% had a reasonable but wrong mental model. They thought Claude Code was like autocomplete: you type something vague and it finishes your sentence. When that did not work, they assumed the tool was overhyped. Nobody had shown them the difference between a zero-context prompt and a well-structured one with a CLAUDE.md file, relevant files attached, and a clear task definition.

What structured onboarding changed

Three months in, we ran a structured pilot with 40 engineers from the 60% group. The onboarding was simple:

1. A 45-minute live workshop where a practitioner (not a vendor, not a slide deck) demonstrated three real tasks on the actual company codebase. Not toy examples — a real bug fix, a real test addition, a real migration script.
2. A hands-on lab where each engineer got a failing test in a repo they already knew, and had 30 minutes to make it pass using Claude Code. Guided, with a facilitator in the room.
3. A one-page reference card with five patterns that work and three antipatterns that waste time. Laminated. Stuck to monitors.

Four weeks after the pilot, the adoption rate in that group went from roughly 30% regular usage to 75%. Not because the tool changed — because the engineers' mental model changed. They stopped treating it like autocomplete and started treating it like a junior pair programmer that needs specific instructions.

Three patterns that emerged

Across both the power users and the newly-onboarded group, three usage patterns dominated:

1. Test-first development. Write the test, hand it to Claude Code, let it write the implementation. The test acts as both specification and verification. This was by far the highest-success-rate pattern.
2. Migration and boilerplate. Database migrations, API endpoint scaffolding, type definitions from OpenAPI specs. Tedious, well-defined tasks where Claude Code is reliably good.
3. Code review prep. Ask Claude Code to review a diff before submitting the PR. Not a replacement for human review — a pre-filter that catches the obvious stuff so the human reviewer can focus on design decisions.

The takeaway

Buying licenses is not adoption. The gap between "tool available" and "tool useful" is a training gap, and it is wider than most engineering leaders expect. The good news: it is not a hard gap to close. A few hours of structured, practitioner-led onboarding with real examples from your own codebase will move the needle more than months of self-directed exploration.

The bad news: if you do not close it intentionally, you end up with a 10/60/30 split and a burned-out power user answering the same five questions in Slack.