Maintenance Mode: Why the Best Developers Treat Themselves Like Production Systems

Last updated: 2026-03-31

You have health checks on your containers. Alerting on your database. Automated failover when a pod goes down. You probably have better observability on a $5/month VPS than you do on the system running the whole operation: you.

This is the zone nobody wants to write about, and the one that matters more than any deploy pipeline or agent orchestration layer. Maintenance Mode is about keeping the human in the loop operational.

I run on ADHD. I code with AI all day. I''ve shipped entire features in single hyperfocus sessions that felt like time travel, then spent the next two days unable to open a terminal. If that pattern sounds familiar, this post is for you.

Why does AI-assisted development burn people out faster?

Vibe coding with AI introduces a kind of fatigue our industry hasn''t named yet.

BCG published research in March 2026 calling it "AI brain fry". Their study of 1,488 workers found that 14% already experience it. You''re not just writing code anymore. You''re reviewing AI-generated output, deciding whether to trust it, holding your own mental model while evaluating someone else''s, and context-switching between creation and QA dozens of times per hour.

That''s a different cognitive pattern than typing code yourself. You''re running two mental processes in parallel: your intent and the AI''s output. Every time they diverge, your brain burns energy reconciling them.

A Faros AI study across 10,000 developers found that AI users were actually 19% slower on average, despite believing they were faster. Not bad tooling. The invisible overhead of constant evaluation and judgement calls.

Stack that on top of already-rising exhaustion across the industry. LeadDev''s 2025 survey found 22% of engineering leaders at critical burnout levels, with another 24% at moderate. Those numbers were measured before AI coding tools became the default workflow.

What makes the ADHD-developer burnout cycle different?

Standard recovery advice doesn''t work for ADHD brains. "Take regular breaks" sounds great until you''re six hours into a hyperfocus session and your brain is producing more dopamine than it has all week. Breaking that flow doesn''t feel like rest. It feels like someone unplugging you mid-download.

The Stack Overflow blog covered this in 2024: ADHD developers exist in a cycle between hyperfocus and burnout that neurotypical productivity frameworks don''t account for. The hyperfocus isn''t optional. It''s how our brains compensate for the executive function gaps that make "normal" sustained focus difficult.

Here''s what the cycle actually looks like. You hit a problem that''s interesting enough to lock in. The world drops away. You ship an unreasonable amount of work in one session. Then you hit the wall. Hard. Not "I''m a bit tired" but "I can''t form a coherent thought and opening Slack gives me anxiety."

ADDitude Magazine calls it the hyperfocus let-down. As they put it: "The ADHD brain''s dopamine system works differently, requiring more stimulation to feel motivated, which is why hyperfocus states are so consuming and why the crash afterward feels so complete." When it runs dry, everything becomes harder. Focus. Motivation. Basic task initiation.

AI coding tools pour fuel on this. Prompt goes in, code comes out, and that instant feedback loop creates exactly the rapid-reward cycle ADHD brains lock onto. Vibe coding is hyperfocus fuel. It makes the productive sprints more intense and the crashes deeper.

How do you apply SRE thinking to yourself?

Your brain is a production system. I stopped treating that as a metaphor and started treating it as an operational reality.

You''d never run a production server at 100% CPU continuously and expect it to perform well. You wouldn''t skip maintenance windows because the system is "fine right now." And you''d never ignore degraded performance metrics because the service is technically still responding.

But that''s exactly how most of us treat ourselves.

SRE vocabulary works better than wellness culture here:

Uptime is not 100%. No production system targets 100% uptime, and neither should you. Five-nines availability on a server is 99.999%, which still allows for 5 minutes of downtime per year. Your personal SLO should be even more generous. The goal is sustainable throughput, not maximum throughput.

Maintenance windows are scheduled, not reactive. You don''t wait for a server to fall over before rebooting it. Schedule your downtime before your system forces it. For me that means hard stops at specific times, not when I "feel tired" (because ADHD brains are terrible at interoception and I''ll feel tired approximately never until I''m already crashed).

Graceful degradation beats hard failure. When a system is under load, you shed non-essential traffic. When your brain is approaching its limit, shed non-essential decisions. Close Slack. Leave the PRs. Drop the context-switching. Protect the one thing that''s actually producing value and let everything else wait.

Incident response needs a runbook. When you do crash, and you will, have a recovery protocol that doesn''t depend on willpower or motivation, because those are the exact resources you''ve depleted. Mine involves a specific playlist, a specific location, and absolutely no screens for a minimum of two hours.

What does maintenance mode actually look like in practice?

Systems, not willpower. Stop relying on the thing ADHD brains are worst at: consistent self-regulation through executive function.

90-minute blocks with hard boundaries. Not "work until I feel like stopping." An actual timer. When it fires, I stand up regardless of where I am in the task. I learned this the hard way: "just five more minutes" with ADHD is never five minutes. It''s two hours and a missed meal.

