You rolled out Copilot. You paid for the licenses. You sent the announcement email.
Six weeks later, usage metrics look like a ski slope — steep drop-off after week one.
If this sounds familiar, you're not alone. Adoption of AI coding tools is failing at most companies, and the reasons have almost nothing to do with the tool itself.
Here's what's actually happening — and what actually works.
The Real Problem: Nobody Knows What to Do With It
When developers get access to a new AI tool, they try it for the obvious things first: "Write me a function that does X." Sometimes it works great. Sometimes it halts output, generates something weird, they hit backspace, and go back to their normal workflow.
The tool didn't fail. The workflow integration did.
AI tools like Copilot and Claude Code aren't drop-in replacements for anything. They're amplifiers — but only if you already have a workflow to amplify. Most developers don't get training on how to integrate the tool into their daily work. They get a license and a Confluence page.
What Engineering Managers Get Wrong
Mistake #1: Mandating the tool without changing the workflow
If you tell your team "use Copilot for all new features" but your PR review process, your definition of done, and your velocity metrics stay the same — you're adding friction, not removing it. Developers will use the tool to generate boilerplate, then spend twice as long understanding what it wrote. They'll stop.
The fix: Pick one part of the workflow to improve first. Sprint retros? Copilot summarizes discussion notes. Code review comments? Copilot explains context. Pick one, build a habit, expand.
Mistake #2: Treating it as a junior developer who writes code
The mental model that AI "writes code for you" sets teams up for disappointment. It does write code — but that's not the highest-value use. The highest-value uses are:
- Explaining unfamiliar codebases ("What does this module do?")
- Generating test cases for existing code
- Writing documentation that actually gets written
- Translating between languages (Python to TypeScript, etc.)
- Summarizing PR diffs for stakeholders
If your team is only using it for autocomplete, they're using 10% of the value.
Mistake #3: No shared knowledge of what works
The teams that get real ROI from AI tools do something specific: they share prompts. Someone discovers that a particular way of asking for code review feedback actually works. They put it in a shared doc. The whole team starts using it. It gets refined.
This sounds obvious. Almost no one does it.
What Claude Code Gets Right (and Wrong)
Claude Code takes a different approach than Copilot — it's agentic, meaning it can take actions, not just suggest completions. This is genuinely powerful for:
- Running tests, seeing them fail, and iterating until they pass
- Doing multi-file refactors
- Researching how a library works before writing code that uses it
But it requires a different mental model. You're not asking it to autocomplete your thought — you're assigning it a task and reviewing the output. That's closer to managing a contractor than writing code. Teams that treat Claude Code like a faster GitHub Copilot will use it poorly.
The best use case: Claude Code is exceptional for "I understand the problem, now execute." It's not great for "I'm not sure what I want yet." Know which situation you're in before you start.
A Framework for Actual Adoption
This is what works, based on patterns I've observed in teams that move the needle:
Week 1–2: Low-stakes, high-visibility wins
Pick tasks where AI clearly saves time and there's no risk: documentation, test generation, meeting summaries, draft emails to vendors. Don't try to change core engineering workflows yet. Just create visible wins that make AI feel real and useful.
Week 3–4: One workflow integration
Pick a single, specific place in your actual development workflow to integrate the tool. Code review prep? Sprint planning notes? Onboarding docs? Make it concrete and measurable. Before: "This takes 45 minutes." After: "This takes 15 minutes."
Week 5–6: Shared knowledge loop
Have someone (or rotate it) collect what's working. Not a survey — a real prompt library. Ten prompts that your team has tried, refined, and actually uses. Put them somewhere everyone can find them. Review in retro.
Week 7+: Expand from proven wins
Now you have real data and real patterns. Expand usage based on what's actually working in your team's specific context — not what a vendor's case study says.
The Organizational Reality
AI tool adoption is a change management problem that's being treated as a tooling problem.
The teams that succeed have a leader (usually a senior engineer or EM) who:
- Takes the tool seriously enough to develop their own workflows
- Documents what works
- Runs informal sessions where people share what they've figured out
- Shields the team from premature pressure to "show ROI" before habits form
The teams that fail have executives who bought licenses and engineers who got an announcement email.
If you're an EM reading this: the tool is probably fine. The missing piece is you.
If you're working through AI tool adoption at your company and want to compare notes, drop a comment. I'm particularly curious to hear from teams who've gotten past the "week one drop-off" problem.
Top comments (0)