Should you mandate AI coding tools? What to do when your engineers are split

Should you mandate AI coding tools? In our judgment, no. Don't mandate the tool and don't set usage targets. Mandate the outcome bar (review, tests, a cost line) for everyone, run a funded pilot with a stop date, and state your AI stance when you hire engineers and when you brief agencies. The rest of the team-shape questions sit in our engineering management guides for CTOs and VPs of Engineering.

How many engineers actually refuse AI tools?

Far fewer than half, and the data is worth reading before you set policy.

In Stack Overflow's 2025 Developer Survey, 84% of respondents use or plan to use AI tools, up from 76% the year before. Among professional developers, 14.7% answered "No, and I don't plan to." Among all respondents it was 16.2%. Daily use among professionals was about 51%.

Adoption is high, but trust isn't. In the same survey, 46% of respondents distrust the accuracy of AI output (somewhat or highly) and 33% trust it. Only 3.1% highly trust it. Favourable sentiment sits near 60%, down from above 70% in the 2023 and 2024 surveys. 66% cited output that's "almost right" as a frustration, and 45.2% say debugging AI-generated code takes more time.

In our judgment, your team probably isn't split between users and refusers. It's split between people who use the tools and verify everything, people who use them and don't, and a smaller group who've opted out. Those need different responses, and a single mandate treats them the same.

Why do they refuse, and are they wrong?

LeadDev's September 2026 piece on developers rejecting AI gives reasons that include craft, comprehension of their own code, skill erosion and ethics. One developer featured, Chalupa, used AI for about 18 months after his employer mandated it, then stopped. A CTO left after a founder banned hand-coding. These are reported accounts, not data.

The measured evidence is mixed in a useful way. METR's 2025 study followed 16 experienced developers across 246 tasks in their own repositories. They were 19% slower with AI, though they'd forecast a 24% speedup and still believed they'd gained 20% afterwards.

METR's February 2026 update is weaker evidence, and METR calls its own data "only very weak evidence for the size" of the uplift. It covered 57 developers and over 800 tasks. The estimate was an 18% slowdown for the original developers (confidence interval from 38% slower to 9% faster) and 4% for new ones (15% slower to 9% faster). Both intervals include zero. 30-50% of developers said in surveys they skipped some tasks because they wouldn't do them without AI, which skews what gets measured, and METR is redesigning the study.

Both camps have evidence, and neither settles your codebase. DORA's 2025 report frames AI as an amplifier of what an organisation already does well or badly, with the greatest returns coming from the underlying system rather than the tool. In our reading, a mandate on a team with weak review habits would amplify them.

If you're deciding based on a published speedup number from either direction, you're deciding on someone else's repo.

Mandate, optional pilot, or change who you hire?

This is our judgment, not a study result. The three options aren't exclusive, and the third is the one most leaders skip.

Option	Use when	Cost	Main risk
Mandate the tool	A deadline forces coordinated change, you fund the learning time, and you've said how you'll judge it	Slower delivery and slipped dates while people learn; licence spend for everyone	Usage numbers become the goal; resisters leave or comply on paper
Optional with a funded pilot	You don't know what the tools do on your codebase	One cohort's time, a licence budget, someone to measure	Pilot drags on; volunteers aren't representative
Change the hiring and vendor ask	You expect the split to persist, or you're adding people anyway	Longer job posts, a few interview questions, contract wording	Narrows the candidate pool if the stance is stated badly

Charity Majors makes the strongest case for a mandate in her July 2026 post, "In defense of AI mandates." Her argument is that a mandate is a way to fund change. You accept the slowdown, the cost and the slipped deadlines, you name what you're deprioritising and how you'll judge whether it was worth it, and you treat forcing as a last resort. That's a fair test. A mandate that arrives with a usage target and no schedule relief fails it.

We found no study of attrition caused by mandates, so we won't give you a rate. What you can see for yourself is who's refusing. If it's the engineer who owns your payments service, the risk is concrete. If one does leave, our guide on what to do when a senior engineer resigns covers the first 48 hours.

How to run an AI coding pilot

Run it as an experiment you can lose.

1. Pick one cohort and fund its time

Pick one team or a mixed group of volunteers and skeptics. Give them licences and explicit time to learn, and move their deadlines. If you don't change their schedule, you've run a mandate and called it a pilot.

2. Set one shared bar for everyone

