Your Engineers Aren't Resisting AI Because They're Lazy
You bought the licenses in February. You sent the memo — a good memo, the one about how this is a tool and not a threat, and how everyone should get comfortable with it. Maybe you expensed a course too.
It’s August. Two people use it properly. Both of them were going to figure it out on their own anyway. Everyone else opened it, poked at it for twenty minutes, and went back to what they were doing.
The easy read is that your engineers are being stubborn. Or precious about their craft. Or, on a bad day, lazy.
They’re not. I’ve been on the founder’s side of this exact standoff, and I got it wrong at first too. From where an engineer sits, not adopting is the rational move. Until you deal with that, no amount of license spend changes anything.
Here’s what’s actually going on, in the order that matters.
Blocker one: “This is how I get replaced”
Think about how these tools were sold to you. The pitch was speed. Ten times the output. Fewer people, more shipped.
Now imagine that same pitch landing on someone whose mortgage depends on the work taking as long as it takes. If a tool’s headline benefit is that it does your job faster, being loudly enthusiastic about it looks a lot like arguing for your own redundancy.
Nobody says this in a standup. It would sound paranoid, and it would sound like you’re not a team player. So it never gets said out loud. It shows up instead as low usage, mild technical objections, and a lot of “yeah, I tried it, it’s fine.”
When I ran Pulse360, I handed my engineering team the tools and told them they could be far more productive. I meant it as good news. What came back was resistance. It took me longer than it should have to see that from where they sat, the resistance made sense. I was asking people to prove they were replaceable and I hadn’t given them one concrete reason to believe they weren’t.
I consult now, and I’m working with two companies where this is the single biggest blocker. In both cases the founder was sure it was a tooling problem. It wasn’t.
So let me say the thing your team is waiting to hear, because I suspect you’re wondering about it as well: this is not an argument for a smaller team. It’s an argument for a faster one. If you have decided to cut headcount, none of what follows will help you, and your engineers will smell it on you in the first session anyway. But if what you actually want is the same people shipping three times as much, that is a completely different conversation — and it’s one you have to start out loud.
Blocker two: they tried it once and it lied to them
Somebody on your team gave it an honest try in week one. They asked it for a function. It produced something confident, clean, well-formatted, and wrong — a call to a method that doesn’t exist, against an API that never had it.
That took an hour to unpick. And that one hour became the whole opinion. “I tried it. It makes stuff up.”
I understand that reaction completely. But what was missing there usually isn’t the model. It’s the workflow around the model — how you scope the task, what context you hand it, how you check what comes back, and when you throw the attempt away instead of arguing with it.
I know that because I went and learned it myself, on a live production codebase, with real customers on it. Over 171 days I shipped 253 pull requests — all merged, all deployed — around 670 commits and roughly 150,000 lines added. That worked out to somewhere between four and five and a half times the pace of a single senior developer.
And it was not magic. A PDF header and footer feature took me seven attempts with reverts before it was right. A template grid took five. I want to be specific about that, because the vendor version of this story never includes the reverts, and any engineer who has actually tried it knows the reverts are there. If your training doesn’t admit that, your team will write off everything else in it.
What I found it genuinely strong at: new features, UX and UI iteration, database migrations. It’s very good at bug fixes when you pair it with real error logs from Sentry — the logs do most of the work of framing the problem. Where it was weakest was performance optimization, which leans on domain knowledge about your data and your users that isn’t sitting anywhere in the repository.
That’s a real, mixed, usable picture. It’s also the kind of thing you can only say after doing the work.
Blocker three: every demo is built on a green-field app
Watch any tutorial. Someone builds a to-do app, or a landing page, or a small API, from an empty folder, in eleven minutes. Impressive. Also nothing like your team’s Tuesday.
Your engineers work in a codebase that’s five or ten years old. There’s a service nobody wants to touch. There are two ways of doing auth because of a migration that never quite finished. There are tests that matter, and a deploy path with real consequences. Dropping a model into that and telling it to “add the feature” produces something that technically runs and quietly violates four conventions your team agreed on in 2021.
So the engineer concludes the tool doesn’t work on serious code. What’s actually true is that using it on serious code is a different skill from using it on a blank folder — and almost nobody is teaching that skill.
That’s the skill worth teaching. Which files to put in front of it and which to keep out. How to describe the constraint that isn’t written down anywhere. How to make it follow your patterns instead of the average pattern from the internet. How to review its output at speed without either rubber-stamping it or rewriting it by hand.
None of that transfers from a tutorial. All of it transfers from doing one real ticket together.
Blocker four: nobody wants to look slow
This is the one almost nobody writes about, and in my experience it’s the most reliable predictor of whether a rollout sticks.
Your senior engineers have spent fifteen years becoming the person other people ask. Their standing on the team is built on knowing more than everyone else in the room. Now there’s a tool that a junior picked up over a weekend and is visibly faster with.
No senior engineer is going to raise their hand in a group session and say they don’t know how this works. They will not fumble a prompt in front of the team they lead. So they’ll skip the session, or attend and say little, and learn it privately at 11pm, or not at all.
If your training doesn’t give them a way to learn without losing face, you’ll lose exactly the people whose adoption would have carried everyone else.
Practically, that means small groups or one-on-one time for the senior folks. It means starting with a problem that’s genuinely hard, so the tool’s limits are visible early and nobody feels naive for hitting them. And it means the person teaching should be the first one in the room to get something wrong.
What actually works
Five things, in this order.
Name the fear out loud, in the first session. Say where this leaves them, specifically. Say whether headcount is changing. Engineers who understand where they stand stop resisting; engineers who are guessing keep resisting, and they’re right to.
Start in your codebase, not a sandbox. Pull real tickets off the backlog and work them together. Whatever gets built in the session is work you keep, which also means the session isn’t overhead.
Teach the workflow, not the tool. The tools will change again this year. How to scope a task so a model can do it, how to review what comes back, when to discard and restart, and where it will confidently lie to you — that survives the next release.
Set a pace expectation. Mine is small features every two to three days, medium ones in about two weeks, large ones in four to six weeks, maximum. Say the number. Once a team has seen that rhythm actually hold on their own code, it stops feeling like a stretch target and starts being the norm.
Leave a written playbook. Specific to your stack, your constraints, your conventions. It’s what makes this survive the person who taught it, and it’s what a new hire reads in week one.
The part worth repeating
Before I built Pulse360 I ran distributed engineering teams across six countries — Argentina, Spain, London, India, Ukraine, Russia. Different time zones, different norms, one constant: people work the way that keeps them employed. That isn’t cynicism. It’s how anyone with responsibilities behaves.
Your engineers are doing the same math. They’re not being difficult and they’re not being lazy. They’re waiting to find out whether this makes them more valuable or less, and so far nobody has told them.
Tell them. Then teach them properly. The tooling part is the easy half.
If this sounds like your team, here’s how I run the training — hands-on, in your repository, on your real tickets. Happy to talk it through first and tell you straight whether training is even the right answer for where you are.
← All writing