Developers are often assumed to resist AI because they fear it will take their job, that using it means training their own replacement. That is not quite right. What is happening is that AI has changed, permanently, what the job of a developer is. And not every developer is, or has to be, okay with that.

A 2024 peer-reviewed study backs this up: developers’ concerns centre less on job loss and more on how AI reshapes the work itself. The market data agrees. In 2025, 84 percent of developers were using or planning to use AI coding tools, yet only 33 percent trusted the code those tools produce, according to the same survey. Adoption is rising. Trust is falling. That gap is the real signal, and it has nothing to do with job security.

Traditional coding is hands-on. Developers solve problems, shape architecture, write code, debug, and make technical decisions directly. That is the part most engineers enjoy. AI-assisted coding moves the developer up a level: instructing, reviewing, correcting, and orchestrating AI agents rather than writing the code themselves. That is not necessarily a downgrade, but it is a different job, and many programmers did not become programmers because they wanted to manage other programmers, even artificial ones.

The psychological mechanism behind the resistance is similar to what happens when you ask one coder to supervise another. It requires a different type of effort. Each developer has their own preferred work style and may feel that writing the solution themselves would take less effort than reviewing, explaining, and refining someone else’s work. AI creates a similar dynamic. The developer now has to define tasks clearly, supervise execution, validate the output, accept accountability for code they did not personally write, and operate at a higher level of abstraction. For some people this is exciting. For others, it removes the part of programming that gives them energy.

AI is not like other programming skills, either. Learning a new programming language, such as moving from Java to Python, is still recognisably “coding.” It preserves the same underlying craft. But AI alters the developer’s workflow and what their job actually “is.” That is why some engineers who are perfectly happy to learn new technologies may still resist AI. They are not resisting change in general. They are resisting a move from maker to orchestrator.

This means companies should be careful not to frame AI adoption only as an efficiency initiative. Saying “AI will save you time” may not address the real concern. The issue is not only productivity, but also professional motivation, ownership, accountability, and identity. A better framing would be that AI does not simply make coders faster; it changes where human creativity sits in the process. The opportunity is to help engineers move from writing every line of code to designing better systems, asking better questions, validating better solutions, and making higher-level product and architecture decisions.

But this transition needs to be managed deliberately. Not everyone will naturally enjoy it, and not everyone will be good at it immediately.

It is also why the “1000x developer” – the top 1-2% of hyper-skilled engineers – is so often misdiagnosed as a skill category rather than a character trait. What separates them is not technical range. It is the willingness to let go of hands-on coding and be measured on outcomes, whether what they are managing is a group of people or a group of AI agents.