Why Developers Push Back on AI: Who Owns the Failure?

“The assistant produced that feature in ten minutes.”

“Who checked the authorization logic?”

The second speaker can sound unenthusiastic. They may also be the person who will be paged if the feature exposes another customer’s data.

This imagined exchange captures a common problem in tool adoption: one person demonstrates the benefit while another inherits the uncertainty. Calling the uncertainty “resistance to change” makes the meeting easier and the decision worse.

Separate three different objections

An evidence objection says the claimed benefit has not been shown under relevant conditions. A demo on a small, clean project does not establish the same outcome in a mature codebase with undocumented constraints.

A responsibility objection says the process has no clear owner for verification, data handling, or failure. This can remain valid even when the tool is capable.

A habit objection says the current way is comfortable. Familiarity is not enough reason to reject a useful improvement, but unfamiliarity has a real transition cost. Training and time to experiment can address it more effectively than a declaration that everyone must embrace the future.

These objections need different responses. A presentation about model capabilities will not settle who is allowed to send repository content to an external provider.

Design a trial that could return “not here”

Choose a bounded task class: adding tests around well-understood code, drafting internal documentation, or implementing small changes with clear acceptance conditions. Establish what counts as finished before the trial begins.

Measure the whole path to an accepted change, including prompt preparation, review, corrections, and later defects discovered during the observation period. Record which tasks were selected and which were excluded. Otherwise the comparison may reward choosing easier work for the new tool.

Use a small enough trial that the team can inspect the results. A universal productivity percentage is less useful than knowing that a tool helps with one kind of task and creates more work in another.

Agree on stop conditions as well as success conditions. If the trial cannot conclude that adoption is presently unsuitable for the chosen work, it is a rollout with a predetermined verdict.

Review capacity is part of the system

Generated code can arrive faster than a team can understand it. That shifts the bottleneck from producing a patch to evaluating it.

The person generating the change should still be able to explain the behavior, point to the relevant tests, and respond to review. Passing the output to a senior colleague with “the AI wrote it” transfers work rather than removing it.

Managers can help by protecting review time and rewarding early discovery of problems. If only visible output is celebrated, careful verification becomes an invisible tax on conscientious people.

Take the uncomfortable questions seriously

Some concerns extend beyond the immediate trial: future staffing, deskilling, surveillance, or pressure to deliver at an unrealistic pace. A technical demonstration cannot answer organizational questions, and promises that nobody’s job will ever change are not credible evidence.

State what is actually decided, what remains undecided, and how developers can influence the process. A skeptical person may still choose to experiment when the boundaries are honest.

The aim is not unanimous enthusiasm. It is a decision grounded in the work, with benefits and responsibilities assigned to the same process. If adoption is worthwhile, it should survive a careful trial and a colleague asking who checks the authorization logic.