AI is addictive, and managers are rewarding those who use it the most (even though they are shipping stuff they don’t understand). What a tangled mess. Let’s unpack findings from the AI Coding Addiction Report, what it says about the wayward use of AI coding tools, and how behavior differs based on whether you use Claude Code, Google Gemini, OpenAI Codex, or GitHub Copilot.

The survey targeted developers who use AI at least once a week, and the report is based on over 300 responses from developers of varying seniority levels and using different tools.

Animal mistreatment, applied to humans

A branch of psychology called behaviorism is based on trial-and-error learning. Edward Thorndike noticed that cats could learn skills to escape from puzzle boxes, but B.F. Skinner took it further. Skinner invented the “operant conditioning chamber”, a box that could be used to manipulate animal behavior by forcing it to respond to signals to earn rewards. If a rat or pigeon in the chamber hits a button when the light comes on, it gets food. If they fail to press the button, the electric grid in the floor delivers a punishment.

The ultimate result of this line of research was the creation of push-button slot machines, arranged in long rows, with flashing lights and occasional rewards for humans who drop coins in and press the button. In a business context, it shows up in gamification techniques, where managers treat employees like lab animals and are surprised when employees respond by acting like they are.

Intentionally or otherwise, AI coding tools seem wired like a Skinner Box. With coding loops delivering frequent flashing lights and rewards, 43% of developers hit home time but can’t tear themselves away from the reward-generation process. Overall, 80% of developers describe their relationship with AI as “more like a dependence than an advantage.” In fact, it’s harder to give up AI coding tools than to give up social media or video games, which are often colloquially described as “addictive.” This is why developers report skipping or delaying breaks, meals, and even bedtime.

What developers skip or delay during AI coding sessions. Source Coddy.

This leads us to ask some serious questions, like how much of the “AI productivity gain” comes from the behaviorism of keeping developers at the keyboard for longer hours with fewer breaks and less rest?

Differences by tooling

One interesting finding is that AI coding tool choice may influence at least some behaviors. Codex had the highest after-hours coding rate (62%), compared with lower rates for Gemini (45%), Claude Code (40%), and GitHub Copilot (36%). This could indicate that Codex most deeply embodies the stimulus/reward cycle of the Skinner box.

It could be illuminating to identify which specific aspects of these tools increase the likelihood of addictive coding loops spilling into the workday so that we can moderate their impact on personal time and crucial rest. As senior developers are most likely to work longer hours, organizations will end up with tired people making important decisions. This hustle has serious consequences, and none of them are good for the organization.

You’ll get more of what you reward

Meanwhile, managers quickly reward those who are most addicted. The heaviest AI users were more likely to get raises and promotions, even though 71% of developers shipped code they didn’t fully understand. Before AI, a developer copying and pasting code from Stack Overflow into their codebase was expected to understand and adapt the examples as part of the work. But now, managers are throwing cash at the developers glued so hard to the slot machine they can’t pause to visit the restroom, let alone assess the code they are committing.

With these heavy AI users getting the rewards, other developers are left to mimic the dysfunctional behavior, or at least give the impression of it. There’s a famous scene in the movie Shaun of the Dead where the band of misfit protagonists must cross a road infested with zombies. They achieve this by emulating the jerky movements and slurred speech of the infected. Developers who want to understand the code they commit will feel pressure to compromise when they see rewards going to the flippant.

Organizations must realize that software value comes from a series of good decisions. Hustle mode rapidly diminishes the rate at which decisions cross the threshold of “good”. The value is in gracefully solving user problems, but too many managers value software by the volume of features, code, or hours spent with their hands on the keyboard.

Look around you. The world is in a state of excess. There’s an avalanche of content, code, and crunch. We don’t need more; we need better.

The post Study: Developers are addicted to AI, and managers are making it worse appeared first on The New Stack.

Since they arrived on the scene, a great swathe of the software industry has pinned its hopes on AI tools, whether that’s early chat interfaces or modern agentic swarms. But the tone has shifted over the past few weeks, with HR software provider Rippling adding an anti-tokenmaxxing AI spend console to give CFOs and CTOs visibility into spend, and IBM Vice Chairman Gary Cohn saying last week that the ROI has “not been nearly as high as people might think.” As the northern hemisphere feels the Fall cooldown, it seems that Winter is coming for AI tool budgets.

As organizations balance the books, teams will start feeling pressure on their Claude Code and Cursor budgets. That means they may face harder usage limits where returns are unclear, or budgets that can’t sustain the usage levels.

For organizations that have figured out how to measure AI impact, there’s a growing realization that generating code volume at pace doesn’t guarantee movement in the metrics that matter. If you count lines of code, the number of pull requests, or even the number of features delivered, you’ll see no clear relationship to value. Not every line of code or feature matters equally to the business or its customers. This distribution is galaxy-wide.

Even at the output level, many organizations haven’t worked out how to turn siloed gains into end-to-end improvements. Gains in coding speed transfer to new tasks introduced by AI or get absorbed by downstream changes. If you haven’t worked out the inherent properties of value streams before you bought AI, you’ll be getting painful lessons when you try to track your ROI.

