About the author: I'm Charles Sieg, a cloud architect and platform engineer who builds apps, services, and infrastructure for Fortune 1000 clients through Vantalect. If your organization is rethinking its software strategy in the age of AI-assisted engineering, let's talk.
Last Monday I went into my office at 7 AM to kick off a few Claude sessions before taking the trash cans to the street. I sat down, wrote three prompts, and started reviewing the first batch of output. At noon I looked up and realized the garbage truck had come and gone four hours ago. I had not eaten breakfast. I had not taken the trash out. I had been sitting in the same chair for five hours without standing up, and the only reason I noticed was that someone texted to ask if I was still alive. The work was going so well that stopping felt physically wrong.
I mentioned this to a colleague, a senior architect who runs his own Claude Code workflow. He laughed and said he had the same problem. He described feeling guilty when he leaves his office for the day because there is always more work Claude could be doing. If he stayed, he could keep prompting. There is always another system to build, another feature to add, another idea to try. Walking away feels like leaving money on the table. We both recognized this as a type of FOMO, but it took us a while to name it because it does not match the usual definition. This is not fear of missing a social event or a trending topic. This is fear of missing the next thing you could build, or at least having to wait for it.
The Guilt of Walking Away
The feeling is specific and consistent. I get into a productive rhythm with Claude. Sessions are running. Code is landing. Tests are passing. Everything I asked for is materializing on screen. Then real life intrudes. Dinner. A doctor's appointment. A meeting that cannot move. I find myself genuinely annoyed at having to leave. Not bored with the interruption itself, but frustrated that I have to stop the thing that is working so well.
Before AI, this feeling existed but had natural limits. A coding session hit a wall when I needed to think through a design problem, or when a build took ten minutes, or when I ran out of energy for the day. Those pauses created breathing room. The work itself imposed its own breaks.
Claude does not get tired. Claude does not need a coffee break. Claude does not need to think about a problem overnight. When I leave my desk, the only thing that stops is my ability to initiate the next task. Every minute I am away is a minute Claude could be building something. That math runs through my head every time I stand up to leave the room.
The Missed Garbage Truck Problem
I have started noticing a pattern of temporal distortion during heavy sessions. I sit down to work at 8 AM planning to handle something in 30 minutes, and I surface at noon having forgotten that the 30-minute task ever existed. I miss lunch by hours. I forget errands. Once I realized at 2 PM that I had a dentist appointment at 1 PM.
This is not carelessness. It is a known neurological phenomenon. Mihaly Csikszentmihalyi described this as a defining characteristic of the flow state): when a person becomes so absorbed in an activity that their sense of time, hunger, and self-awareness suppresses. People in flow states have elevated dopamine levels that actively suppress bodily sensations like hunger and fatigue. Your brain literally stops telling you that you are hungry because the reward signal from the work is stronger.
The difference with agentic coding is that the flow state does not require me to be coding. I am reviewing, prompting, evaluating, and directing. The cognitive engagement is high enough to trigger flow but the physical effort is near zero. I can sustain this state for far longer than I could sustain actual hands-on-keyboard programming, because my fingers never get tired, my eyes never strain from typing, and the results keep coming faster than I can consume them.
What FOMO Looks Like in Practice
I have developed a habit of trying to find the biggest possible project to fire off before leaving my desk. If I have to go to dinner, I want to give Claude a task that will take long enough that I do not feel like I wasted the time away. So I scope up. Instead of asking for one feature, I ask for an entire subsystem with tests and documentation.
The problem is that the tasks finish too fast. I will spend five minutes crafting what I think is a two-hour project, and Claude finishes it in 15 minutes. Parallelization made this worse. Claude now fires up as many subagents as it needs, works on all the components simultaneously, and delivers the entire system in a fraction of the time a sequential approach would take. A task I expected to keep it busy through dinner is done before I find my car keys.
| What I Expected | What Actually Happens |
|---|---|
| "This will keep Claude busy for 2 hours" | Done in 18 minutes |
| "This is at least a 4-subsystem project" | All 4 built in parallel, done in 22 minutes |
| "I'll fire this off before bed" | Finished before I brush my teeth |
| "This is a full weekend project" | Completed by Saturday lunch |
The math keeps getting worse. As models improve and parallelization gets more aggressive, the gap between "how long I think it will take" and "how long it actually takes" keeps widening. The FOMO intensifies because the theoretical throughput keeps climbing while my physical presence remains the bottleneck.
The Neuroscience of the Dopamine Loop
There is a neurochemical reason this feels addictive, and it goes beyond the casual use of the word.
The Variable Ratio Reinforcement Schedule
Behavioral psychology has a concept called variable ratio reinforcement. It is the most addictive reinforcement pattern ever documented. Slot machines use it. Social media uses it. The mechanism is simple: deliver rewards at unpredictable intervals, and the brain releases more dopamine in anticipation of the reward than it does from the reward itself.
Agentic coding operates on a variable ratio schedule. Every prompt is a pull of the lever. Sometimes Claude produces exactly what I wanted. Sometimes it produces something better than what I imagined. Sometimes it goes sideways and I need to redirect. I never know which outcome I will get until the output arrives. That uncertainty is the key. Research on reward uncertainty shows that unpredictable rewards trigger larger dopamine responses than predictable ones, and that those responses grow stronger over time as variability increases.
The dopamine hit when Claude delivers a working application, when you see the app run for the first time and it is everything you were hoping for, is genuine. That high you get when you know the thing you wanted to build is going to be real. That feeling is chemically identical to the feeling a gambler gets when the slot machine pays out. The difference is that my slot machine produces working software.
Flow State as a Dopamine Amplifier
Csikszentmihalyi identified flow as a state where the challenge of the activity matches the person's skill level. Too easy and you get bored. Too hard and you get anxious. The sweet spot produces the experience of effortless concentration.
Agentic coding sits perfectly in that sweet spot for someone with experience directing AI. The challenge is real: you need to scope the work correctly, evaluate the output critically, catch architectural mistakes, and maintain a coherent vision across multiple concurrent sessions. But the execution barrier is gone. You never hit the "I don't know how to implement this" wall that breaks flow in traditional programming. Claude handles the implementation. You handle the judgment. That combination produces flow states that can last for hours because the challenge-to-skill ratio never drops.
| Factor | Traditional Coding | Agentic Coding |
|---|---|---|
| Flow trigger | Solving implementation puzzles | Directing and evaluating AI output |
| Flow breaker | Getting stuck on a bug | Running out of ideas to prompt |
| Typical flow duration | 30-90 minutes | 2-6 hours |
| Physical fatigue signal | Eyes, wrists, back | Rarely triggered |
| Hunger awareness | Moderate (breaks for compile/test) | Suppressed (no natural pauses) |
| Time distortion | Mild to moderate | Severe |
The research on flow and dopamine confirms this. Neuroimaging studies show that flow states involve sustained dopamine and norepinephrine release that suppresses the brain's default mode network (the system responsible for self-reflection, time awareness, and mind wandering). When that network goes quiet, you lose track of time, forget to eat, and stop noticing that your body needs to move. The dopamine from the flow state creates a self-reinforcing loop: engagement triggers dopamine, dopamine deepens engagement, deeper engagement triggers more dopamine.
Csikszentmihalyi himself warned about this): "Enjoyable activities that produce flow can become addictive, at which point the self becomes captive of a certain kind of order, and is then unwilling to cope with the ambiguities of life." I read that sentence and recognized my own Monday morning.
The Parallelization Problem
Claude Code now supports subagents, agent teams, and concurrent sessions that work in parallel. This is an enormous productivity multiplier. It also makes the FOMO problem structurally worse.
Why Speed Kills FOMO Resistance
When a task took a human engineer a full day, walking away for dinner cost you an hour out of eight. The task would still be there tomorrow, and progress would resume. When Claude completes that same task in 20 minutes, walking away for dinner means you missed three full project cycles. The opportunity cost per hour of absence scales with the throughput of the tool.
Here is a concrete example. On a recent Saturday I ran six Claude Code sessions simultaneously. Each session was building a different subsystem of an application. My job was to write the initial prompts, review the output, approve the diffs, and kick off the next phase. In four hours, those six sessions produced what would have taken a solo engineer several weeks. The leverage was extraordinary.
The problem is that all six sessions finished within 20 minutes. Every one of them. I spent more time writing the prompts than Claude spent building the code. And when they all completed, six sessions sat idle until I could review the output and write the next batch of prompts. I am the bottleneck. Not the AI. Not the compute. Not the context window. Me, physically sitting in a chair, reading diffs and typing prompts.
That realization creates a specific kind of anxiety. I have access to a tool that can produce months of human-equivalent engineering output per day, and the only constraint is my biological availability. Every hour I spend sleeping, eating, exercising, or spending time with my family is an hour where Claude could be building something. I know that framing is unhealthy. I know it rationally. But the feeling persists.
The Throughput Ceiling
The math clarifies the problem. Across my The Leverage Factor: Measuring AI-Assisted Engineering Output, the average leverage factor is 45x. That means for every minute Claude runs, it produces 45 minutes of human-equivalent engineering output. If I can keep Claude busy for 8 hours in a day across multiple sessions, that is the equivalent of 360 hours of human engineering. Forty-five workdays. Nine work weeks. From a single calendar day.
But I cannot actually keep Claude busy for 8 continuous hours. I eat. I have meetings. I take phone calls. I walk the dog. Realistically, I get 4-5 hours of active prompting and review per day. That means I am leaving half the theoretical throughput on the table every single day. The FOMO is a direct consequence of understanding the math.
| Scenario | Active Hours | Claude Output | Human Equivalent |
|---|---|---|---|
| Maximum theoretical | 8h | 480 Claude-minutes | 360 hours (9 weeks) |
| My typical day | 5h | 300 Claude-minutes | 225 hours (5.6 weeks) |
| Light day (meetings, errands) | 2h | 120 Claude-minutes | 90 hours (2.25 weeks) |
| Day off | 0h | 0 Claude-minutes | 0 hours |
That "Day off = 0 hours" row hits differently when you have internalized the leverage numbers. A day off is not just a day off. It is nine weeks of potential engineering output that did not happen. I realize how absurd that sounds. I also realize I am not the only person who thinks this way.
The Dual Nature: Exhaustion and Craving
Here is the genuinely strange part. I wrote an entire article about Agentic Coding and Decision Fatigue: The Cognitive Cost of Supervising AI because the cognitive load of supervising AI is real and measurable. By 3 PM, my prefrontal cortex is running on fumes. Glutamate is accumulating. My judgment is degrading. I can feel my decision quality dropping.
And yet. I do not want to stop.
The decision fatigue and the dopamine craving coexist. I am exhausted and addicted at the same time. My rational brain knows I should stop because my review quality is suffering. My dopamine system wants one more prompt, one more build, one more hit of seeing the application take shape. This is the same dual state that characterizes most behavioral addictions: the conscious knowledge that you should stop, paired with the compulsion to continue.
How the Craving Overrides the Fatigue
The neurochemistry explains why the craving wins. Decision fatigue depletes the prefrontal cortex, which is the brain region responsible for impulse control and long-term planning. As that region weakens, the limbic system (which drives reward-seeking behavior) gains relative influence. You get worse at resisting temptation precisely when the temptation is strongest. By 3 PM I am simultaneously too tired to review code carefully and too wired to stop requesting it.
I have caught myself approving diffs at 4 PM that I would have rejected at 9 AM. Not because I stopped caring, but because my brain ran out of the neurochemical resources required to care at the same resolution. The decision fatigue article covers the mechanism. The relevant point here is that the exhaustion does not produce a desire to rest. It produces a desire to keep going with less rigor, which is the worst possible combination for code quality.
The Bottleneck Is You
The fundamental psychological tension comes from a simple realization: the only limit on what Claude can build is me being physically present to kick off the next thing.
The Productivity Trap
Traditional knowledge work has a natural cap. You can only type so fast, think through problems so quickly, maintain focus for so many hours. Those limits felt frustrating when you were young and ambitious, but they also created a ceiling that protected you from working yourself into the ground. Your own limitations were your guardrails.
AI removed the guardrails. The ceiling is gone. Claude can produce 200x your output for as long as you keep feeding it prompts. The only governor on the system is your biological need to sleep, eat, and maintain relationships. That is a profoundly different constraint than "I am tired and my brain does not want to solve this problem anymore." It is external rather than internal, which means you have to enforce it consciously rather than relying on your body to shut you down.
| Constraint | Pre-AI | Post-AI |
|---|---|---|
| Typing speed | Natural limit | Irrelevant |
| Problem-solving capacity | Depletes over hours | Claude handles implementation |
| Build/compile wait time | Forces breaks | Near zero |
| Cognitive ceiling | Reached by afternoon | Reached but craving overrides |
| Physical fatigue | Signals to stop | Suppressed by flow state |
| External obligations | Accepted as normal | Resented as lost throughput |
That last row is the one that concerns me. When you start resenting dinner with your family because it costs you two Claude sessions, something has shifted in your relationship with work. I catch that thought and correct it, but the thought still arrives.
The Lazy Feeling
I feel lazy if Claude is not running in at least half a dozen sessions. If I am sitting at my desk and only one terminal has a Claude session active, I feel like I am wasting capacity. Like leaving a factory floor idle while orders are backing up. I know this is irrational. Nobody calls a person running five concurrent engineering sessions "lazy." But the feeling does not respond to logic. It responds to the gap between what I could be producing and what I am actually producing, and that gap is always nonzero because the theoretical maximum is absurd.
What I Have Tried
I am not going to pretend I have solved this. I have not. But I have tried several approaches that help manage the intensity.
Commitment Anchoring
Alarms do not work. I tried setting hard stops for the day, and I silenced the alarm 30% of the time because I was in the middle of something that felt too good to interrupt. An alarm is a suggestion. It has no consequences.
What works is scheduling commitments with other people. I set a workout with my son at 4 PM. I will never cancel on my son unless the situation is genuinely dire, and no amount of FOMO qualifies as dire. That commitment to being physically present with another person is stronger than any pull from the terminal. The obligation is external and social, which means my dopamine system cannot override it the way it overrides a timer.
The key insight is that FOMO loses to relationships. I can silence an alarm. I can rationalize "just ten more minutes" to a calendar reminder. I cannot look my son in the eye and tell him I skipped our workout because Claude was in the middle of a build. The social contract is the strongest forcing function I have found.
Front-Loading the Day
I do my most intensive Claude work in the morning when my judgment is sharpest. By afternoon, I shift to lighter tasks: documentation, research, planning. This aligns with the decision fatigue research and reduces the 3 PM problem of exhausted-but-craving. It does not eliminate the FOMO when I leave for the day, but it ensures that my highest-leverage hours get my best cognitive resources.
The "Fire and Walk Away" Strategy
Sometimes I deliberately write a large prompt, kick off the session, and physically leave the room before the output arrives. This prevents the dopamine hit from triggering "one more" behavior. I come back, review the output cold, and decide whether to continue. Breaking the real-time feedback loop helps, though it requires genuine willpower because the temptation to stay and watch is strong.
Pomodoro for Agentic Work
I covered this in detail in the Agentic Coding and Decision Fatigue: The Cognitive Cost of Supervising AI article, but it bears repeating here because it addresses both the fatigue and the FOMO simultaneously. The classic Pomodoro Technique (25 minutes of focused work, 5 minutes of mandatory break, longer break every fourth cycle) maps well to agentic coding. A single Pomodoro aligns with one or two substantial agent tasks: enough time to prompt, review output, iterate once, and ship. The 5-minute break forces me to step back before starting the next task.
The critical rule is that the break happens whether I feel fatigued or not. The research on glutamate accumulation shows that I cannot accurately assess my own decision quality under cognitive load. Perceived freshness and actual prefrontal cortex function diverge. The timer is more trustworthy than my self-assessment. And unlike a simple alarm, the Pomodoro structure turns breaks into part of the system rather than interruptions to it. I am not "stopping work" during a break. I am executing the next step of the protocol. That reframing makes it easier for my dopamine system to accept.
Accepting the Math
The most helpful mental shift has been accepting that I will never saturate the available throughput. There will always be more that Claude could do. Optimizing for maximum Claude utilization is optimizing for the wrong metric. The right metric is total output quality over sustainable periods. A person who works 5 focused hours per day for 20 years will produce more than someone who burns at maximum intensity for 18 months and then crashes.
There is also a practical argument for patience. The next version of Opus will be faster and smarter than the current one. Each model generation requires less of my judgment and produces higher-quality output per prompt. The throughput I am anxious about missing today will look quaint in twelve months. Burning myself out trying to maximize utilization of the current model makes even less sense when the model itself is a moving target that keeps getting better. The leverage factor only goes up. My job is to still be functional when it does.
I still feel the FOMO. I still feel the guilt. I still forget to eat when the work is going well. But I have stopped trying to eliminate these feelings and started trying to manage them. They are a side effect of access to a genuinely transformative tool, and I suspect they will fade as the novelty wears off. Or they will not, and I will need to develop better coping mechanisms. Either way, the tool is not going anywhere, and neither is the work.
Key Patterns
The FOMO and addictive qualities of agentic coding stem from specific neurological mechanisms, not personality flaws. Variable ratio reinforcement creates dopamine patterns identical to those seen in gambling and social media addiction. Flow states suppress hunger, time awareness, and the default mode network. Parallelization amplifies FOMO by making every absent hour feel like lost weeks of engineering output. Decision fatigue and dopamine craving coexist, producing a state where you are simultaneously too tired to work well and too wired to stop.
The bottleneck has shifted from capability to presence. Pre-AI, your own limitations governed your output. Post-AI, only your physical availability limits what gets built. That shift changes the psychology of work in ways that the productivity literature has not yet addressed, because the literature assumed that human capability was always the constraint.
I do not have a clean solution, but five strategies help. Commitment anchoring (scheduling obligations with other people that FOMO cannot override) is the strongest forcing function I have found. Front-loading intensive work into morning hours aligns with the decision fatigue research. Pomodoro cycles turn breaks into protocol steps rather than interruptions, addressing both fatigue and the dopamine loop. Firing off a large prompt and physically leaving the room breaks the real-time feedback cycle. And accepting the math, including the fact that the next model generation will be even more capable, makes burning out on the current one look shortsighted.
None of them eliminate the fundamental tension of having access to a tool whose throughput exceeds your ability to supervise it. I suspect this is a problem that will define the first generation of serious AI-assisted engineers, and that we will look back on this period the way early smartphone users look back on their first years of compulsive notification checking: a transitional phase where the tools outpaced our ability to use them sustainably.
Additional Resources
- Agentic Coding and Decision Fatigue: The Cognitive Cost of Supervising AI for the cognitive cost of supervising AI
- The Leverage Factor: Measuring AI-Assisted Engineering Output for the leverage factor methodology and dataset
- The Leverage Factor, Part 2: Defending the Numbers for a defense of the productivity numbers
- Overlooked Productivity Boosts with Claude Code for practical Claude Code productivity techniques
- Flow (Psychology) on Wikipedia) for Csikszentmihalyi's original framework
- Go with the Flow: A Neuroscientific View on Being Fully Engaged for the dopamine and norepinephrine mechanisms
- The Neuroscience of the Flow State (Frontiers in Psychology) for locus coeruleus and norepinephrine involvement
- Engineered Highs: Reward Variability and Frequency as Prerequisites of Behavioral Addiction for variable ratio reinforcement research
- The Fear of Missing Out: Origin and Relationship with Mental Health (PMC) for FOMO as a psychological construct
- The Cognitive Cost of AI: How AI Anxiety Influences Decision Fatigue for AI-specific decision fatigue research
Let's Build Something!
I help teams ship cloud infrastructure that actually works at scale. Whether you're modernizing a legacy platform, designing a multi-region architecture from scratch, or figuring out how AI fits into your engineering workflow, I've seen your problem before. Let me help.
Currently taking on select consulting engagements through Vantalect.