One more turn

Last Sunday I built most of an app between turns of a barbecue. Turn the meat, check Claude Code. Refill someone's glass, read the diff, ship the feature, ask for the next one. Turn the meat again. My family was ten feet away and I was, technically, present. I was also having one of the best afternoons of work I'd had in months — standing over a grill, watching software assemble itself in the gaps between flipping sausages.

That's the part that should have worried me, and didn't. Not the working-on-a-Sunday part; I've done that my whole career when something was on fire. This was the opposite of on fire. Nothing was urgent. I just couldn't put it down. It was too enjoyable to stop, and the fact that it didn't feel like a problem is, I've come to think, exactly the problem.

This is the second of two posts on dépendance. The first was about the meaning your procurement team understands — the firm's reliance on suppliers it doesn't control, and how to keep the exit cheap. French folds two meanings into that one word, and this is the other one. Not dependence. Addiction. The pull. The reason the laptop stayed open next to the coals.

Three features before the meat was done

Here is the thing nobody warned me about: shipping is fun, and Claude Code lets you ship constantly.

You describe a feature. A few minutes later it exists — tested, wired in, more or less working. The old loop, where an idea took a day or a week to become real, has collapsed to minutes. And when you ship three features in an hour, you do not feel finished. You feel the opposite. You want a fourth. The reward arrives fast enough that the appetite never closes.

I watch this in myself, and I watch it in my data scientists and my developers. None of us seems able to stop. We talk about it on Slack the way you'd talk about a series you're bingeing — half boasting, half uneasy. The work got more rewarding per hour, and somehow that made us do more hours, not fewer.

It's a turn-based game

It took me a while to see why the pull is so strong, and then it was obvious: it's structured exactly like a turn-based game.

You think. You submit. You wait — fifteen seconds, ninety seconds, while the agent works. Then the result lands, and you take another turn. Think, wait, result, again. Anyone who has lost a night to Civilization knows the words "just one more turn" and knows they are a lie you tell yourself eight times. That loop — a small action, a short unpredictable wait, a reward, repeat — is the variable-ratio schedule that makes slot machines what they are. The wait is the pull of the lever. The shipped feature is the payout. And the payout is real — that's what makes it stronger than any game. You're not winning fake territory. You're shipping actual software.

Two things make it worse than a slot machine, for our purposes. It used to take friction to start coding — set up the environment, load the problem into your head, get into flow. That friction is mostly gone now; you can take a turn cold, in thirty seconds, from a phone. And it's portable in a way real work never was. You can take a turn standing over a barbecue. So the loop follows you out of the office and into the evening and the weekend, because there's nothing physical left to leave behind.

The brake is gone

Now the part I find genuinely unsettling, because it inverts something I'd assumed was permanent.

Coding in flow used to be self-limiting. It was absorbing, but it tired you in a way you could feel, and at some point your brain said enough and you stopped. The exhaustion was the brake.

The work has changed shape, though. With an agent, you're not in the flow of writing — you're reviewing code someone else wrote, and making the architectural calls about where it all goes. And reviewing someone else's work and holding a whole design in your head is heavier than coding in flow, not lighter. Anyone who has reviewed a colleague's pull request for an hour knows it drains you faster than writing your own.

So here's the trap. The work got more tiring per unit. But the reward got faster, and the whole thing feels like play. The fun masks the fatigue. The old warning light — this stopped being fun, I'm spent — never comes on, because it never stops being fun. It pays out faster than it tires you. You burn through your cognitive budget without the one signal that used to tell you the account was empty. That is why I couldn't stop at the barbecue, and why my team can't stop on a Tuesday night. The brake was never willpower. It was the work pushing back, and the work stopped pushing back.

What it actually costs

Two bills come due, and the second is the one your CFO should care about.

The first is burnout, and it sneaks up. Because the work feels like play, a team can deplete itself for weeks without anyone noticing — no late-night death march, no visible crunch, just a lot of people quietly unable to log off, having a great time, right up until they aren't. The bill arrives late and lagging: mistakes, cynicism, the good engineer who hands in their notice for reasons they can't quite articulate. You don't see it coming because it doesn't look like overwork. It looks like enthusiasm.

