For me there’s no flow state possible with LLM “coding”.
This comment in a HN thread about AI struck me—because I hadn’t thought about it before, and my initial reaction was “Yeah, same.”
But my secondary reaction was, “Is it even possible to enter a flow state while vibecoding?”
Definitions
Right off the bat, the answer to this is going to be dependent on your definition of flow state. The term descends from psychologist Mihály Csíkszentmihályi, who describes it thusly:
We have called this state the flow experience, because this is the term many of the people we interviewed had used in their descriptions of how it felt to be in top form: "It was like floating," "I was carried on by the flow.”
—Csikszentmihályi, Flow (1990)
After decades of research, a more rigorous definition has emerged:
Flow is an intrinsically rewarding state of absorption in a task in which a high degree of control feels more effort-less than normal.
—Wikipedia, possibly derived from this paywalled paper
That paper lays out these characteristics:
…a core experience of flow including overarching antecedent constructs:
- Optimal challenge: A perceived capability to meet the challenging demands of the situation
- High motivation: A high motivational force
And recurring characteristics of the flow experience itself included:
- Absorption: A state of absorption in the task characterized by focused, undistracted attention, and a merging of action and awareness
- Effort-less control: A high sense of control in which the task feels less effortful than is typical for that person, characterized by fluidity of performance and an absence of concern over losing control
- Intrinsic reward: An intrinsically rewarding experience characterized by positive valence and optimal levels of arousal
Knowledge Crystals
My initial intuition about this question was “No, you can’t enter a flow state while vibecoding,” because the task of vibecoding is fundamentally different from actual programming.
While coding, you are responsible for understanding the problem deeply enough to solve it. This involves maintaining an active, continuous mental model of the knowledge graph necessary to complete the task.
Anyone who has coded for a while has probably observed how difficult and time-consuming it can be to get that mental model in place, which is why it’s so incredibly important to avoid any distractions that can shatter it—because it can get shattered so incredibly easily.
Let’s call this your knowledge crystal, because that sounds rad as hell and fits the analogy. The knowledge crystal explains several of these characteristics of the flow state:
- Absorption: focused, undistracted attention is a necessary prerequisite for the formation of the crystal
- Effortless control: when the crystal has all the information you need in it, ‘control’ feels effortless because you’re hitting far fewer brick walls
- Intrinsic reward: effortless control means you glide through problem after problem after problem without slowdowns, which is, you know, incredibly freaking rewarding
The Task of Vibecoding
Vibecoding—writing prompts that cause an LLM to output code—is a fundamentally different beast.
Isn’t it?
In coding, the knowledge crystal is ‘technical:’ it may include the syntax rules of the programming language you’re using, the patterns that language affords, all the context of the problem itself (APIs, libraries, existing code and prior art), and much more.
Vibecoding requires you to understand the product, in both the figurative and literal sense: you are focussed on the outcome of all that technical knowledge.
Could it be said that vibecoding has its own knowledge crystal? One formed out of customer needs, jobs-to-be-done, product requirements, marketing promises, etc. etc.?
If we accept this premise, can you then enter a flow state centered around the product’s problem instead of the computer’s problem? Let’s look at the above characteristics again:
- Absorption: well, if your LLM doesn’t hit any brick walls, then presumably you could have focused, undistracted attention
- Effortless control: I suppose the analog here would be something like “I know exactly how to prompt this particular LLM”, resulting in less brick-wall-hitting
- Intrinsic reward: it can indeed be rewarding to achieve your product vision
But something still doesn’t feel right.
It’s About Control
One big catch here is “if your LLM doesn’t hit any brick walls.” Right now I don’t know of anyone for whom this is a reality. I hear claims like this frequently but I suspect they’re conveniently dancing around the reality.
If the AI agent gave you exactly the right code—no weird logical leaps, no outdated libraries, no absurd cruft, no stupid choices that even a junior would never have made—you’d hypothetically have the desired output in one step. In the ‘product crystal’ model, the problems you are solving are product design problems, not engineering problems. So if your agent isn’t throwing up barriers to solving those problems quickly and easily, I suppose I would concede that you could potentially experience a flow state.
When I take a step back and think about the product POV, I realize: well, I actually do experience flow states while doing product design—but that’s while in Figma. I absolutely can and do get into fantastic grooves where I’m slinging autolayouts faster than I can consciously register it.
But that’s not vibecoding, that’s Figma. So I think we’ve got 3 different tasks here: programming, designing, and vibecoding. What sets vibecoding apart from the other two?
The answer is that vibecoding is a supervisory task, not a ‘direct’ one, and the difference between those is control. A supervisory task defines the desired outcome, and then reviews it, with a gigantic black box in between. As such, the supervisor makes none of the microdecisions involved in the production of the output, and are arguably not really in control of it. Control is more than “influence over outcomes.”
A flow state requires you to be the one in control, where your decisions are made nearly unconsciously, in rapid succession, without intervals that break concentration. With this realization, I come back to my initial gut reaction: vibecoding is simply not the right kind of task to afford a flow state, in the same way that managing a junior developer is not a ‘flow-able’ task: there’s simply far too big of a disconnect between your actions and the results.
But I’m very curious to hear reactions and rebuttals to this—let me know what your experience reflects!