You Bought the AI Tools. Nobody's Using Them.

How I got 90% of my engineers using AI daily.

It's Dionis Lebedev 🇺🇦

Dec 19, 2025

Every CTO I talk to says the same thing:

“Yeah, we bought licenses. Engineers can use it if they want.”

Then I ask: “How many actually use it daily?”

Crickets.

Here’s the thing: buying AI tools and getting engineers to actually adopt them are two completely different problems.

We ditched GitHub Copilot a long time ago, by the way. It was fine for autocomplete, but the game has changed. Now we’re using Cursor for frontend work (it’s great for React and component stuff), Windsurf for backend (it’s okay, gets the job done), and Claude Code for everything else.

And honestly? Nothing beats Claude Code. The agentic workflow, the ability to actually understand context across your whole codebase, the way it handles complex refactoring => it’s on another level. But I’ll get to that.

I spent the last 6 months actively pushing AI adoption across my engineering team. Not just “making it available.” Actually pushing it.

And I’m seeing results. Real usage. Productivity gains. Engineers who were skeptical are now telling me they can’t work without it.

Here’s how I did it.

The Problem With “Making It Available”

Most companies approach AI tools like this:

Buy licenses for GitHub Copilot or Cursor or whatever
Send an announcement: “Hey team, we now have AI coding tools available!”
Wait for adoption
Wonder why nobody’s using it

I did this too at first. And you know what happened? Maybe 2 out of 15 engineers actually used it consistently.

Why?

Engineers have workflows that already work.

They’re busy. Learning a new tool, even one that could save time, requires upfront investment.

Without active encouragement, most people default to what they know.

Skepticism is real.

A lot of senior engineers (especially the ones who’ve been coding for 10+ years) are skeptical of AI. “It just autocompletes. I can type fast enough.” “The suggestions are wrong half the time.” “I don’t trust it for production code.”

These aren’t dumb concerns. They’re just... incomplete. Because they haven’t experienced the productivity boost yet.

Nobody’s measuring it.

If you don’t track usage, you don’t know who’s benefiting and who’s not. You can’t spot patterns. You can’t help the people who are struggling.

You’re just hoping for the best.

My Approach: Active, Persistent, Measured

I decided to treat AI adoption like any other initiative: with intention, follow-through, and metrics.

Here’s what I actually did.

1. Push It Everywhere (In Slack, Meetings, 1-1s)

I started talking about AI coding tools constantly.

In Slack:

When someone shares a cool feature they shipped, I ask: “Did you use Claude Code for any of this?”
When someone’s stuck on a problem, I suggest: “Have you tried throwing it at Claude Code? It’s scary good at debugging.”
I share my own wins: “Just used Claude Code to refactor 500 lines of code in 10 minutes. It understood the whole context. Game changer.”

In meetings:

During sprint planning: “Remember, you’ve got AI tools now. Use them for boilerplate.”
During retros: “How many of you used AI this sprint? How’d it go?”
During tech talks: I demo specific workflows with AI

In 1-1s:

I ask every engineer: “Are you using Claude Code yet? What’s your experience?”
If they say no, I ask why. If they say yes, I ask what’s working.
I troubleshoot with them. “Not getting good results? Let me show you how I structure my prompts.”

The key: constant, low-pressure reminders.

Not “you MUST use this.” More like “hey, this is available, it’s really useful, here’s how I use it, give it a shot.”

But consistently. Every week. Multiple times.

Here’s what I noticed: active pushing plus genuine exchange sparks interest. When engineers see you actually using it, share their own discoveries, ask questions! That’s when it clicks. That curiosity is the foundation.

Once you have interest, you can move to the next level: establishing standards, building shared assets (prompt libraries, custom instructions), and adjusting processes to actually leverage AI properly.

2. Get Team Leads to Push It Too

Here’s the thing: I can only influence so much.

So I got my team leads on board.

I told them: “Part of your job now is helping your stream adopt AI tools. Encourage it. Share tips. Ask about it in standups.”

And they did.

Suddenly, it wasn’t just me. It were multiple people consistently talking about AI adoption.

That social proof matters. When multiple people are using it and talking about it, it normalizes the behavior.

3. Set Up Team Accounts (And Monitor Usage)

This was a game-changer.

I set up team accounts for our AI tools. This lets me:

Track who’s using the tools and how often
See usage patterns (are people trying it and dropping off? Or sticking with it?)
Identify who’s not using it at all (so I can follow up)

I’m not spying on engineers. I’m not micromanaging. But I AM paying attention.

If someone hasn’t logged in for 2 weeks, I’ll ask: “Hey, I noticed you haven’t touched Cursor lately. Is something not working? Or just haven’t had time to try it?”

Usually, it’s one of two things:

They forgot it was available
They tried it once, had a bad experience, and gave up

Both are fixable with a quick conversation.

4. Prepare Workshops

Here’s what I learned: most engineers don’t know how to use AI tools effectively.

They think it’s just autocomplete. Or they don’t know how to prompt. Or they don’t know which tools to use for what.

So I started preparing workshops.

Short, practical sessions:

“How to use Cursor for refactoring”
“How to use ChatGPT for debugging”
“Prompt engineering for code generation”
“When AI is helpful vs when it’s not”

The goal: lower the barrier to entry. Show people the patterns that work.

Not theory. Just: “Here’s what I do. Here’s what works. Try it.”

5. Hire AI-First Engineers

