AI Made My Work Addictive

The most profitable machine ever designed is the slot machine. The jackpot barely matters. Most players know the odds. What keeps them pulling is a particular pattern in how rewards are delivered, one that B.F. Skinner identified decades ago: variable-ratio reinforcement, a schedule where the payoff arrives at unpredictable intervals. The player cannot determine which pull will pay out, so every pull feels like it could be the one. The unpredictability sustains the behavior far more effectively than the prize ever could.

I have been inside this mechanism since the early days of Copilot. Through GPT-3.5, when the workflow was copying chunks of code into a chat window and pasting the results back. Through every generation since, as the tools got better and the sessions got longer. By early 2025, somewhere around 90 to 100 percent of the code I was shipping was AI-generated. I am writing this in 2026, and the pattern has only deepened. I work with AI from the time I wake up until I sleep, and I am fully aware that this is the case, which has done remarkably little to change it.

The Slot Machine You Built Yourself

If you have spent real time with these tools, you know the texture of the experience. Sometimes the model produces exactly what you need, clean and well-structured, and there is a quiet satisfaction in having directed something powerful toward a precise result. Sometimes the output is nonsense and you discard it without thought. But the characteristic output, the one that defines the relationship between builder and tool, is neither of those. It is almost right. The layout renders but the spacing feels slightly off. The optimization works but you can already see how the naming conventions would read better one abstraction level up. The component is functional but the animation easing is just a hair too aggressive, and you know exactly how to soften it.

And this extends well beyond code. When I use AI to design a UI, the same loop takes over. The hierarchy is almost right but the visual weight needs redistributing. The color palette works but the contrast ratio on one secondary element could be tighter. When I generate graphics, marketing assets, diagrams, the output is always improvable in ways I can see clearly and articulate precisely. The AI takes on the cognitive load of execution, which frees me to direct, but directing toward perfection is a game with no natural endpoint. Each generation inches the work forward, sometimes dramatically, sometimes by a pixel, and occasionally sideways in a direction I hadn't considered but now want to explore. The gap between where you are and where you want to be is always visible, always specific, and always appears closable with one more attempt.

Here the analogy with gambling sharpens into something I recognized from a different context. I studied behavioral reinforcement schedules years ago, the kind of research that explains why casinos are designed the way they are. Schüll's ethnography of Las Vegas machine gambling. Schultz's dopamine prediction error work. The findings are well established: the near-miss produces a stronger urge to continue than a clean loss, the brain generates stronger responses to unpredictable rewards than to predictable ones, and casinos have been engineering around these mechanics for decades. I never expected to recognize the same pattern in my own work sessions at 2am on a Tuesday, fully aware of what was happening and completely unable to close the laptop.

A slot machine's near-miss, though, is abstract. Two cherries and a lemon is an arbitrary arrangement of symbols. When an AI coding tool delivers a near-miss, you can see the exact delta between what you got and what you need. You can point to the three lines that would close the gap. The near-miss stops looking like chance and starts looking like signal. "One more try" stops feeling like gambling and starts feeling like engineering, which is exactly what makes it so much harder to recognize as compulsion.

The mechanism is the same. The camouflage is better.

What Friction Was Actually For

Once that loop takes hold, a subtler problem emerges: the disappearance of every cue that used to tell a developer when a unit of work was complete.

Software development has always had a rhythm imposed by its own resistance. Compilation took time. Test suites ran for minutes. Code review required waiting for another person to read what you had written and respond. Debugging meant tracing logic by hand, slowly, with the kind of sustained attention that naturally exhausted itself. These were the pulse of the work, small embedded signals that a piece was finished and it was time to assess, reconsider, or stop. The friction served as a metronome.

AI tools eliminated the friction, and with it the rhythm, and with the rhythm the stopping cues. The session becomes continuous in a way that programming sessions never were. There is no natural " hand" in this game the way there is in poker, no forced pause between rounds where you look at your stack and decide whether to keep playing. The developer still at it at 2am has plenty of discipline. The environment has simply been stripped of the structures that once made stopping feel like a natural transition rather than an act of will. When every pause has been engineered out, continuing becomes the default and stopping becomes the thing that requires a decision.

The Work That Never Turns Off

This pattern extends beyond a single session. It reshapes the structure of an entire day.

