FOR THE LOVE OF MAKING IT
Discipline is All You Need // A three-part essay by Peter Urban
When the Engineer Becomes the Experiment
When a developer opens an AI coding assistant and types a prompt, this is what happens.
Sometimes they get an elegant, appropriate working solution in seconds, a small miracle on the screen. The feature works. Let’s ship it. Jackpot!
Sometimes they get plausible-looking garbage. Code that compiles, appears reasonable, and wastes three hours before someone discovers it doesn't actually do what it's supposed to do. A near miss, keep going!
Sometimes they get something that works today but contains a subtle flaw. A logic error, a security gap, an implicit assumption about the production environment. Something that won't surface for weeks or months.
Gambling researchers at the University of Waterloo, studying how slot machines sustain play, identified a precise term for this kind of outcome: a loss disguised as a win. The machine celebrates with lights and sounds, the player feels the rush of victory, but the payout is less than the wager. Simply, the player lost, yet the machine told them they won. In AI coding, the equivalent is code that compiles, passes basic tests, and ships, but contains assumptions or design flaws that cost far more to fix than the time it "saved."
Most critically, the developer never knows what prompt will produce which outcome. This is multiplied by the fact that frontier AI models constantly shift, often driven by continuous A/B testing or updated training. The outcomes from the same prompts often change dramatically over time.
This is a variable-ratio reinforcement schedule running in real time on your engineering team or on whoever does knowledge work in your organization. The prompt is the lever, and like every lever connected to a variable-ratio schedule, pulling it doesn't feel like compulsion; it feels like choice. The developer crafts the prompt, adjusts the context, and then selects which files to include. The work feels effortful and deliberate, and the occasional spectacular win, that moment where the AI produces something genuinely impressive, is exactly what keeps the lever being pulled. One more try. One more prompt. This time it'll work.
The practitioners confirm it from direct experience
Jeremy Howard is a deep learning pioneer, a Kaggle grandmaster, and someone who has written software for over forty years. He uses AI coding tools daily and in a detailed interview on the Machine Learning Street Talk podcast, describes the experience in terms that should alarm any leader. "The thing about AI-based coding is that it's like a slot machine. You have an illusion of control, but in the end you pull the lever." He reports fourteen-hour marathon sessions that inevitably leave him completely drained, with the output often not justifying the effort.
Rachel Thomas, Howard's partner and co-founder at fast.ai, went even further. She systematically mapped the defining features of gambling addiction onto AI coding workflows. The illusion of control, the unpredictable reward, the losses disguised as wins. The inability to stop despite diminishing returns. Every single feature was present.
These people aren't critics of AI technology in general. They're among the technology’s most accomplished users. They're describing, in precise terms, the behavioral signature of Skinner's variable-ratio schedule operating on experienced engineers.
The METR data confirms what the practitioners report. Anthropic's own research tells the rest of the story, and in this case, it's their own engineers raising the alarm. In their internal workforce study, through analyzing hundreds of thousands of AI coding sessions, Anthropic found that engineers were delegating increasingly complex tasks to AI while providing less human oversight with each passing month. The consequences went beyond basic workflow changes. Engineers reported that AI had become their "first stop," reducing key success practices such as peer collaboration, mentorship, and the informal knowledge transfer that happens through code reviews and engineering discussions. Senior engineers identified what they called a "paradox of supervision." Effectively using AI requires oversight, but oversight requires the very skills that atrophy when AI does the work.
In a separate controlled study, Anthropic found that developers who delegated coding to AI scored seventeen percent lower on comprehension, code-reading, and debugging assessments, with the steepest decline in the ability to identify when code is wrong and why. The tools weren't just changing how engineers worked. They were eroding the skills engineers need to judge whether the tools' output is sufficiently precise and capable in structure, functionality, and overall quality.
Jeremy Howard, in the same interview, summarizes the industry-wide picture with characteristic candor. "No one's actually creating 50 times more high-quality software than they were before. We've actually just done a study of this and there's a tiny uptick. Tiny uptick, in what people are actually shipping."
The gap between perceived productivity and actual productivity, that thirty-nine-point delta the METR study uncovered, is not a minor discrepancy; it is the telltale signature of a variable-ratio reinforcement schedule at work. It is a system that rewards the feeling of progress so effectively that the people inside it lose the ability to distinguish feeling from fact.
So the mechanism completes its migration, from the lab to the casino floor, where it extracts money, to social media, where it extracts attention, into the place where your organization actually creates value. The place where systems are designed, problems are solved, and the work that justifies your entire operation gets done. What it extracts here isn't money or attention. It's understanding.
Flow and Its Shadow Brother
The addiction analogy only takes us partway. The greater danger isn't about compulsive behavior. It's about what happens to the engineer's capability while they're absorbed in the prompting loop. To see it, we need to look at a state most leaders have already experienced and recognize, at least on the surface..
I am talking about "flow," which can be defined as the mental state of deep absorption where time disappears, self-consciousness fades, and your best work happens. The psychologist Mihaly Csikszentmihalyi spent decades studying it. His research, replicated extensively, established that achieving genuine flow requires three preconditions.
Clear proximal goals. You know exactly what you're trying to accomplish in the immediate next step. Not a vague aspiration, but a specific target.
Immediate, interpretable feedback. You can tell, in real time, whether what you just did worked. You have the knowledge to understand why it worked or didn't.
Challenge-skill balance. The task stretches your current ability without overwhelming it; you're operating at the edge of your competence.
When all three conditions align, something remarkable happens. You enter a state of deep absorption. Hours vanish, action and awareness merge, and performance peaks. The part most people miss is that the person emerges from flow more capable than when they entered it. Flow isn't just peak performance; it is peak learning. The two are inseparable; every flow session makes you slightly better at the thing you're doing.
Think of a pianist performing a piece at the edge of their ability. The goal is clear. Play this passage. The feedback is instant; they can hear whether it sounds right. The challenge matches their skill, and with every session in full flow, they become a better pianist.
Traditional software development, done well, is almost perfectly structured to produce flow. The developer defines a clear goal: Make this function work, pass this test, or implement this feature. The feedback is immediate, the code compiles or it doesn't, the test passes or fails. The developer tunes the challenge-skill balance themselves by breaking problems into pieces they can reason out fully. This is why programmers describe their best coding sessions in terms that match Csikszentmihalyi's framework exactly. Time vanishes, they feel challenged but in control, and they come out the other side having built something they deeply understand. It's one of the most productive states a human can enter, which is precisely what makes its counterfeit version so dangerous.
Dark flow enters the game
In 2017, researchers at the University of Waterloo, Dixon, Stange, and colleagues, formally identified a state they called "dark flow." They found it in gambling. Dark flow shares nearly all the subjective markers of productive flow. Time distortion, deep absorption, loss of self-consciousness, intense focus, and freedom from distraction. To the person experiencing it, the two states feel almost identical.
But the structural preconditions are different, and the outcomes are the opposite.
In dark flow, goals are ambiguous. Keep playing, keep pulling, keep going. Feedback is opaque or actively misleading. Slot machines are specifically designed to produce outcomes that feel like winning but are actually net losses. The challenge-skill balance is absent because the outcome is determined by a system the player doesn't control. They are systems whose outputs are unpredictable by design.
The gambler feels absorbed, productive, even exhilarated. But they're not growing, nor building competence. They emerge depleted rather than energized and elevated. This is critical; the absorption itself impairs their ability to notice the difference, because dark flow, like productive flow, suppresses self-consciousness and reflective awareness.
You've experienced dark flow yourself. It's what happens when you sit down to "quickly check" something on your phone, to look up and discover two hours have vanished. It felt engaging, and active, but nothing was built, nothing was learned. You simply consumed; you didn't create.
Lay AI-prompted development against both patterns, and the mapping becomes clear.
Traditional, human programming satisfies all three flow preconditions; goals are clear and specific, feedback is immediate and interpretable, because the developer wrote the code and understands the problem. The challenge-skill balance is real; the developer is operating at the edge of their own competence.
AI-prompted development disrupts all three requirements for achieving flow; Goals become ambiguous, and you're no longer solving the problem directly. Instead, you're trying to describe it accurately enough for an unpredictable system to produce something usable. Feedback becomes opaque, the AI returns code you often can't fully evaluate, and "this looks like it might work" replaces "this works, or it doesn't." The challenge-skill balance collapses. Your skill is decoupled from the outcome because you're evaluating output from a system whose capabilities you don't control.
The subjective experience is nearly identical in both cases: deep absorption, time distortion, and a sense of control. The structural reality is, however, that one produces a better engineer, the other produces a more dependent one.
The developer in an AI prompting marathon feels like they're in flow. But the structural properties of the activity match dark flow, not productive flow. They're not growing, they're not really building mental models. They're absorbed, in the way a slot machine player is absorbed, with diminishing returns they cannot perceive because the absorption itself suppresses the self-awareness that would otherwise alert them.
There is an important distinction here. The dark flow of social media scrolling is at least pleasantly numbing. The AI coding workflow is often considerably worse. Evaluating AI-generated code demands intense cognitive effort, but the effort is evaluative rather than creative. The developer isn't building understanding through the work; they're spending mental energy assessing whether someone else's output, the AI's, is correct and whether it delivers on the requirements.
Alex Kondov, a developer who recently took an emergency sabbatical after an intense period of sustained AI-assisted work, describes the difference precisely. The deep focus he once sustained all day, iterating through solutions, investing his mind in a problem, left him tired in a way that felt earned. The AI workflow, constantly evaluating output across multiple agents, left him unable to stay awake past 2 pm despite three double espressos. Traditional deep work produces productive exhaustion, the kind that builds capability. The AI evaluation loop produces extractive exhaustion, the kind that drains capability. Both deplete your energy; only one develops your skill. Part 2 of this essay will explore the deeper implications of this dynamic for individuals and across entire teams and organizations.
I want to be precise about the evidence here. The dark flow research comes from gambling; the productive flow research comes from programming and other skilled activities. The structural mapping between AI-assisted prompting and gambling is supported by converging evidence between practitioner testimony from people like Jeremy Howard and the METR and Anthropic studies, in tandem with the formal similarity of the reward structures. But the specific claim "AI coding induces dark flow in developers" has not yet been directly tested in a peer-reviewed study.
I say this because it matters. This essay is grounded in what we know, not what we suspect. However, the structural case is clear enough that any leader betting their company's future on AI-assisted work should be asking themselves and their consultants hard questions about which kind of absorption, flow, or dark flow, their teams are actually experiencing, and whether any metric they currently track would reveal which one it is.
Next up: Engineering Without Understanding
PART 1 SEGMENTS
0
1
2
3
4
5
Get "Discipline is All You Need" as A Printable PDF
And Be Notified When Part 2 Drops.
Sign up to my newsletter. Carefully written and beautifully crafted tech & business leadership treasures, semi-regularly in your inbox free of charge.
Bonus Feature: I'll never sell your email address.