This is the long game.

When we’re hiring now, I ask candidates: “Do you use AI coding tools? Which ones? How do you use them?”

If they say no? That’s not an automatic disqualifier. But it’s a signal.

If they say yes and can talk about their workflow? That’s a big plus.

I want engineers who are already comfortable with AI. Who see it as a tool, not a threat. Who are excited about productivity gains.

And when these people join the team, they bring that mindset with them. They model the behavior for everyone else.

What’s Actually Working

Alright, so what are the results?

Usage is up.

6 months ago: 40% engineers using AI regularly
Now: 90%

That’s a huge shift. And it happened because of active pushing, not passive availability.

Engineers are reporting productivity gains.

I’m hearing things like:

“Claude Code just wrote the entire feature. I reviewed it, made two tweaks, done.”
“I threw that async bug at Claude Code. It found the race condition in 30 seconds.”
“Cursor’s great for frontend stuff, but for anything complex I just open Claude Code now.”

These aren’t juniors. These are senior engineers who were skeptical 6 months ago.

The thing about Claude Code specifically: it actually understands your codebase context. It can reason about architecture. That’s what converted the skeptics.

The culture is changing.

It’s becoming normal to use AI. Engineers share tips in Slack. “Hey, I found this cool Claude Code workflow for...” or “Check out this Cursor trick for components...”

That’s the shift I wanted. From “this is weird” to “this is just how we work now.”

The Resistance I Hit

Not everything has been smooth.

Some engineers are still skeptical.

Especially the most senior ones. They’ve been writing code for 15+ years. They’re fast. They know the patterns.

For them, AI feels like unnecessary overhead. “I can write this faster than I can prompt for it.”

I don’t force it. But I do encourage: “Just try it for one sprint. If it doesn’t help, drop it.”

Usually, they come back and say: “Okay, it’s actually useful for [specific thing].”

Some engineers had bad initial experiences.

They tried Copilot once. It gave terrible suggestions. They gave up.

That’s actually why we moved past Copilot. It’s fine for autocomplete, but when engineers tried it for real work and got garbage, they wrote off AI tools entirely.

Claude Code changed that. When I showed them what agentic AI can actually do, that’s when the lightbulb went on.

This is where the workshops help. “Here’s how to structure prompts. Here’s when to use Cursor vs Claude Code. Here’s what to ignore.”

Some people worry about code quality.

“What if the AI writes buggy code and I don’t catch it?”

Fair concern. My response: “You’re still reviewing it. You’re still testing it. AI is a junior developer that types really fast. You wouldn’t merge a junior’s code without review, right?”

That usually lands.

The Big Picture: AI Is a Competitive Advantage

Here’s why I’m pushing this so hard.

AI tools make good engineers 2-3x more productive.

Not for everything. But for a lot of things: boilerplate, refactoring, test writing, debugging.

If my team is 2x faster on 30% of their work? That’s a massive productivity gain.

Companies that adopt AI early will outpace those that don’t.

AI-assisted coding is already becoming table stakes. The companies that figure it out now have a head start.

Engineers who resist will fall behind.

I don’t mean that in a threatening way. I mean: the engineers who learn to work with AI will be way more productive than those who don’t.

And over time, that gap will widen.

I want my team on the right side of that gap.

What I’d Do Differently

Looking back, here’s what I’d change:

Start with a small pilot group.

Instead of pushing to the whole team at once, pick 3-4 engineers who are enthusiastic. Get them fluent. Then let them evangelize.

Social proof from peers is way more powerful than pressure from management.

Track specific metrics.

I’m tracking usage (who’s logging in). But I wish I’d tracked outcomes: “How much time did this save?” “How many lines of AI-generated code made it to production?”

Hard to measure, but useful for making the case.

Invest in prompting skills earlier.

The engineers who are getting the most value are the ones who learned how to prompt well. I should’ve taught that upfront.

It’s a skill. And it’s learnable.

The Playbook

Alright, so if you want to drive AI adoption on your team, here’s what I’d recommend:

1. Pick the right tools (this matters more than you think)

Skip Copilot, it’s yesterday’s news. Here’s what’s actually working for us:

Claude Code for everything complex. Agentic AI that understands your whole codebase. This is the game changer.
Cursor for frontend work. Great for React, component stuff, quick iterations.
Windsurf for backend if working with JetBrains. It’s okay, gets the job done.

Get team licenses. Make it easy.

2. Push it actively and consistently

In Slack. In meetings. In 1-1s. Don’t just announce it. Keep talking about it.

3. Get your leads on board

They multiply your influence. If they’re pushing it too, adoption happens way faster.

4. Track usage

Set up team accounts so you can see who’s using it and who’s not. Follow up with people who aren’t.

5. Run workshops

Teach people how to use the tools effectively. Show patterns that work.

6. Hire AI-first

When you’re hiring, prioritize candidates who already use AI. They’ll bring the culture with them.

7. Be patient but persistent

This won’t happen overnight. It’s a culture shift. But if you keep pushing, it’ll stick.

8. Build the next layer: standards, shared assets, process adjustments

Once you have adoption, go deeper:

Create shared prompt libraries for common tasks
Build custom instructions or CLAUDE.md files for your repos
Adjust your code review process (AI-generated code still needs review, but maybe differently)
Establish standards for when to use which tool

This is where the real leverage comes from. Individual adoption is step one. Team-wide integration is where it gets interesting.