Everyone, user or not, meets the same standard: code review by a named human, tests passing, and the author able to explain every line they merge. The tool is a personal choice. The bar isn't. Watch reviewer time as well as author time, since review is where extra output lands (our judgment). The method for comparing cohorts is in how to measure AI coding tools ROI.

3. Write a stop rule and a decision date

Write down before you start what result would end the pilot, what would extend it, and the date you'll decide. A sensible stop rule might be "defect escape rate rises or review queues grow past an agreed limit." The thresholds are yours to pick, and we don't have a benchmark for them. That's a judgment call, and it keeps the pilot from becoming policy by drift.

4. Ban usage targets

Don't count prompts, tokens or accepted suggestions per engineer, and don't publish a leaderboard. In our judgment, usage metrics reward the wrong behaviour. Targets turn a signal into a quota.

What to screen for in interviews

In our judgment, you should state your stance in the job post. A candidate who finds out in the final round that the company is all-in on AI, or bans it, will either withdraw or say what you want to hear. LeadDev's piece includes Jared White, a freelancer who missed out on a full-time role after the interview showed the company was all-in on AI. That's one account, but it's a cheap mismatch to avoid.

Then score verification, not tool use. Four questions we'd use:

Tell me about the last time an AI suggestion was wrong. How did you find out?
What do you check before you merge code you didn't write yourself?
Show me how you'd review this diff, then tell me which parts you'd distrust if a model wrote it.
Where do you not use AI, and why?

A candidate who refuses all AI use but reasons clearly about review is a different hire from one who pastes output without reading it. The second risk is larger than the first in our judgment. For the exercise itself, see how to run a coding interview where candidates can use AI. It covers the rubric.

What to ask a contractor or agency about AI use

Your policy covers your employees. It doesn't cover the engineers an agency puts on your codebase unless you write it into the engagement. Ask these before you sign:

Which AI tools do your engineers use on client work, and is that a firm-wide rule or each engineer's choice?
Does client code or data go to those tools, and under which plan and retention terms?
How do you review AI-assisted code before it reaches us?
Will you name any AI use that's outside our list?

Then put your list in the contract: approved tools, data handling, review requirements. If the answer to the first question is "we don't track it," in our judgment you've learned something about their review process. Our guide to contractor and external engineer rules covers the contractor rules to copy into an engagement.

What this means for your team shape and hiring bar

Decide three things this quarter. First, drop any plan for tool mandates or per-engineer usage targets, and replace it with a written outcome bar that applies to everyone. Second, fund one pilot with a stop rule and a decision date, and budget for the review load it creates. Third, change what you say outside the team: put your AI stance in the next job post, add the verification questions to the interview loop, and put an AI clause in every agency or contractor engagement.

The facts behind this are modest. Most developers use or plan to use the tools, trust is low, DORA says outcomes depend on your system, and METR's own latest numbers are too uncertain to justify forcing either way. The rest is our judgment. If your best engineer is the one refusing, a mandate costs you more than the pilot would.

Next, read why token targets mislead before anyone proposes a usage dashboard.

Frequently asked questions

Can you require engineers to use AI coding tools?

Whether you can require it, and how, depends on your country and your engineers' contracts. This isn't legal advice; ask employment counsel before you write it into terms. The better question is whether you should. A requirement without schedule relief and a way of judging results can, in our experience, produce compliance on paper.

Will engineers who refuse AI tools fall behind?

Maybe, maybe not, and the evidence doesn't say. METR's two studies don't show a reliable speedup for experienced developers on their own repos, and the later one has intervals that include zero. A refuser who reviews carefully may be as productive as a heavy user. Check output against your shared bar rather than the tool they choose.

Should AI usage count in performance reviews?

We'd say no. Review outcomes: quality, delivery, review contribution. Usage counts invite gaming and punish people who judge correctly that a task doesn't need the tool. If you want adoption data, collect it at team level for the pilot and keep it out of individual evaluations.

What if my best engineer refuses?

Ask why before you decide anything. If the objection is verification or trust, the shared bar probably addresses it. Trust in AI output is low across the survey (46% distrust), though it doesn't ask why individuals opt out. If it's a matter of principle, let them stay out of the pilot, hold them to the same bar, and revisit at the stop date. In our judgment, forcing the issue with your strongest engineer is the highest-cost version of this decision.