TL;DR
A few engineers decline AI coding tools while the rest of the team has adopted them, and the lead has to be fair to both groups. Ask each person what the refusal is about. Then write down what everyone’s work must meet, whatever tool produced it: the same review, checks, conventions, readable shared documentation and turnaround times. Tool choice can then stay personal, and it becomes a performance or role conversation only when evidence shows the agreed outcomes are being missed.
In this article
8 min read
Treat it as a question about the work and keep the tool out of the expectation. Agree in writing what every change must meet, whoever or whatever wrote it, hold everyone to that bar, and talk to each person who declines about their actual reason. Tool use turns into a performance or role question only when evidence shows the agreed outcomes are not being met, and in an employment relationship that step belongs with the line manager and HR, not with the team.
The same conflict, asked from both chairs
Two public questions show the problem from opposite sides. In July 2026 a manager on Reddit’s r/EngineeringManagers forum described inheriting a capable engineer in a hardware and measurement organisation who refuses all AI tools on ethical grounds. The team was moving to share knowledge through AI skill files instead of written notes, colleagues were absorbing analysis work the engineer did slowly, and leadership was fully committed to AI. The manager asked how to handle the objections and treat the person fairly.
In May 2026 a developer with about three decades in the industry asked on The Workplace Stack Exchange whether being made to work as an orchestrator of AI agents, after their employer was acquired, was a material change to the role that they could refuse without discipline. They were in the United Kingdom and asked for pointers, not legal advice.
A third, asked on Hacker News in January 2026, turns the hierarchy around: a team member wanted to convince a sceptical CTO and noted that the rest of the team was mostly not using AI or not saying so. When the stance is unclear, people hide what they do, in either direction.
Find out which refusal you are dealing with
“Refuses AI” covers several positions that need different responses, and survey data shows they are common. In the Stack Overflow 2025 Developer Survey, 16.2% of respondents said they do not use AI tools and do not plan to, and 45.7% somewhat or highly distrust the accuracy of AI output. In the 2024 edition, 25.5% named “not everyone uses them” as a challenge to their team adopting AI assistants; among the ethical responsibilities respondents selected, energy demand drew 36.3% and replacing jobs 34.1%. A March 2025 survey study by Akhoroz and Yildirim (arXiv:2503.16508) found that some programmers actively avoid LLMs out of a preference for independent learning, distrust of generated code and ethical considerations.
None of this tells you why your engineer declines, so ask, one to one, and listen before proposing anything.
Comparison
| Reason given | What the team can address | What it should not attempt |
|---|---|---|
| Ethics: energy, jobs, how models were trained | State what the role requires and what it does not; keep the agreement about outcomes | Argue the person out of a moral position, or make agreement a condition of respect |
| Distrust of output quality | Show the review and checks every change passes; invite them to review generated changes | Dismiss the concern; many adopters share it |
| Fear for their role | Say honestly what is changing in the job and what is not | Promise that nothing will change |
| A workflow that already works | Judge it by the same outcomes as everyone else’s | Require a tool for its own sake |
Write down what every change must meet, whoever wrote it
A fair position separates what the team needs from everyone’s work from how each person produces it. DORA’s page on a clear and communicated AI stance (last updated 12 January 2026) treats “is using AI expected?” and “is it clear which tools are permitted?” as separate perceptions, and reports that a clear stance reduces friction. A team can be that clear without mandating usage.
LLVM’s AI tool use policy (checked 9 October 2026) shows such an agreement in writing. It lets contributors use whatever tools they like, keeps the contributor as the author who is fully accountable for the contribution, and requires them to read and review generated code before asking others to review it. Every clause is about the contribution and its author, so it reads the same for someone who never opens an assistant.
A team version might say:
- Every change passes the same tests, checks and review, however it was produced.
- The author can explain the change and answers for it in review.
- Conventions are written down where everyone can read them, and the testable ones run as checks.
- Anything the team relies on to work together, including shared AI instruction or skill files, stays readable by a person without an assistant.
- Review turnaround and handover expectations are agreed as times or conditions, the same for everyone.
- Estimates are made by the person doing the work, for the way they work.
What stays personal: whether to draft with an assistant, which editor to use, how to look things up, and how much to delegate to an agent within the agreed rules. Executable checks are what make the first item believable. A rule that runs as a check holds a hand-written change and a generated one to the same standard, so nobody has to take anyone’s habits on trust.
Where an outcome agreement can still break
Outcome agreements can still go wrong, and the Reddit case shows two ways.
The first is the shared artefact. When a team moves knowledge out of written documentation and into AI skill files, a colleague who does not use the tools loses access to how the team works. Either the shared files are written so a person can read them as documentation, or the agreement says plainly that reading and maintaining them is part of the job. Both are defensible; leaving it unsaid excludes one person without anyone deciding to.
The second is load. If colleagues regularly pick up work a person does slowly, the adopters carry a cost that should be visible, and fairness applies to them as well. Record it as work redistributed, with the reason, so a later conversation can rest on what happened.
A third failure comes from measurement. Counting prompts, accepted suggestions or licence activity per person measures the tool use the agreement deliberately left personal; the case against activity metrics applies here too. In the Netherlands, an arrangement for facilities suited to observing or checking employees’ behaviour or performance needs the works council’s consent under article 27(1)(l) of the Works Councils Act, and introducing an important technological facility is an advice matter under article 25(1)(k). That is general information, not legal advice: check with HR before usage telemetry becomes a personal metric.
When a preference becomes a role conversation
A preference becomes a performance question when agreed outcomes are missed over a period set in advance and measured the same way for everyone: review turnaround, defects found after merge, missed commitments, work others had to absorb. If the outcomes are met, the tool choice is a preference and can stay one. If they are not, the conversation is about the outcomes, and the person sees the evidence and gets a chance to respond.
Whether an employer may require a new way of working depends on country, contract and role. In the Netherlands, employer and employee must behave as a good employer and a good employee (Civil Code article 7:611), and the employer must enable the training the job requires (article 7:611a). In Stoof/Mammoet (Hoge Raad, 11 July 2008), the court held that an employee should in general respond positively to a reasonable proposal linked to changed circumstances at work and may refuse only when acceptance cannot reasonably be required, while the assessment must not focus one-sidedly on the employee. A written clause allowing the employer to change terms on its own needs an interest weighty enough to outweigh the employee’s (article 7:613).
The AI Delivery Programme works on the shared side of this line. Over five weeks on one application, it writes the team’s conventions down with the engineers and turns the testable ones into checks that inspect the change itself, so the team agrees on what must be true of the work. It does not resolve an ethical or contractual objection, gives no employment advice, and is designed for teams that already ship with AI tools. Sales wait for Spine, the shared team view, which is being finished; no dates or fees are published. If that agreement is what your team is missing, explore the Programme and ask for a fit conversation.
Frequently Asked Questions
How should a lead handle engineers who refuse to use AI coding tools?
Hold everyone to the same written outcomes and leave the tool to the person. Keep the discussion out of team channels: a refusal debated in public turns into sides, while a one-to-one conversation can stay about the work.
How do I find out what a refusal is actually about?
Ask open questions about what worries the person and what they would need to see, then listen for the reason that actually decides it, which may differ from the first one given. If they are willing, a narrow trial on their terms, such as asking an assistant to explain code without writing any, can test a distrust objection. It should never be framed as a test of loyalty.
What should everyone share, and what can stay a personal choice?
A useful test is whether a colleague relies on it. Review standards, checks, conventions, shared files and turnaround times are relied on by others, so they are shared. The editor, the drafting method and whether an assistant writes the first version affect only the person doing the work, as long as the result meets the shared bar.
How can an outcome-based agreement still fail?
It fails when the outcomes quietly assume AI speed, for example when estimates or sprint commitments are sized for assisted work and imposed on everyone. It also fails in the other direction when large generated pull requests push review load onto colleagues; LLVM’s policy calls contributions that cost reviewers more than they return “extractive”. Check the agreement from both sides.
What evidence shows a refusal is affecting delivery, and who decides?
Evidence comes from the work, collected the same way for everyone: review times, escaped defects, commitments and redistributed tasks. Write the expectation and the review date down before you start measuring, so nothing is judged retroactively. The line manager decides, with HR, and the person sees the same evidence before any decision.
