Dark Flow: Why Vibe Coding Feels Productive but Isn't
dark flow vibe coding, vibe coding productivity, vibe coding problems, AI coding psychology
Gambling researchers have a term for the state where a slot machine player loses track of time, money, and intention. They call it dark flow. It is the shadow twin of Mihaly Csikszentmihalyi’s flow, that productive trance where challenge and skill are perfectly balanced and hours vanish into deep work. Dark flow feels identical from the inside. The difference is that regular flow produces something. Dark flow just keeps you pulling the lever.
Fast.ai’s blog post “Breaking the Spell of Vibe Coding” applied this concept to AI-assisted programming, and when we discussed it on episode 12 of ADI Pod, the analogy clicked with a force that was, honestly, uncomfortable. I recognized myself in it immediately. There was a weekend where I was vibe coding a home lab project, completely absorbed, generating feature after feature. The code was accumulating. The dopamine was real. And by the end I had built something I could not explain to you if you asked.
That pattern, the feeling of productivity without the substance of comprehension, deserves a closer look. Because the psychology behind it is well-documented, the mechanism is specific, and the countermeasures are not “just stop using AI.” (If you are looking for a broader treatment of vibe coding’s tradeoffs, we maintain a guide to vibe coding that covers the practice from multiple angles. This piece focuses specifically on the psychology.)
The Slot Machine in Your Editor
The core of dark flow research comes from the gambling psychology literature, specifically the study of how slot machines keep people playing despite net losses. The mechanism is not complicated, but it is effective: slot machines are designed so that a loss can be disguised as a win.
Picture three sevens and a lemon. You almost won. The near-miss activates the same reward circuitry as an actual win; your brain processes it as progress rather than failure. So you pull the lever again, because clearly the magic combination is close. One more spin. One more adjustment.
Vibe coding maps to this with disturbing precision. You prompt the model and get back 200 lines of code. It almost works. There is a bug, or the approach is slightly wrong, or the feature behaves correctly in the demo case but breaks on edge cases you have not tested yet. The near-miss registers as progress: the model understood the shape of what you want; you just need to refine the prompt. So you iterate. You tweak the instruction. The model generates another 200 lines. Each cycle feels like you are converging on the solution. Each cycle produces the neurochemical signature of achievement.
The problem is that each cycle also produces code you did not write and may not understand. The code accumulates. Your comprehension does not. And you are in a state (dark flow) that is specifically characterized by the inability to notice that gap in real time.
Why the Trance Works on Developers
Regular flow requires two conditions from Csikszentmihalyi’s original research: the task must be challenging enough to demand full engagement, and your skill must be high enough that the challenge does not overwhelm you. The result is absorption, time distortion, intrinsic reward.
Dark flow has all the same phenomenological features, but the skill-challenge balance is illusory. In gambling, the machine does the work and presents the outcome as your agency. In vibe coding, the model does the work and presents the outcome as your intent. You said what you wanted. The code appeared. It feels like building, in the same way that pulling a slot lever feels like playing a game.
Developers might be especially susceptible for a reason that is both obvious and easy to miss: we are trained to measure progress by output. Lines of code, features shipped, tasks closed. Vibe coding produces output at an extraordinary rate. The velocity metrics look incredible. The pull request diff is enormous. The commit log is dense with activity. Every signal we have internalized as “productive day” is firing at maximum intensity.
My co-host Dan Lasky captured this when we were discussing it: “The bar feels low because it also feels magical. The computer is writing its own code. So even when the result is terrible and not at all what you would have done, there is this sense of, hey, it did something. That is kind of cool.” That sense of wonder creates a permission structure for accepting work you would reject from a human colleague. The novelty suppresses your quality filter. And the data backs this up: AI-authored code has measurably more logic errors, precisely the kind of bugs that a developer in dark flow is least equipped to catch.
What Anthropic’s Research Adds
Anthropic published a study on how AI assistance impacts the formation of coding skills that, read alongside the dark flow concept, paints a sharper picture. They gave 52 junior developers (all with at least one year of Python experience) 35 minutes to complete two tasks using an unfamiliar library (Trio, an async library). Half had AI assistance. Half did not. Afterward, both groups took a recall quiz on what they had learned.
The results split along lines of engagement strategy, not just AI usage. Developers who fully delegated to the AI scored only 39% on the recall quiz. The worst performers, scoring just 24%, were the iterative AI debuggers: developers who repeatedly used AI to troubleshoot and verify, cycling through prompts without building a mental model of the underlying library. They took the longest and learned the least.
That 24% group is dark flow in its purest form. They were engaged, active, cycling through attempts, experiencing the near-miss reward of almost-working code. But the activity was happening at the surface level (prompt, generate, evaluate output, adjust prompt) while the deeper cognitive work of understanding the library’s abstractions never occurred. The slot machine was spinning. The lever was being pulled. But the quarters were running out.
Critically, AI-assisted developers who used a generation-then-comprehension approach (writing code with the AI first, then asking focused questions about what was generated) scored 86% on the quiz and did not take significantly longer. The difference between dark flow and productive flow was not the presence of AI. It was whether the developer maintained an active comprehension loop or outsourced it entirely.
The OpenClaw Cautionary Tale
Episode 12 also covered the OpenClaw saga, the personal AI assistant that went through three names in a week (ClawBot, MoltBot, OpenClaw). I installed it in a Dockerized environment and gave it a shot. The tool is interesting, but what struck me was how quickly I found myself in the dark flow loop. The assistant would do something, I would evaluate the output, tweak the instruction, and repeat. I was not learning the tool’s architecture. I was not building a mental model of its skill system. I was iterating on prompts the way you might iterate on slot machine strategy, adjusting your pull technique while the random number generator remains indifferent to your efforts.
The broader OpenClaw ecosystem illustrated the same pattern at community scale. A skill marketplace emerged where people were installing and running code they had not audited, because the iteration loop felt productive. The result was predictable: the ClawdBot crypto-stealing malware incident, where a malicious skill drained users’ cryptocurrency. The community was in collective dark flow, so absorbed in the novelty of the tool that basic security hygiene was suspended.
That is not a technology failure. It is a psychology failure, and specifically, a failure mode that gambling researchers have been documenting for decades.
Four Symptoms of Dark Flow in Your Coding Sessions
The Fast.ai post and Anthropic’s research, taken together, suggest a diagnostic framework. You are likely in dark flow, rather than productive flow, when:
| Symptom | Signal | Diagnostic Question |
|---|---|---|
| Iterating on prompts, not understanding | ”Maybe if I phrase it differently” | Could you explain the underlying problem to a colleague? |
| Output growing faster than comprehension | Code accumulating, mental model stalled | Could you whiteboard the architecture right now? |
| Near-miss keeping you engaged | ”Almost works” loop | Do you know why the next iteration might work? |
| Feeling productive without learning | Hours passing, no new skills | Could you solve this faster tomorrow without AI? |
1. You are iterating on prompts rather than iterating on understanding. If your inner monologue is “maybe if I phrase it differently” rather than “let me understand why that approach failed,” the slot machine is spinning. The distinction is subtle because prompt refinement can be a legitimate skill. But if you are on your fourth rephrasing and you still could not explain the underlying problem to a colleague, you are adjusting your grip on the lever, not learning the game.
2. Your output is growing faster than your comprehension. This is the defining characteristic. Dark flow produces code at a rate that outstrips your ability to build a mental model of what was produced. If you paused and someone asked you to whiteboard the architecture of what you just built, could you do it? If the answer is “roughly, but not the details,” you are accumulating cognitive debt at a rate that will come due. We explored that dynamic in depth in a separate piece on cognitive debt.
3. The near-miss is keeping you engaged. “Almost works” is the dark flow signal. When the code is close (compiles but fails one test, handles the happy path but breaks on edge cases, looks right but does something subtly wrong) the near-miss reward circuitry activates. You feel motivated to keep going, not because you have a clear diagnosis, but because you believe the next iteration will land. This is the three-sevens-and-a-lemon moment. Sometimes the next iteration does land. Slot machines pay out too. The question is whether you understand why, or whether you are just pattern-matching on the outcome.
4. You feel productive but cannot articulate what you learned. Flow states, by definition, involve skill exercise. If you have been vibe coding for two hours and your skill set is exactly where it was when you started, and you could not solve the same problem faster tomorrow without the AI, then the flow was dark. You were experiencing the phenomenology of deep work without the epistemic gains.
Breaking the Spell Without Breaking the Tool
AI-assisted coding should stay in your toolkit. The same mechanics produce both flow and dark flow, and the variable is the developer’s relationship to the activity, not the activity itself. Banning the tool would be like responding to the discovery of dark flow in gambling by banning all games; it confuses the mechanism with the medium.
What the Anthropic data suggests is that the intervention point is comprehension checkpoints. The generation-then-comprehension group scored 86% on recall without a meaningful time penalty. They were neither slower nor less productive. They simply added a step: after the AI generated the code, they asked it to explain what it did and why. That single addition, forcing the mental model to be constructed rather than assumed, is the difference between flow and dark flow.
In practice, a few specific habits make the difference:
- After every significant generation, ask the model to explain the approach it chose and what alternatives it considered. This is not busywork. It is the cognitive equivalent of counting your chips between hands. You are forcing an accounting of what you actually have versus what you feel like you have.
- Set a comprehension threshold before you accept generated code. Not “does it work” but “could I modify this without the AI’s help.” If the answer is no, you are taking on cognitive debt, and unlike technical debt, you cannot have a future agent pay it down for you.
- Watch for the fourth prompt revision. If you are on your fourth attempt to get the AI to produce what you want, stop. You are in the near-miss loop. Step back, read the documentation, understand the problem space manually, then return to the AI with a more informed prompt. The irony is that this usually produces better results faster.
- Distinguish vibe coding contexts. Dan made a point on the episode that I think is exactly right: for personal side projects where the goal is exploration and the stakes are low, vibe coding is fine. The danger is when the same mode, the same dark flow state, follows you into production codebases where someone else will have to maintain what you built. Know which mode you are in.
The Cost That Is Not Money
Gambling dark flow costs money. Vibe coding dark flow costs comprehension. Of the two, comprehension might be the more expensive loss, because you do not get an account statement showing the balance. You discover it when something breaks and you realize you cannot fix it, not because the problem is hard, but because you never understood the system well enough to diagnose it. That is the moment the cognitive surrender begins, and we have written about where that leads.
The Fast.ai post that coined the term in a coding context ends with the advice to “break the spell.” I think the framing is slightly more precise than that. You do not need to break the spell of vibe coding. You need to learn to tell the difference between the spell that is building something and the spell that is just keeping you at the machine, between flow and its shadow. The symptoms are well-documented and the intervention is cheap, but the cost of not intervening is a codebase that runs but nobody understands, built by a developer who was productive all day and has nothing to show for it but a commit log.
The lever is right there. The question is whether you are pulling it because you know what you are building, or because it feels too good to stop.