Your CEO wants AI adoption. Your budget got approved. Your engineers are skeptical. Welcome to 2025.
Most teams mess this up spectacularly - buying every tool, running token competitions, forcing adoption just to say they’ve done it.
But some teams nail it. They get productivity gains, their engineers actually want to use the tools, and they can prove ROI.
We analyzed AI adoption patterns across 400+ companies (from 10-person startups to enterprises) over the past 12 months, to create an ‘AI adoption checklist’ for Weave’s users. The teams that succeeded all followed the same 5-level pattern:
Code editors
Background agents
AI code reviews
Measurement
Ongoing innovation
If you want to test yourself and get the TLDR recommendations, take the 30-second quiz here:
Note: I just started working at Weave, so full transparency - I’ll mention our product where it fits. But this framework works with any tools (spreadsheets, custom dashboards, whatever).
Level 1 - AI code editors
1.1 - Choose which tools to try
The amount of AI coding tools is overwhelming.
There is Cursor, Claude Code, GitHub copilot, Windsurf, Trae, and more popping up every week. We’ll cover in level 5 the need to constantly assess the latest tools, but for starters, we suggest picking 2 and evaluating them (our suggestion is Claude Code and Cursor). During the evaluation you’ll get tons of knowledge and experience, making the next tests easier.
1.2 - Pick an alpha team
Pick your alpha team strategically. Look for engineers who are:
Naturally curious about new tools (they were the early adapters of Cursor)
Influential with their peers (when they endorse something, others listen)
From different teams/seniority levels (mix senior and mid-level developers)
Size matters: 3-5 engineers total. Too few and you won’t get diverse feedback, but too many and coordination (and too many opinions) becomes a nightmare.
Time commitment: Expect each alpha team member to spend at least 4-5 hours per week on evaluation for the first month. Budget this into their sprint planning.
1.3 Set up rules files
Your alpha team’s first mission: teach AI to code like your team, not like a generic coding bootcamp graduate.
Most teams skip this step and then wonder why their AI keeps suggesting outdated patterns or writing code that feels “off.” Without rules, you’re basically asking AI to guess your preferences (spoiler - it will guess wrong).
Create rules that actually guide AI behavior. Instead of vague guidelines, be specific:
❌ Bad rule: “Write clean code” ✅ Good rule: “Always use TypeScript interfaces for component props. Name them with ‘Props’ suffix (e.g., ButtonProps)”
❌ Bad rule: “Follow security best practices”✅ Good rule: “Never hardcode API keys. Use environment variables with VITE_ prefix for client-side, no prefix for server-side”
❌ Bad rule: “Write tests” ✅ Good rule: “Every API endpoint needs integration tests using our testClient helper. Mock external services with vi.mock()”
Start with 10-15 specific rules. You can always add more as patterns emerge.
We also recommend to task your alpha team with testing solutions that can help your team unify and maintain rules across different tools. Here’s an open source example.
And of course, use Weave to automatically analyze your existing rules files against best practices from top engineering teams and get specific improvement suggestions!
1.4 Set up MCP servers
Next your team needs to tackle MCPs.
The Model Context Protocol lets AI tools pull in relevant context when they’re working, and also perform actions. Think of it as giving your AI access to the same tools your engineers use.
If you’re using Postgres locally, set up an MCP server for it. If you have internal APIs, same thing. Almost any tool right now has an MCP server - Jira, GitHub, Sentry. Make the AI’s environment as close to your engineers’ as possible.
You can also use GitMCP, which Instantly creates a Remote MCP server for any GitHub repository (meaning your tools will understand those libraries much better). Very useful if you have some big libraries you depend on (Tailwind, Phaser, etc).
1.5 Org-wide adoption
After your alpha team chooses a tool (or two), creates rules and sets up MCP servers - now it’s time to roll it out to everyone. Plan for 2-4 weeks of alpha testing before going org-wide (no need to rush, but a couple of sprints are more than enough).
Track adoption from both angles: have regular check-ins with teams to understand their experience, and use Weave to see the actual usage numbers (we’ll cover this in level 4).
1.6 Run ongoing internal training
The rollout is just the beginning. Now you need to help engineers actually master these tools.
Your alpha team has the deepest knowledge of how AI works with your specific codebase, so make them your internal trainers. Have them run small, focused sessions (team-sized max) using real examples from your company, not generic tutorials.
Focus on context engineering - the art of communicating with AI to get what you want. This skill transfers across all AI tools and will keep your team ahead as new ones emerge.
Make knowledge sharing automatic. Set up regular “AI tips” sessions (or even Slack channels) where engineers share their best prompts and workflows. The teams that do this consistently see the biggest productivity gains.
Keep sessions practical. Show how to debug a real bug, refactor actual legacy code, or write tests for your specific patterns.
Level 2 - background agents
2.1 Set up background agents
Now we’re getting into the good stuff. Set up background agents (Devin, Cursor Background agent, Codex, etc.) to actually make commits to your repos.
There are tons of tasks that need barely any human intervention. Background agents are a great fit for this - they’ll do the simple changes while your engineers focus on the hard problems.
They are definitely not perfect yet, but you have to start using them to figure out what works and what their limitations are.
Fun fact: 25% of Linear workspaces now use agents. Mainly Cursor and Devin agents that are getting tasked directly from Linear to fix bugs and improvements.
And those are used not only by engineers - CS, PMs and designers start opening PRs:
In the best setups, those commits automatically spin up preview environments, the stakeholder approves the result, and you “just” need to fix the PR 🙂
2.2 Enhance background agents with proper context
If you stop at level 2.1, expect shitty results.
You have to configure the agents with the right context and permissions - agents work way better when their environment looks like your engineers’ one. Follow the same steps as for coding environments, starting with rules and connecting relevant MCPs.
Level 3 - AI code reviews
As soon as you start working with agents, code reviews will become the new bottleneck. We are not at the stage yet where we can just blindly merge PRs without a human eye (unless you want a disaster), but it doesn’t mean you shouldn’t use AI to help you review faster (and catch more bugs).
They’re not replacing human reviewers, but they’re a strong addition. Let the AI catch the obvious stuff so engineers can focus on architecture and design decisions.
3.1 Set up AI code reviewer
Here too, we recommend going back to the alpha team and asking them to experiment.
In my experience, using the same tool that wrote your code to review it doesn’t generate great results.
We also recommend testing some dedicated tools to see which works best for your case.
3.2 Set up reviewer rules
Just like with code editors, AI reviewers don’t know your team’s style by default. Give them rules to follow.
Think of it like onboarding a new team member. Tell them what to call out and what to ignore. This improves the signal-to-noise ratio and saves everyone time.
Level 4 - Measuring the adoption (and its benefit)
You’ve rolled out AI tools, your engineers are using them, but how do you know if they’re actually helping? Most teams either don’t measure at all or track vanity metrics like “lines of AI-suggested code.”
Here’s how to measure what actually matters:
4.1 Track adoption quality, not just usage
Don’t celebrate “AI usage went up 40%!” without context. Track metrics that show if people are getting value:
Daily active users by team (are all teams engaging?)
Background agent adoption - are your automated agents actually getting used, or are engineers still doing everything manually in foreground tools?
Token burn rate vs outcome - who’s getting value vs. who’s stuck in prompt loops? Then you can see how a great environment set up looks like, and share with the other engineers.
4.2 Measure productivity impact
Track metrics that show if AI is actually making your team faster:
Time to first commit for new features (should decrease)
Code review cycle time (should stay flat or improve, not get worse)
Deployment frequency (should increase)
Warning sign: If code review time increases significantly, your engineers might be dumping unreviewed AI code on teammates (and everybody will hate it quite soon).
4.3 Watch for quality trade-offs
AI can make you faster, but not if you’re shipping broken code:
PR revert rate (should stay flat or improve)
Time spent on bug fixes vs. new features (should shift toward new features)
Code turnover rate: percentage of code rewritten within 90 days (watch for increases)
4.4 Calculate ROI
If costs are growing faster than usage, you might have engineers burning tokens on low-value tasks. Measure:
AI tool costs per engineer per month
ROI calculation: (Time saved × hourly rate) ÷ Tool costs
4.5 Set up your measurement system
Start simple: Pick 3 metrics total - one from adoption, one from productivity, one from quality. Track these manually for the first month to understand the data.
Level up: Use tools that connect your scattered data. Your AI usage lives in different tools, productivity metrics are in GitHub/GitLab, project data is in Linear/Jira. Tools like Weave can connect everything, but even a simple dashboard beats scattered spreadsheets.
Review cadence: Monthly reviews minimum. Look for trends, not just snapshots. Is adoption growing? Is productivity improving? Are quality metrics stable?
Level 5 - keep innovating (and converging)
The best AI tools today may not be the best in 1, 3, or 6 months. To make sure your team is getting the most value possible, you need a process for evaluating and adopting new tools.
5.1 Create a process for trying out new tools
We suggest deciding on:
Who is responsible for evaluating new tools?
How often should they do it? (make sure to provide time for it!).
How will they measure success?
You need some balance between evaluating new tools and not chasing every shiny object.
5.2 Adopt the best ones
Use all the steps above to adopt the new tools your testing team decides are worth a shot.
A side note: we recommend not to stop with engineering tools, but also to try to help other departments in your company. Evaluate AI tools for presentation (like Gamma), internal apps and PoCs (like Lovable), and so on. While non-engineers can evaluate and adopt those by themselves, you can provide tons of valuable input and get some goodwill.
Final words
There are so many teams with frustrated engineers and expensive tools that don’t help.
Treat AI adoption like any other engineering project - with clear requirements, testing, and rollout phases.
Your engineers aren’t the problem. They want tools that actually make their work better, not harder. Give them AI with proper context, clear rules, and time to learn - and they’ll become your biggest advocates.
Discover weekly
The Disposable Software Era by . An interesting perpsective.
Building prototypes that actually look like your product by .