If the only problem were translating the cost of AI tools into end-to-end value, it would be serious enough. But something far worse is happening.

Productivity in terms of output

Let’s look at the data, which GitClear collected and analyzed for the Maintainability Gap report. The report, published in June, covers 623 million analyzed changes from 2023 to 2026. This is a substantial dataset, with millions of change operations included across three and a half years. As teams rapidly adopt AI developer environments and tools such as Cursor and Claude Code, GitClear’s code-change-operation database allows them to detect and classify code duplication, hotspots, and signals of good or poor code factoring.

Heavy AI users gained 25% on their own prior velocity, far from the claims of 10x increases. The same report shows those heavy users out-producing non-AI users by 4 to 10x, which sounds like the opposite finding until you look at who they are. Teams that outperformed their peers in output were doing so before AI tooling arrived. And remember, there’s no guarantee this output will accrue to the value stream, or provide meaningful value to the organization or its customers.

The first part of the ROI calculation is to determine whether these increases are worth the cost. For many organizations, I would be surprised if they were.

Perhaps because much of the discussion of AI tools has focused on speed, other factors have received little attention. The software industry may have found a different kind of value if it had focused on the tools as a forklift truck, rather than a racing car, because the straight-line speed doesn’t seem so impressive. Yet they can perform heavy lifts that are tricky for us mere humans, like large-scale changes across a codebase, such as replacing an unmaintained library with a replacement.

For those who pass this first gate, we can look at the next factor.

Productivity in terms of code quality

The shift to AI has brought about a giant behavioral change in the software industry. For several decades, the importance of code maintainability has been emphasized repeatedly. More than half the programming books on my shelf focus on architecture, code design, coupling, and cleanliness. The idea of refactoring, supported by automated tests, appears across many of these books.

Yet the signals GitClear is getting from the data are a complete reversal: a return to the code-and-fix era of software development. Across the dataset, block duplication rose 81% over 2023, from 40.3 to 73.0 per million changed lines. Those multiple expressions of the same concept drift apart and create whack-a-mole bugs. Moved code, the signature of refactoring, fell from 21% of changed lines in 2022 to 3.8% in 2026, which means code is becoming harder to understand, and that will hit maintainers with or without AI.

When you make these changes, you get away with it initially because you’re early in the maintenance cost curve. Over time, however, the rising costs will become unbearable. Rework rates will rise, stealing time from new feature development. Seemingly minor issues will take far too long to pinpoint and resolve, with many simply becoming part of how it works because the fix is economically unviable. The accumulation of tightly coupled, incomprehensible code units will reach the point where the software stops being valuable.

We’ve been trying to validate the claims of 10x boosts with AI coding assistants. The data shows the opposite. Before AI, developers chose refactoring over copy-and-paste about two to one. Now they’re roughly five times likelier to copy and paste.

Technical practices are the mission, not a side quest

When I’ve presented at conferences and user groups on what great software delivery looks like, I mention, among other things, test automation and refactoring. In the Q&A that follows, this question will inevitably come up in one form or another: “How do I get permission from my boss to do these things?”

Developers are whipped hard for fast progress, so they are trained to avoid what they see as the side quest. If they need to increase output, they streamline coding tasks, leaving no time to write tests or improve the code’s design, which would delay the feature. Inevitably, this makes all feature development vastly slower over time.

The premise of lightweight software delivery processes is that they rely on technical practices that control the cost of maintaining software over time. The wisdom is that working more deliberately today lets us maintain the pace of change indefinitely. If we skip these practices, change becomes increasingly slow and expensive.

Those technical practices, like test automation and refactoring, aren’t side quests; they are the work. Technical discipline is a fundamental requirement of commercial software delivery, and these practices stopped being optional some time ago.

When asked for techniques to convince managers to allow these practices, I’m confused. I’ve never asked for permission to do what is right for me, the software, its users, and the organization. No compromise can be reached, because omitting technical practices harms everyone involved.

This “side quest” thinking was unresolved in many organizations, and adding AI into the mix has made things far worse. When teams are given AI tools, they come with the expectation of a big return. When teams are, in reality, seeing a 25% increase in their rate of change against an industry misperception of some 10x boost, they will feel even more pressure to deliver.

Under these dysfunctional circumstances, it’s no wonder those who treat good practice as a side quest are skipping crucial steps.

Real high performance is well known

High-performing teams have worked out that a set of software delivery practices is no longer optional. They worked it out because they were scaling long before the new tools arrived.

For software that matters, that people depend on, and that still needs to exist in a year, in five years, and beyond, we’ve moved from the pick-and-mix of the past, and there’s a new bar for professional software delivery.

There is a glimmer of hope here. The teams doing well with AI are the same teams that outpaced the industry before AI. They maintain rigorous technical disciplines, monitor code health indicators, and prioritize the craft of keeping code maintainable for the long haul.

The post Your AI coding spend bought 25% more output. Duplication rose 81%. appeared first on The New Stack.