Surf explains why teams sabotage AI implementation in product development

Surf executives described a typical scenario in which teams adopt AI in development: from sharp denial to working equilibrium. The main idea is that failures in implementation are often linked not to the quality of Copilot, ChatGPT, or Claude, but to how managers work with people's resistance.

Not in the Technology

The article's authors suggest viewing AI implementation as a management task, not only a technical one. According to their observations, the same model in one company delivers acceleration and cost savings, while in another it causes silent sabotage, token usage, and frustration. The difference emerges at the moment when an experienced developer stops being just an executor and must master a new role: setting the task for the machine, checking the result, and making a decision, even if the decision looks different from how he would have done it. This shift in role strikes at professional identity.

For some specialists, value was long built around personal skill: write code by hand, hold context in your head, make quick local decisions. When AI starts doing a piece of this work, the reaction is often perceived not as interest in a new tool, but as a threat to accumulated expertise. This is particularly painful for strong performers who are used to proving value through the quality of their own craft and are not ready to immediately switch to orchestrator or reviewer mode.

Five Stages of Acceptance

Surf links the team's reaction to the logic of stages of change acceptance, familiar from the Kübler-Ross model. The authors do not claim to present an academic typology, but consider it a convenient practical framework for managers and leads. It helps distinguish normal adaptation from sabotage and understand at what point a person needs not another call about the benefits of AI, but concrete support, error analysis, and a safer format for mastering a new tool.

• Denial. A developer tries AI with the assumption that they will quickly prove its uselessness, and after the first failure concludes about the technology, not about their approach.
• Anger. If colleagues succeed, the desire emerges to devalue someone else's result and prove that this is not real work, but a dangerous imitation of quality.
• Bargaining. For the first time, the thought arises that the problem may not be in the tool, but in how a person uses it; this is the best point for mentorship.
• Euphoria. After the first successes, the pendulum swings the other way: it seems that now almost everything can be automated and one can take on extra promises.
• Equilibrium. AI ceases to be either a threat or magic and becomes just a working tool with clear boundaries.

"This doesn't work, and I'll prove it to you right now."

The authors separately highlight an intermediate state where a specialist already sees the successes of others, but instead of correcting the process begins to doubt themselves. This mode doesn't always look like direct resistance, but also slows down implementation: the person fears making mistakes, loses energy, and falls into simulating usage instead of real practice. For a manager, this is an important signal: not every weak result means hostility, sometimes the team simply lacks safe feedback and a clear way to learn from mistakes.

How to Implement Carefully

The main practical conclusion for managers is not to launch AI across the entire team at once. Simultaneous mass implementation amplifies both denial, anger, and euphoria, and the manager physically cannot take everyone through this cycle. Instead, Surf advises piloting not the technology, but people: choose those who are already open to experiments, give them suitable tasks, and support them at the points where errors, failed expectations, or overestimation of possibilities usually occur.

The authors also remind that without a safe learning environment, learning won't take off. If the team immediately punishes or publicly ridicules any rough result, employees won't honestly master the new tool. They will start hiding mistakes, pretending progress, or silently sabotaging the process. That's why a healthy work environment is not an HR slogan here, but a direct condition for the appearance of the first working cases on which to build internal expertise and gradually change the attitude of the rest of the team.

Another important point concerns internal leaders. A few notable examples are enough for the rest of the team to start perceiving AI not as a top-down trend, but as a real way to work faster or better. Such an example reduces resistance better than mandatory regulations, presentations, and license purchases without a clear application scenario. When success is visible nearby, the technology stops being an abstraction and becomes a working argument within the team.

What It Means

For companies, this is a useful reminder: implementing AI in development is not buying another tool, but restructuring roles, habits, and criteria for value within the team. Those who win are not those who faster formalized licenses, but those who managed to take people through resistance without breaking their motivation and turn interest in AI into a sustainable work practice.