How AI-powered hyperfocus loops can quietly burn you out — and why the danger extends far beyond developers.
A few days ago, I came across a Reddit post titled "I think we need a name for this new dev behavior: Slurm coding." I expected a joke, maybe a meme. By the time I finished reading, something had shifted.
The author, referencing Futurama's Slurms MacKenzie — the party worm who just kept going forever — was describing a pattern anyone using AI coding tools would recognize. You start with a small idea. You ask an LLM to scaffold a few pieces. It works. Suddenly you're refactoring the architecture, adding features, building a cross-platform version of something that didn't exist a week ago. You sit down after dinner and resurface at 3am with an entire system running.
It was well written, energetic, charming, and deeply relatable. I expected to laugh and move on.
Instead, it stayed stuck with me for days. Because the author was describing, with admiration and humor, a pattern that nearly destroyed me. Not once — three times.
The loop before AI
I need to be honest about something: this loop is not new. AI has supercharged it, but the fundamental pattern has been running in my brain since I was a teenager.
In the late 1980s, I was writing Turbo Pascal on MS-DOS. Self-taught, no computer science education, just a kid fascinated by what these machines could do. I built a text windowing library — overlapping windows, resizable, pretty sophisticated for the time. Then a menu system on top of it, configurable by file instead of hardcoded. Then a generic library for single and double linked lists and binary trees. Then a printing library for arbitrary report generation. Then I started on a database module.
Each piece triggered the next. One idea fed another. I was learning and building simultaneously, and the combination was intoxicating.
The project died when I hit Turbo Pascal's 64KB binary limit. My libraries consumed about 95% of the available space, leaving no room for actual applications. I still have a large binder of printed code somewhere. But the lesson I didn't learn — couldn't learn, at that age — was that the loop itself was the product. Not the software. The feeling.
That feeling followed me through decades. In my thirties, coding late into the night. In my forties, spending weekends on work projects instead of being fully present with my family. By then we were living in Asia — Hong Kong first, then Singapore — where I held senior roles at a major bank. In 2011, I left the bank to start a company, writing Objective-C for iOS with the same all-consuming intensity. When that venture failed, the loop didn't vanish — it shifted. I poured my energy into wildlife photography for over a year, until I found a new role at the same bank and resumed my usual pattern: adjacent coding, Excel pivot tables and formulas, always finding ways to build systems even without a compiler. The medium changed. The wiring didn't.
What AuDHD has to do with it
I was diagnosed with ADHD and autism — AuDHD — at 55. My daughter had been diagnosed about ten years earlier. My wife just before we left Singapore to return to Switzerland in 2022, after sixteen years in Asia. We'd recognized the shared traits for years. The autism part was more of a formality for me; I'd known for a while.
The ADHD part hit differently.
In early 2023, hoping to get a handle on my procrastination, I found a YouTube channel called "How to ADHD." After one video, I was stunned. She was talking about me. I watched it again. At 55 years old, I couldn't watch her other videos without my wife sitting next to me. I needed someone there to help me digest what I was learning about myself.
Think about that for a moment. A grown man, decades of professional experience across continents, and I needed support to watch YouTube videos about my own brain.
The diagnosis didn't explain one single thing in my life. It explained all of it. The special interests. The inability for small talk without alcohol to smooth the edges. The compulsion to dive into any rabbit hole and go deep, deep down. The meltdowns when technology fails — because computers aren't just tools for me, they're part of my identity. I learned English from computer user manuals as a French-speaking teenager. They've been woven into who I am since my early teens.
It also explained the coping mechanisms I'd built over a lifetime. Smoking. Drinking. Spending money I shouldn't have. One by one, I dismantled them. I quit smoking in 2012. My alcohol consumption dropped gradually to once or twice a year. And when I recognized the spending pattern as a danger to my family — we'd bought a house, we had a life to protect — I asked for an administrative guardianship with my wife as guardian.
That took everything I had. It also left me exposed. All the buffers were gone.
Three burnouts and what I didn't see coming
Here's what I know about burnout: you don't see it coming. You especially don't see it coming when you have a brain that's wired for hyperfocus, perfectionism, and an overwhelming need not to let the team down.
The first burnout hit at the end of my physics studies. I never finished my Master's. At the time, I didn't have a name for what happened. I just couldn't continue.
The second came in 2011 when I left the bank to start a company. The timing was terrible. The experience was rich; the outcome was financially disastrous. I coded through it with the same intensity I'd always had, and when it collapsed, so did I.
The third, in mid-2023, was the one that finally got named. My wife saw it before I did. "You need to see a doctor. I think you are having a burnout." She was right. She usually is.
I'm now working at 60% capacity. The remaining 40% is about to be declared a legal partial disability. I'm 58, and I won't fully get back on the horse. That's not self-pity — it's arithmetic. Each recovery has taken years. The reserves aren't what they were.
There's a fallacy we all fall for: these things only happen to other people. We ignore the signs and keep going. And we tend to be the last ones to know.
The LLM asymmetry
Now here's where the Reddit post becomes something more than a relatable anecdote.
When I used to code with another person — a colleague, a collaborator — there were natural breaks. They'd go home. They'd forget what we discussed and we'd need to re-establish context. They'd get tired and say "let's pick this up tomorrow."
An LLM does none of that.
It waits indefinitely. It loses nothing. It never signals fatigue. And when you have a brain that's already wired to ignore its own needs in pursuit of an interesting problem, this asymmetry is genuinely dangerous.
I know this because I've lived it. In the past few months, working with AI tools, I've watched projects explode in exactly the way the Reddit post describes.
I started building a semantic search tool for my codebase — a side project. Three months later, it had grown into a full knowledge management system with code intelligence, document storage, a background daemon, a CLI, and text search with trigrams optimized to outperform ripgrep. From an idea to an ecosystem, organically, each feature triggering the next.
I wanted to build a database for my fountain pen collection — how to manage rotations of pens and inks. I ran into the problem of qualifying colors objectively. That opened a color science rabbit hole. Out came a Munsell color space library implementing mathematical transformations from public-domain research dating back to the 1930s, plus an overlay system from a recent academic paper. The library is open source now. The pen database still isn't finished.
I wanted to relearn how to use a slide rule. That project spawned a Lua-Swift integration library, a numerical methods library inspired by SciPy, an array library with NumPy-style broadcasting, a plotting library modeled on Matplotlib and Seaborn, a computer algebra system in Rust, and several other open-source packages. The slide rule app itself is still in progress.
Each of these is a textbook example of the Slurm coding loop. And none of them involved a single sleepless night — because I've learned, at great cost, where that leads. But the pull is constant. The ideas don't stop. And the AI is always ready to go.
The guardrails I have, and the ones I don't
I use a break timer — Break Time, from Parallels — set for every 50 minutes with a 10-minute break. It starts automatically in the morning and stops in the early evening. When it fires, the screen dims and a countdown begins. I can snooze or skip it, but doing so requires a deliberate action. I can't pretend I didn't see it.
In theory, this works. In practice, when I'm in a conversation with an AI and ideas are flowing, it's always too easy to skip. "We're in the flow, we have so many things to explore, why stop now?" The rationale that the LLM will simply wait — that nothing is lost by taking a break — is often lost on me in the moment.
I have a strict bedtime. Around 10pm, sometimes a bit later, never past midnight. I wind down with an audiobook and a game on my phone. Medication helps me fall asleep. When I feel the effect: stop the book, phone on the charger, lights off. This routine is non-negotiable, and it's probably the single most important guardrail I have.
My wife is the ultimate safety net. She's observant in ways I'm not. She sees the patterns before I can even imagine them. But I don't want to be solely reliant on her. She has enough on her plate, and adding friction to her life isn't something I'm willing to do.
So I'm experimenting. I'm considering physical programming books — Rust, Swift, TypeScript, Zig, color science — as a way to keep learning without the LLM amplification loop. Slower, more deliberate, and it splits the day into smaller, more manageable chunks. I'm also looking at tools that create stronger friction than my current timer.
My intuition tells me the solution won't be a single thing. It'll be a series of things: some creating forceful friction, others creating dilution — keeping the content interesting while splitting it into pieces that are easier to manage. But I have to be careful. Building habits can trigger something called PDA — Pathological Demand Avoidance — and if that happens, everything has to be rebuilt from the ground up. I can't use the same trick twice.
As a physicist by training, I think of it as two competing potential wells. One voice says "take a breath." The other says "you're in the flow, don't stop now." Which one wins depends on their relative depth and distance, and I can't always predict what positions them. It's not binary. It's not simple. It's always a combination.
This isn't just about developers
Right now, Slurm coding lives in the tech world. Developers with AI tools, building things at a pace that wasn't possible a few years ago. But I don't think it stays there.
Agentic AI systems are going to spread. They'll reach people who don't write code — professionals of all kinds setting up automated workflows, building things, getting caught in the same feedback loop. Idea, build, it works, dopamine, bigger idea, keep going.
We talk about the dangers of AI in abstract terms — job displacement, misinformation, autonomy. But there's a quieter risk that lives at the human level: the risk of what happens when a tool that never gets tired meets a person who doesn't know when to stop.
Will the people around them understand what's happening? Will they see the signs? Are there universal signs, or are we all different enough that a one-size-fits-all warning wouldn't work?
I don't have all the answers. I'm not sure anyone does yet.
We are not machines
My burnout wasn't caused by Slurm coding. But if the tools I have now had existed then, I'm certain it would have come faster and hit harder.
What I wish someone had told me — what I want to say clearly — is this: it's not a lesson, and it's not a moral. It's about sharing what I've learned. It's about giving clues, not having all the answers. It's about being honest that the thing you love doing can also be the thing that breaks you, and that you'll likely be the last person to notice.
There are people who sleep four hours a night and bulldoze through their days without consequence. They exist. They're annoyed when they have to take holidays. Despite what we'd like to think, most of us are not built that way.
There can still be enormous fun in these fascinating, immersive activities. So much fun that the longer you can sustain them, the better life is. But the key word is sustain. Giving your body and mind a break is not too high a price to keep doing what you love for as long as humanly possible — or until the next shiny thing captures your attention entirely.
No matter what, we are not machines. We are humans.
The original Reddit post ends with: "Party on. Keep coding."
I'd add three words: And make it last.
The original Reddit post that inspired this article is reproduced below with the author's permission.
"I think we need a name for this new dev behavior: Slurm coding"
By u/Khr0mZ — posted March 9, 2026 on r/ClaudeCode
A few years ago if you had told me that a single developer could casually start building something like a Discord-style internal communication tool on a random evening and have it mostly working a week later, I would have assumed you were either exaggerating or running on dangerous amounts of caffeine.
Now it's just Monday.
Since AI coding tools became common I've started noticing a particular pattern in how some of us work. People talk about "vibe coding", but that doesn't quite capture what I'm seeing. Vibe coding feels more relaxed and exploratory. What I'm talking about is more… intense.
I've started calling it Slurm coding.
If you remember Futurama, Slurms MacKenzie was the party worm powered by Slurm who just kept going forever. That's basically the energy of this style of development.
Slurm coding happens when curiosity, AI coding tools, and a brain that likes building systems all line up. You start with a small idea. You ask an LLM to scaffold a few pieces. You wire things together. Suddenly the thing works. Then you notice the architecture could be cleaner so you refactor a bit. Then you realize adding another feature wouldn't be that hard.
At that point the session escalates.
You tell yourself you're just going to try one more thing. The feature works. Now the system feels like it deserves a better UI. While you're there you might as well make it cross platform. Before you know it you're deep into a React Native version of something that didn't exist a week ago.
The interesting part is that these aren't broken weekend prototypes. AI has removed a lot of the mechanical work that used to slow projects down. Boilerplate, digging through documentation, wiring up basic architecture. A weekend that used to produce a rough demo can now produce something actually usable.
That creates a very specific feedback loop.
Idea. Build something quickly. It works. Dopamine. Bigger idea. Keep going.
Once that loop starts it's very easy to slip into coding sessions where time basically disappears. You sit down after dinner and suddenly it's 3 in the morning and the project is three features bigger than when you started.
The funny part is that the real bottleneck isn't technical anymore. It's energy and sleep. The tools made building faster, but they didn't change the human tendency to get obsessed with an interesting problem.
So you get these bursts where a developer just goes full Slurms MacKenzie on a project.
Party on. Keep coding.
I'm curious if other people have noticed this pattern since AI coding tools became part of the workflow. It feels like a distinct mode of development that didn't really exist a few years ago.
If you've ever sat down to try something small and resurfaced 12 hours later with an entire system running, you might be doing Slurm coding.
Top comments (0)