Context dumps before shutdown. Before stopping any session, I spend 3 minutes writing down exactly where I am, what the next step is, and any state that won''t survive a break. ADHD working memory is a whiteboard that someone wipes clean every time you look away. Anything not written down is gone.

No-decisions-after-6pm rule. Decision fatigue compounds through the day, and AI-assisted development accelerates it because every AI output requires a judgement call: accept, reject, modify. By evening, my ability to choose well has degraded enough that any call I make is likely wrong. So I stop making them.

One offline day per week. Not "no coding." No screens with work on them. This is the weekly maintenance window. No tickets, no PRs, no "quick check on that deploy." If the production system can''t survive 24 hours without you, that''s a reliability problem.

Energy auditing. I track which activities drain versus restore cognitive capacity. Debugging an agent pipeline? Draining. Sketching system architecture on paper? Restorative. Reviewing AI-generated code for correctness? Extremely draining. Riding a motorcycle? Hard reset. This lets me schedule work like I''d schedule jobs on a server: expensive operations go in peak windows, cheap tasks fill the gaps.

What does a personal SLO actually look like?

Concrete. Measurable. Not aspirational.

Here''s what mine look like (yours will differ, tune them to your own system):

• No deep-work session exceeds 3 hours without a hard 30-minute break. Not negotiable. Not "unless I''m in flow." Especially if I''m in flow. That''s when ADHD brains are most at risk of burning through their reserves.
• Maximum 2 major context switches per day. Switching between projects or problem domains has a higher cognitive cost than most people realise. For ADHD brains, each switch can cost 20-30 minutes of ramp-up time. Two per day is my limit.
• Weekly maintenance window is sacred. One full day offline. 52 out of 52 weeks. This is my 99.x% uptime target for the year. Skip the maintenance window, and unplanned downtime follows.
• Crash recovery protocol activates immediately. No "push through it." When I recognise the signs (task initiation failure, irritability, inability to hold a thought for more than 30 seconds), the runbook fires. Screen off. Walk. Music. Minimum two hours before I reassess.

These aren''t goals. They''re operational constraints. A rate limit on an API isn''t aspirational. It''s what keeps the system stable.

How do AI coding tools change this equation?

AI tools are amplifiers. They multiply your productive capacity during hyperfocus, and they deepen the crash when it comes.

Vibe coding with Claude or Copilot creates a tight feedback loop that ADHD brains find irresistible. Prompt, result, evaluate, prompt, result, evaluate. Each cycle delivers a small dopamine hit. You''re shipping features at a pace that would have taken days, finishing in hours.

But each evaluation cycle costs cognitive energy. And because the feedback is instant, you burn through reserves faster than writing code manually. Manual coding has natural governors: thinking time, typing time, compile time. AI removes them. You accelerate without friction until you hit the wall.

So keep using them. Just respect the operating limits the same way you would with any high-performance tool.

A chainsaw cuts faster than a handsaw. That''s why it has more safety features, not fewer.

Frequently Asked Questions

Is ADHD actually common in software development, or just a Silicon Valley stereotype?

The data suggests it''s genuinely more prevalent. Analysis of the 2022 Stack Overflow Developer Survey found roughly 10.5% of developers reported concentration or memory difficulties consistent with ADHD, compared to the general population prevalence of 4-5%. The self-selection makes sense: ADHD brains are drawn to work that rewards novel problem-solving and intense short-duration focus, which describes most of software development.

I don''t have ADHD. Does any of this apply to me?

Most of it applies to anyone doing AI-assisted development. The cognitive load patterns, the decision fatigue accumulation, the missing recovery systems are universal. The same applies to anyone running Claude, Copilot, or multi-agent workflows at scale. ADHD just makes the consequences hit faster and harder. Think of it as the canary in the coal mine: if these patterns burn out ADHD developers first, they''ll eventually reach everyone.

How do I bring this up at work without sounding like I''m making excuses?

Frame it in systems language your team already understands. "I''m implementing maintenance windows to prevent unplanned outages" lands better than "I need mental health breaks." You''re not asking for special treatment. You''re applying the same reliability engineering principles your team uses on production systems, to the most critical system in the pipeline.

What tools actually help with managing this?

Timers that you can''t dismiss (I use a physical one, not an app, because apps are too easy to ignore). A paper notebook for context dumps (screens during breaks aren''t breaks). A calendar with blocked time that colleagues can see but can''t book over. These are boring, low-tech solutions. That''s the point. The system has to work when your executive function is at its worst, not its best.

The best developers I know don''t have more discipline than the rest of us. They have better systems. They build the same guardrails around themselves that they build around their production infrastructure, because they''ve learned, usually the hard way, that the most expensive outage is always the one running the whole operation.

Your servers have health checks. Your CI pipeline has gates. Your database has automated backups.

Build the same thing for yourself. That''s maintenance mode.