How to roll out AI coding agents to an engineering team when part of it won't touch them

I’ve watched this a lot on one engagement. The split was roughly what I’d expect anywhere now. Some of the developers were all in on AI. A lot more were somewhere on the fence. And there was a good group that were just like, I’m not using it.

Most of what’s written about rolling out coding agents is readiness checklists and vendor enablement guides, and that’s fine for the people who are already keen. This is about the last group, because in a big team that’s a lot of people, and plenty of them are senior.

What the resistance actually sounds like

The objection I heard more than any other was, my skills are going to atrophy. I had one developer on a proof of concept tell me they didn’t want to use it anymore because it was going to cause their developer skills to atrophy, and I almost hit my head on the table. Development has come through assembly language, and before that punch cards. Nobody’s punch card skills are relevant now. You’re not going to use those skills, and stopping yourself from embracing what’s coming to protect them doesn’t make a lot of sense.

But it’s worth knowing your sceptics aren’t some strange minority. The Stack Overflow Developer Survey 2025, with about 49,000 respondents, had 84% of developers using or planning to use AI tools, and 46% distrusting the accuracy of what comes out. Only 3% said they highly trust it, and favourability dropped from 72% to 60% in a year. Google’s DORA 2025 report has adoption at 90%, with 30% trusting the output little or not at all. Nearly everyone is using it, and a lot of them don’t believe it.

Impossible things change minds

What actually moved people was the ones who were adopting it succeeding. They were getting work done that wasn’t possible before. And it only took a few of those impossible things. Teams had items where it was, oh, we cannot do that, that’s going to take three months of work. And then somebody went and basically did it on the weekend with AI, and all of a sudden it was, okay, I need to change my prejudices a little bit.

The tech debt work was the same. There was a whole bunch of open tech debt that had been fairly stable for a long time, and a lot of it was framework upgrades from old versions. That’s going to take us three weeks, so we’ll never get around to it. It turned into two days. They could sit down for a hackathon, have a week, and it had a drastic impact on the open tech debt. Then they found new tech debt to add to the list, because now they could tackle all of that as well.

Tracking adoption, how much it’s used by developers and by everyone else, is useful as a change management number: are we actually even touching it? It doesn’t tell you whether you’re getting any benefit. What I’d track instead is a baseline of recurring tasks. That took us a week to deliver previously, and it’s something we do regularly. With AI, how long does it take now? Two days. Get to ten examples like that and you’ve got something you can show people. I think it’s a trap trying to track it too much, because most work isn’t recurring and every piece of code is slightly different.

The other thing I do with a lot of teams is find the people that are willing and give them every advantage I possibly can. Some of that’s about testing, but some of it is making sure they come out of it looking good.

Sit down with the sceptic, on their problem

The other half of it is being the example yourself. You just do things people didn’t think were possible.

One of the most senior engineers on that engagement wasn’t engaging with me at all. Not negative, he’s a lovely guy, he just hadn’t really touched AI. I sat down with him and he said he’d been struggling with a particular problem. We spent 15 minutes on it and got an 80% finished version, and then he had to run off to another meeting. He asked me to come back afterwards, and 30 minutes later he had something in production that he’d been putting off for six months, because he thought it was a huge task.

All of a sudden he became the biggest advocate, and he learned it all himself. That was my only training interaction with him. There’s more to training than that, obviously, but so much of it is self-learnable anyway. What people need is permission and examples of, oh, that works.

I think what sits under a lot of the resistance is a fear of wasting time. You invest time in something that doesn’t work, and then you look bad for having wasted the time. Once the unknown is gone, it becomes, oh, you can learn that.

Reasonable pushback versus feeling threatened

Not all resistance is the same. There’s a level of people being triggered by AI, feeling threatened by it, feeling like it’s changing a job they were quite happy and comfortable doing one way. And there are a lot of people pushing back in very reasonable ways, because they look at it and they don’t see it improving things.

The second group deserves a hearing. But that has to be a numbers argument, right? You can’t just say, oh, I don’t like it. If it isn’t helping on a particular codebase or a particular kind of work, show it, the same way the people with wins have to show theirs. Gut feel is unreliable in both directions anyway. METR ran a study in early 2025 with 16 experienced open source developers working in their own repos, and with AI tools they were 19% slower while believing they were about 20% faster.

What I’d set up is channels where teams show their wins, and the ability for a team to say, we’re deliberately not using it here because it’s not the right fit. That has to be an acceptable outcome. Sometimes the win really is, no, we’re not using it for this, or we’re using it but we’ve got proper processes to validate what it puts out. There are better ways to push back against AI adoption than being triggered, and that’s one of them.

Hiring, and what you’re actually protecting against

One company I was talking to has made this a big topic in their interview process: how willing people are to use AI and where they are in the journey. It’s not a hard no if someone is early in the journey. If they’re completely sceptical and unwilling to engage with it, that is probably a problem.

Don’t confuse that with the opposite risk, though, which is juniors. We’re all using AI, and that’s fine, but a senior will ask the AI for an answer only once they understand the problem. A lot of juniors and interns are blindly going, I don’t know what to do, solve it for me. That’s a different problem from a senior who won’t touch it, and it needs a different conversation.

And for the sceptics who are worried about their jobs, I’d tell them what I believe. The work never goes away. The job changes. I started with assembly language, BASIC and C, and people were certain with every one of those technologies that the job would go. It didn’t. Maybe not everyone stays at the same employer, but there’s so much more work to be done. The people who should be most worried are the ones who refuse to see the new technology, because the biggest risk to the job is pretending it’s not happening.

For what changes in the team itself once the agents are writing most of the code, I wrote about that in what changes for an engineering team when agents write the code. If you want someone to sit down with your engineers on their own problems, that’s what team enablement is for.