中文EN

Why Vibe Coding Is Addictive: It Turns Coding Back Into a Game

Engineering Methods · 2026-05-30

There's a phenomenon a lot of people feel but can't quite name: the moment you start coding with AI, you can't stop. You sit down to fix one bug in 20 minutes, look up, and two hours are gone — no water, no phone, no fatigue.

That's not willpower, and it's not that the AI is magic. It's flow — and flow that was deliberately (if not intentionally) engineered.

To see why, you have to unpack that overused word "flow."

What flow actually is: treating real work like a game

Csikszentmihalyi defined flow as being so absorbed you lose track of time, and listed conditions: clear goals, instant feedback, difficulty matched to skill. Accurate, but it doesn't quite land.

Here's a cruder, truer version: flow is what happens when you treat the task in front of you like a game.

You hit flow playing games; you don't hit it filling out a spreadsheet. The difference isn't that coding is nobler than gaming — it's that games are engineered as flow machines and most real work isn't. Games keep you pinned to the chair with three things:

  1. Exploration — I don't know what's in the next room, but I want to find out.
  2. Randomness — the same action doesn't give the exact same result; sometimes there's a surprise.
  3. Achievement — every few minutes there's a visible "I did it."

Traditional coding is thin on all three. The spec is fixed (weak exploration), the compiler is deterministic (near-zero randomness), and a real "done" might be two days away (delayed achievement). So coding can be rewarding, but it rarely delivers reward the way a game does: continuously. Its feedback loop is just too long.

What vibe coding does is shove all three back in at once.

How vibe coding stacks all three at once

Exploration is back. You're no longer "I know what to write, my hands just can't keep up." You're "I throw an idea at the model and see what it gives me." Every prompt pushes open a door — it might hand you an implementation you didn't think of, a library you didn't know, a pattern you'd never used. For the first time, writing code has the suspense of "what's in the next room."

Randomness is back — real randomness. The same prompt, run twice, returns different code. The model has temperature, has sampling; it's fundamentally a probability machine. As engineering, that's a flaw (not reproducible). As flow, it's a feature — it turns programming from "deterministic cause and effect" into "a bet with luck in it." You never quite know what this pull will give you. That's the exact mechanic that makes slot machines addictive: the variable reward.

The achievement loop got compressed. The "done" that used to come every two days now comes every few minutes: state a need, and seconds later something runnable appears, goes green, passes, next. The feedback loop dropped from days to minutes. Flow's hardest prerequisite — instant feedback — got manufactured out of thin air.

Stack all three and the result is: coding, for the first time, has a game's addictive structure. You're not "working," you're playing a roguelike about building software — random each run, exploration at every step, a small level cleared every few minutes.

Of course you can't stop. That's the design.

The flip side: you might just be yanking a slot-machine lever

But stay clear-eyed: the mechanic that puts you into flow and the mechanic that gets you hooked and spinning your wheels are the same mechanic. That's not a coincidence — it's one coin.

Variable reward produces flow, and it produces gamblers. When the code is wrong, that urge to "throw one more prompt and see" runs on the same circuit as a gambler's "one more pull and I'm even." You can spend a whole evening trading thirty rounds with the model, feeling very "busy" and "immersed," and ship less than if you'd stopped and thought for ten minutes and hand-written twenty lines.

A short feedback loop produces achievement, and it produces a fake sense of progress. Every "green, passed" drips you a hit of dopamine — but half the time the thing that went green is something you weren't actually testing. The achievement is real; the progress is fake. That's why so many people vibe for a day, feel "productive," and look back to find the whole PR is rework.

Exploration produces curiosity, and it produces endless drift. The doors keep opening, but you forgot long ago which room you set out to enter. Two hours later you've refactored a module that was fine, pulled in three new dependencies, and the original bug is still there.

This is the danger of flow: it feels exactly like being effective. You can't tell "I'm productive in flow" from "I'm spinning in flow" by feel — almost the same thing is happening in your brain either way.

How a veteran uses the mechanic instead of being used by it

A junior gets carried by the mechanic — enjoys the immersion, then ships a pile of rework. The veteran's difference is knowing this is a flow machine, and so bolting brakes onto it on purpose. A few concrete moves:

  • Define the finish before you open any doors. Before you start vibing, write one sentence for "the win condition of this run" (which bug fixed, which test green). Push doors freely, but don't let the finish line get quietly swapped mid-process. This converts "aimless exploration" into "exploration with a target" — the latter is flow, the former is drift.

  • Anchor achievement to something verifiable. Don't let "the model says it's fixed" give you the dopamine; let an assertion you ran yourself give it. Swap the source of achievement to real feedback and the fake-progress feeling loses its footing. This is why TDV (test-driven verification) isn't fussiness in the AI era — it's cutting power to the slot machine.

  • Cap the "one more pull." If the same problem hasn't converged after three to five round-trips, that's not bad luck — it's your cue to stop and think for yourself. Put a hard circuit-breaker on the gambler's impulse.

  • Separate two kinds of session. In exploration mode (I don't know how to do this, let the model try with me) let it run loose and enjoy the randomness; in convergence mode (I know what I want, I just need it shipped) treat randomness as the enemy — lock it down, make it reproducible, close it out. The biggest waste is doing convergence work with an exploration mindset: pulling cards forever, never cashing out.

One line

Vibe coding is addictive not because it's efficient, but because it quietly rebuilt coding into a flow machine: exploration, randomness, instant achievement — the three things that make games compulsive, all present and accounted for.

That's its biggest productivity dividend and its biggest trap. Flow and spinning your wheels are twins by feel.

The veteran's skill isn't resisting the machine — resisting means forfeiting the dividend — it's knowing how it works your dopamine, then bolting on the finish line, the verification, and the circuit-breaker yourself. Those who can play it enjoy the flow; those who get played pull the lever.

← More in Engineering Methods