The second is subtler and, I think, more expensive. The genuinely creative ideas don't arrive during the turns. They arrive in the gaps — on the walk, in the shower, in the half-hour at the grill when your hands are busy and your mind is wandering. That wandering is not idleness; it's where your brain makes the non-obvious connection, reframes the problem, has the idea that was actually worth having. Fill every one of those gaps with one more turn and you don't just risk your health. You quietly stop having the ideas.

And look at what you're trading. The features Claude ships are the part AI made cheap. Judgment, taste, the original strategic idea — those are the parts AI made more valuable, because they're now the scarce input. By filling the gaps with more shipping, you spend the scarce thing to manufacture more of the cheap thing. You end the week having produced a great deal and thought almost nothing. That is a bad trade wearing the costume of a productive one.

(There's a third worry — whether we're losing the ability to do the work at all without the tool, the skill that quietly atrophies. That's real, but it's a different argument, and it's a post of its own. This one is only about not being able to stop.)

A manager's new job is to make people stop

Here is the reversal that makes this a problem for the people who run things, not just the people who code.

For your entire career as a manager, the job has been to get people to start — to push, to motivate, to fight under-work and procrastination and the meeting that should have been an email. Every instinct you've built points one direction. This tool fails in the opposite direction. It doesn't make people do too little. It makes your best, most engaged people do too much, happily, until something breaks.

So the new skill — and it is genuinely new — is protecting your team from a tool that's too good at being fun. In the AI era, part of managing a technical team is managing its rest, not just its throughput, because the tool quietly removed rest's natural enforcement. The person shipping features from their kitchen at 11pm on a Sunday is not a hero to be praised in the standup. They're an early warning. If you reward that, you'll get a quarter of spectacular output and then a hole in your org chart.

The honest limits

Let me be straight about what I'm not saying.

I'm not telling you to stop using it. Claude Code is the most productive and the most enjoyable way to build software I have ever found, and I'm not giving it up — neither is my team, nor should they. The point isn't abstinence. It's noticing the loop and putting a brake back where the work used to provide one.

Intensity genuinely suits some people, some of the time. A focused weekend on something you love is not burnout; sometimes it's the best part of the job. The danger isn't the occasional binge — it's the binge becoming the default with no off-ramp, and nobody noticing because it feels fine.

Rest has to be modelled, not surveilled. The wrong response to all this is monitoring when people commit code and policing their evenings — that's a different and worse problem. The right response is norms and example: leaders who visibly stop, who don't fire off Claude-built pull requests at midnight, who treat protected downtime as part of the work rather than a reward for it.

And it's hard to see until it's late. There's no clean metric for "my team is having too much fun to stop." You mostly catch it by paying attention, and by being honest about it in yourself first — which is why this post is in the first person.

What to do this week

You don't need a policy. You need a brake and a bit of honesty.

For yourself — install a hard stop. Pick a time the laptop closes, and an activity that genuinely takes both hands — cooking, a walk without the phone, anything where you can't sneak a turn. Protect at least one real gap a day where your mind is allowed to wander, because that's where the next good idea is hiding. When you notice the "just one more turn" feeling, that's the signal to stop, not to continue.

As a manager — change what you praise. Notice who on your team never seems to log off, and check on them before the standup, not after the resignation. Stop celebrating the weekend ship. Model stopping yourself: if you don't send the Sunday-night PR, you give everyone below you permission not to. Make protected downtime explicit and boring and normal.

Coda

The app I built at the barbecue works, by the way. But the best idea in it — the one bit of design I'm actually proud of — didn't come during a turn. It came an hour later, after I'd finally shut the laptop, while I was doing nothing more productive than eating. My mind, off the leash for the first time all afternoon, handed it to me.

That's the whole thing, really. The first post was about dépendance as the firm sees it: stay reversible, own your knowledge, keep the exit cheap. This one is the same lesson worn closer to the skin. The model is rented, the knowledge is yours — and so is your attention, your judgment, and the quiet hour where the good ideas actually arrive. The tool will happily take all three if you let it, one turn at a time, and it will feel great the whole way down.

So rent the model. Ship the features. And then close the laptop and turn the meat — properly, with both hands, thinking about nothing. That's not the break from the work. That's where the best of the work comes from.

If this landed a little too close to home, you're not the only one — reply and tell me how you put the brake back, I'm still working mine out. And if there's someone on your team who never seems to log off, this one's for them. Forward it.