DEV Community: Christian C. Berclaz

Party On. Keep Coding. And Make It Last.

Christian C. Berclaz — Tue, 17 Mar 2026 23:00:00 +0000

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.

Why I built codesize: enforcing function length limits with an AST

Christian C. Berclaz — Sat, 14 Mar 2026 19:53:00 +0000

Every team I have worked on had some version of the rule: "keep functions short." It shows up in style guides, code review comments, and onboarding docs. It almost never shows up in CI.

When it does get automated, the tooling usually reaches for wc -l on the whole file. That is a rough proxy at best. A 300-line file might contain five short, readable functions and a big block of comments. A 150-line file might contain one function that does the work of three. File length and function length are different problems.

In the advent of AI, these constraints can be even more difficult to enforce.

I built codesize to check the thing that actually matters: how long each function is.

Why existing tools fall short

cloc and similar tools count lines of code, but at the file level. Linters can flag long functions, but they are language-specific — you need a different one for every language in a polyglot repo, each with its own config format and output schema.

What I wanted was a single binary that could scan a mixed-language project and produce a uniform report: which files exceed their limit, which functions exceed their limit, sorted by how far over the line they are.

Using tree-sitter to find function boundaries

codesize uses tree-sitter to parse each source file and walk the AST to find function boundaries. Instead of counting lines in a text buffer, it counts the lines that belong to each function from signature to closing brace.

This handles a number of cases that trip up simpler approaches: blank lines inside a function body, comments interleaved with code, string literals that happen to contain braces, and nested functions. Arrow functions in JavaScript and TypeScript are counted as functions. Constructors in Java are counted. Nested functions in Rust and Python are each counted independently.

Ten languages have built-in grammars: Rust, TypeScript, JavaScript, Python, Go, Java, C, C++, Swift, and Lua. For any other language you can add an extension mapping in config and still get file-level enforcement — you just won't get per-function analysis until a grammar is available.

What the output looks like

Results go to a CSV file (or stdout with --stdout). Six columns:

language	exception	function	codefile	lines	limit
Rust	function	build_report	src/scanner.rs	95	80
Python	file		src/legacy/monolith.py	450	300

The exception column is either file (the whole file is over the limit) or function (a specific function is). For file-level violations, function is empty. Rows are sorted by language, then by line count descending, so the worst offenders are at the top.

This format was a deliberate choice. CSV goes everywhere: spreadsheets, GitHub issue imports, Jira, Linear, a shell pipeline. The intent is not to fail a build on day one — it is to generate a list of violations you can work through over time, treating function length as technical debt to be retired gradually rather than a gate that blocks you immediately.

Configuration

Limits are per-language and fully configurable in a TOML file at ~/.config/codesize/config.toml:

[limits.Rust]
file     = 500
function = 80

[limits.Python]
function = 50   # leave file limit at the default 300

You can also add languages that have no built-in grammar:

[languages]
".rb" = "Ruby"

[limits.Ruby]
file     = 300
function = 30

When you are onboarding an existing codebase with a lot of violations, the --tolerance flag lets you start with headroom and tighten the limits over time:

# Report only functions more than 20% over the limit
codesize --tolerance 20 --gitignore

Once the backlog is clear, drop the tolerance and the limits become exact.

CI integration

For GitHub Actions, there is a companion action that installs and runs codesize with no setup beyond a checkout:

# .github/workflows/codesize.yml
name: Code size check
on: [push, pull_request]
jobs:
  codesize:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ChrisGVE/codesize-action@v1.0.0

The --fail flag makes codesize exit with status 1 when violations are found, which is what you want for a blocking CI check. Without it, the tool always exits 0 and just writes the report — useful for the gradual rollout approach.

Try it

Install via Homebrew (macOS and Linux):

brew install ChrisGVE/tap/codesize

Or from crates.io:

cargo install codesize

Shell completions for zsh, bash, and fish are included. When installed via Homebrew they are set up automatically; otherwise run codesize init <shell> to generate them.

Source, issues, and the full CLI reference are at github.com/ChrisGVE/codesize. The companion GitHub Action is at ChrisGVE/codesize-action.