The boundary between work and non-work has always served a cognitive function that its critics underestimate. The hours away from the screen are where slow background processing happens, the kind that turns accumulated experience into judgment. The walk after lunch. The commute home. The half-hour of staring at nothing while the mind quietly rearranges pieces of a problem you stopped consciously working on hours ago. Integration happens here, and intuition is built here. It requires disengagement, and it requires the absence of guilt about disengaging.

AI dissolves that boundary from the inside. Agents continue running overnight. Pull requests accumulate while you sleep. The machine generates output in your absence, which fundamentally changes the perceived cost of rest. Stepping away begins to feel less like recovery and more like waste, because something is being produced somewhere and you are choosing to ignore it. The pressure is subtle and it operates through guilt as much as ambition: the diffuse guilt of choosing to stop iterating when iteration is always available, and being unable to determine whether that choice reflects self-awareness or negligence.

When the work never pauses, the integration never happens. Judgment degrades in ways that remain invisible until something breaks. You make worse architectural decisions. You lose the ability to distinguish between progress and motion. You ship more and understand less, and the metrics reward the shipping.

The Load Moved Upward

Beneath the compulsion loop and the vanished stopping cues, there is a quieter structural shift that may matter more than either. I can trace it in my own trajectory.

In the early days, when I was copying code into GPT-3.5 and pasting results back, the mistakes I made were at the functional level. Connections between modules that didn't hold. Dependencies that conflicted. The internalization required to catch these errors was manageable because the scope of what the AI was producing was small. As the tools improved and the output grew, the level at which I needed to internalize the work kept rising. The mistakes stopped being about functions and started being about features. About architectural decisions. About whether the system I was directing the AI to build was the right system to build at all. The responsibility surface expanded with every generation of tooling, and the cognitive cost of staying on top of it expanded in lockstep.

What used to be sustained focus within a single mode of work has become high-frequency alternation between directing, evaluating, and course-correcting. I am simultaneously the architect, the product manager, the reviewer, and the person deciding when something qualifies as done, often within the span of a few minutes. The productivity gains are visible and real. The volume of judgment calls required per hour has also increased in proportion, and judgment is the cognitive resource that depletes fastest and recovers slowest.

What Changed

Nobody set out to design an addictive tool. That is partly what makes the pattern difficult to see. The compulsion is an emergent property of removing every natural pause from a process that used to have dozens of them, while making the reward unpredictable enough to keep the builder reaching for the next iteration. The friction that once structured the work was the scaffolding that made good engineering sustainable, and it was removed without anyone noticing what it held up.

What makes this moment particularly disorienting is that the structures surrounding the work have not caught up. Sprints still assume the old rhythm of write, test, review. Code review processes still assume a human wrote what they are reading. Team sizing and capacity planning still assume the old relationship between effort and output. The organizational scaffolding was built for a world where friction existed, and it quietly depends on that friction to function. The friction is gone, and the scaffolding is still standing, but it is load-bearing nothing. We are in a transition state where the old structure persists in form while the reality underneath it has already shifted, and most teams have not yet noticed the gap.

I should note that software is simply where this is most visible right now, because the tooling matured here first. Before I was building software, I was a theoretical physicist. I spent years working through equations, ideating on models, wrestling with the kind of problems where you stare at a derivation for hours and the insight arrives sideways. When I think about what these tools would have meant in that context, the answer is obvious: the same thing. The compulsion loop would have been identical. The almost-right formulation that needs one more term. The model that nearly fits but the boundary behavior is off and you can see exactly where. The 3am conviction that one more pass through the algebra will close the gap. The mechanism has nothing to do with code specifically. It has to do with any work where AI absorbs the execution load while leaving the human to direct, evaluate, and refine. Software is the canary. Every field where AI begins taking on cognitive labor will encounter this same pattern, likely sooner than expected.

Whether this is something the tools amplify in a person or something they create from scratch, I genuinely do not know. I notice it in myself. I notice it in engineers I work with. I do not yet have enough distance to determine whether the compulsion was always latent and the tools simply found it, or whether the tools manufactured something new. That distinction matters, and I suspect the answer will shape how seriously we take what comes next.

That gap between the old structures and the new reality, and what it means for how teams, organizations, and the craft itself need to be rebuilt, is where this series goes next.