ki-fuer-menschen · 2026-05-17
Vibe Coding as a Drug — An Honest Self-Observation
TL;DR
Vibe coding is productive. Vibe coding is also a drug. After 12 months of daily use I observe three symptoms in myself that have more in common with slot-machine mechanics than software engineering: 2-minute reward loops, collapsing time perception, difficulty stopping. This post is honest self-observation, not Karpathy-bashing — vibe coding is a real new method with real value. But the discourse gap I want to close is: we talk about the upside, no one talks about the pull. Three symptoms, three stop lists, one stop question.
Featured image placeholder: stylized self-observation with reward-loop visualization. Asset pending — prompt at end.
Table of Contents
- What is vibe coding actually?
- The three symptoms I observe in myself
- What it shares with classic addiction mechanics
- Three stop lists from 12 months of practice
- The one stop question that actually helps
- Why I still keep going
- FAQ
What is vibe coding actually?
The term was coined by Andrej Karpathy in February 2025 (see Wikipedia entry on the term), became Collins English Dictionary “Word of the Year 2025”, and has reshaped the software discourse in 18 months.
Core definition (from Karpathy’s original tweet): “I describe to an AI what I want, accept the generated code without reading it, and only react if it does not do what I wanted.”
Important: Vibe coding is not agentic coding. Simon Willison writes in May 2026 that the two terms are converging, but they are conceptually different:
- Vibe coding: trust in output, no code review, react to behavior
- Agentic coding / engineering: trust in process, spec-driven, test-driven
My productive daily mix is 80% agentic, 20% vibe. The vibe slice is the addictive one.
The three symptoms I observe in myself
Symptom 1: The 2-minute reward loop
When vibe coding, I type a prompt, wait 30-90 seconds, read the result, accept/refine/discard — and type the next prompt. This loop typically runs every 2-3 minutes.
Per Stanford research on variable reward schedules, this is exactly the reward frequency slot-machine designers and social-media algorithms optimize for. We know that this schedule shape maximizes dopamine releases.
Observation: if I do an hour of vibe coding, then read and write code classically (3-10 minute reward pause), the latter feels slow. Not because it is slow — it is normal software pace. It just feels slow relative to vibe frequency.
Symptom 2: Time perception collapses
In vibe-coding sessions I lose time differently than in classic code sessions. What feels like 30 minutes is often 2-3 hours.
Fraunhofer IESE writes in a May 2026 blog post on vibe coding risks that this “flow state on steroids” is one of the primary safety risks: you commit code you never read, in places whose consequences you have not thought through.
A real example from me, last week: I sat down with a Bonblick feature at 19:00 thinking “30 more minutes.” Looked up at 22:45. Four hours in a vibe-coding loop, no dinner equivalent, no break. Output was good. Body was wrecked.
Symptom 3: Difficulty stopping
The third symptom is the most diagnostically clear. Stopping vibe coding feels like stopping Netflix mid-episode.
Even when I know it is 21:00 (my hard cutoff per the eight-projects-parallel post), even when the feature branch is done, even when I am tired — the reflex is “just one more iteration”. And that is exactly the reaction every slot machine triggers by design.
Inline image placeholder: comparison diagram of the three symptoms. Asset pending.
What it shares with classic addiction mechanics
I am not an addiction researcher. But the parallels are clear enough that the framing fits:
| Classic addiction mechanic | Vibe-coding equivalent |
|---|---|
| Variable reward schedule | Sometimes brilliant, sometimes garbage → unpredictable |
| Low-friction access | Type, wait, read — no setup cost |
| Social comparison | Indie-hacker Twitter, ChatGPT communities, Show HN posts |
| Sunk-cost fallacy | ”Just one more prompt and I have it” |
| Time distortion | As above — hours vanish |
| Reward anticipation | Expectation of the next output is part of the high |
This is not a moral judgment. Software engineering is neither morally better nor worse than other reward-driven activities. But if the mechanic is an addiction mechanic, it should be handled with addiction discipline.
The German guideline on Internet Gaming Disorder (DGPPN) lists six diagnostic criteria for behavioral addictions. I regularly meet criterion 1 (loss of control on cessation), criterion 2 (time-perception distortion), and criterion 4 (continuation despite negative consequences — sleep loss) after long vibe sessions. Not clinical, but phenomenologically parallel.
Three stop lists from 12 months of practice
These three stop lists have protected me from the worst outgrowths.
Stop list 1: Time-of-day limits
| Rule | Consequence |
|---|---|
| No vibe coding before 09:00 | Morning energy goes to spec/design, not reward loops |
| No vibe coding after 21:00 | Hard cutoff, otherwise it runs to 02:00 |
| Maximum 90 min vibe at a stretch | Slot rule from eight-projects-parallel post |
| At least 30 min classic code reading per day | Reset for code-reading skill |
Stop list 2: Output limits
| Rule | Consequence |
|---|---|
| Never commit directly to main | Branch + PR-review-your-own-PRs |
| Test-coverage check before every push | auto-test from Conductor enforces this |
| No architecture decisions in vibe mode | Spec phase separated in the morning |
| No production DB operations in vibe mode | Sandbox first, hardcoded |
Stop list 3: Body signals
| Signal | Action |
|---|---|
| 60+ min without drinking water | Hard reset, 10 min away from screen |
| Calf cramps (sitting without movement) | Walk, 15 min minimum |
| Eyes burning | Screen off, 20-20-20 rule |
| Tiredness but compulsion to continue | Take THIS signal seriously — stop immediately |
The last line is the most important. When your body says “tired” and your brain says “one more iteration”, that is the addiction signature.
The one stop question that actually helps
When all stop lists fail, one question helps:
“What would happen if I just stopped right now?”
Almost always the answer: Nothing. The feature waits until tomorrow. The PR reviewer (me) needs sleep anyway. The market is not waiting for 30 min of code from the third third of the night.
The question works because it attacks the sunk-cost argument frontally. Vibe-coding trance lives on an imaginary “almost done” goal preventing the stop. The question dissolves the goal — and suddenly stopping is trivial.
Inline image placeholder: visualization of the stop question as loop breaker. Asset pending.
Why I still keep going
After all these symptoms the honest question: why do I use vibe coding daily?
Three reasons:
- The productivity is real and measurable. Per Conductor telemetry from the eight-projects post: ~12,400 net new lines per week at 78% test coverage. Not reachable with classic code-writing in the same time.
- It is age-appropriate. I am 60. Typing speed is no longer my competitive advantage. Articulating concepts precisely is. Vibe coding monetizes that.
- The addiction mechanic is manageable. With the three stop lists plus the stop question, I stay functional. Without them I would drop it too.
But: anyone entering vibe coding without self-observation experience — especially younger developers with less calibration of their own reward system — should start with deliberate caution. The Fraunhofer IESE warning on vibe-coding risks is not academic caution but a real observation.
Where this goes next
Three open issues I am currently working on:
- Telemetry for vibe sessions. I track my slots manually but not the vibe-vs-spec/architect share. A side tool that does this automatically would be insurance.
- Social pressure as a stop mechanic. Family + close friends now know about the vibe-coding pull. When my wife asks “it is 22:30, everything okay?” — that is a real stop trigger. Social stop mechanics are more effective than self-imposed ones.
- Closing the discourse gap. This post is part of that. If the vibe-coding discussion only runs on productivity wins, the self-observation voices are missing. That does not help anyone long-term.
If you practice vibe coding yourself and recognize the three symptoms: reach me on LinkedIn. Exchange of experience helps.
FAQ
Is vibe coding really comparable to an addiction?
Phenomenologically partly yes (variable reward schedule, time distortion, loss of control on cessation), clinically no. There is no established diagnosis “vibe coding addiction.” But the German guideline on Internet Gaming Disorder recognizes structurally similar behavioral addictions.
Should I stop using vibe coding?
No, if you value the productivity gain and adhere to the stop mechanics above. Yes, if you observe symptoms in yourself and cannot establish a stop mechanic. That is a very personal calibration.
What is the difference between vibe coding and agentic coding?
Vibe coding = trust in output, no code review, react to behavior. Agentic coding = trust in process, spec-driven, test-driven. My productive mix is 80% agentic, 20% vibe. Detail here.
Does vibe coding produce bad code?
Not necessarily. But it produces not-understood code. The risk is not bug density but having code in production whose edge-case behavior you cannot predict. Discipline in test coverage and PR review handles that. Without discipline: yes, bad code.
Why does no one else write about the addiction dimension?
Probably for three reasons: (1) the discourse is young (Karpathy 2025), (2) productivity wins are more visible than slow side effects, (3) the addiction dimension is personal/embarrassing. Reason 3 is why this post exists.
Written on May 17, 2026 in Hamburg. Personal experience report, not a medical statement. If you find this post useful, link to it — the self-observation perspective is underrepresented in the vibe coding discourse.