Eighty percent of developers say AI coding tools feel more addictive than useful

Quentin Rousseau, co-founder and CTO of Rootly, posted on LinkedIn that he found himself at 02:47 watching Claude Code refactor a module — no deadline, no incident, no way to stop. "Agentic coding is addictive," he wrote. "When the agent succeeds you get dopamine; when it fails you get adrenaline." Rousseau said he eventually sought medical help. His description captures the core mechanism: watching an agent work is passive enough to feel like rest, yet active enough to keep you in the loop.

A Coddy Tech survey of 305 developers sharpens the picture. Four out of five respondents (80%) reported that using AI feels more like dependence than advantage. 43% keep coding with the tools after hours even when they intended to stop. 32% delayed sleep to continue. 39% said the tools make it harder to disconnect from work. On the other side, 74% said intensive AI use increased their chance of a raise or promotion, while 51% said it also increased their risk of burnout. The organizational incentive and the personal cost are moving in opposite directions.

Stack Overflow's 2025 developer survey adds a technical layer. 45% of respondents described frustration with answers that are "almost right, but not quite" — output that looks convincing but generates difficult debugging work. Tool adoption kept climbing to 80% of developers, but trust in accuracy fell from 40% in previous years to 29% this year, and overall positivity toward AI dropped from 72% to 60%. Researchers call the gap "verification debt": code arrives faster, yet the developer remains stuck checking correctness, security, maintainability, and fit with the existing architecture, including edge cases and production implications.

The problem intensifies when organizations start treating AI as a capacity multiplier. If management expects each developer to ship several times more features, the pressure to stay in the endless loop of "one more implementation, one more refactor, one more optimization" becomes an implicit requirement. The tools do not replace the need to understand requirements, spot architectural conflicts, or take responsibility for code running in production; they only compress the time between generating output and discovering whether it actually works.