I used to think the annoying parts of building software were just annoying. The build that took four minutes. The colleague who couldn't look at my pull request until the next morning. The client who needed three days to get back to me with an answer I already knew. I spent years trying to engineer those delays out of my work, because delay looked like waste, and waste looked like the enemy. If I could just remove the friction, I'd get the work without the wait.
Most of that delay is gone now. I run several companies at once, mostly alone, and on an ordinary day I have three or four AI agents doing something in parallel — one working through a change in a branch, one drafting a reply to a customer, one checking whether a fix from an hour ago actually held under load. None of them get tired. None of them go home. The moment I hand one of them a task it's already moving, and by the time I've clicked over to the next window, the first one is often finished and sitting there waiting for me to look at it.
For a long stretch I told myself this was simply a good trade, full stop. Work that used to take a week now takes an afternoon. Ideas that would have died on a whiteboard because nobody had the hours to try them get built the same day, cheaply enough that being wrong barely costs anything. I still believe that part. Running a company mostly through agents instead of a team is the best trade I've made as a builder, and I'm not going to pretend otherwise to make the rest of this essay sound more balanced than it is.
But somewhere in the last few months I noticed something that didn't fit the story I'd been telling myself. I wasn't writing less. I was reviewing more, deciding more, switching contexts more often than I ever had — and on the days I shipped an unusual amount, I was frequently more drained by the evening than I used to be at Leantree, the company I ran before this one, back when I had fifteen people and lost half my week to meetings that produced nothing anybody could point to afterward. That shouldn't be true. Meetings that go nowhere are supposed to be the tiring part. Shipping fast is supposed to feel good, and it does — which is exactly what made the exhaustion so hard to notice at first. It doesn't show up as a bad day. It shows up as a great one that costs more than it should.
One More Diff
There's a specific sensation that turns up after two or three hours of running agents back to back. You ask for something and it comes back mostly right. You ask for the next thing and it comes back right again. The distance between having an idea and watching it work collapses to almost nothing, and the loop is fast enough and successful enough that you don't feel the hours pass inside it. I don't think "addictive" is quite the right word — that word gets used too loosely online to mean anything precise anymore — but the mechanism underneath it isn't a mystery either. A short, repeated, mostly-successful loop is exactly the shape of thing that keeps attention engaged well past the point where it should have let go. More than once I've caught myself at eleven at night telling myself I'd just check one more diff, found something small wrong with it, fixed that, and then it's midnight and I've built half a feature nobody asked me to ship tonight.
A team of BCG-affiliated researchers surveyed close to fifteen hundred knowledge workers earlier this year and found that fourteen percent of people who use AI regularly report a specific kind of mental fatigue they've started calling brain fry — not from doing the work, but from supervising it. Workflows built around heavy oversight, where the human's job is mostly reading, correcting, and interpreting what a model hands back, produced meaningfully more mental effort and information overload than workflows where AI simply replaced a repetitive task outright and got out of the way. The same data traced something close to a curve: one or two tools running at once produced real gains, three sat near the peak, and past that the benefit reversed. A separate and much larger BCG survey, close to twelve thousand workers across fourteen countries, found that two-thirds of regular AI users report their job satisfaction has gone up — and forty-one percent of that same population report their cognitive load has gone up too, often the same people reporting both at once. I think that's the detail most arguments about whether AI is good or bad for how work feels manage to miss. It isn't a question with one right answer sitting underneath it. It's two effects running on the same nervous system simultaneously, and which one you notice mostly depends on what time of day someone asks you.
What Friction Was Actually Doing
What I keep circling back to, though, is that none of this is really about AI being tiring to operate. Writing a prompt isn't hard. Reading a diff isn't hard. What's hard is that the thing which used to regulate how much of this I could do in a day quietly disappeared, and nothing stepped in to replace it.
At Leantree, a good part of what I experienced as friction was doing a job I never gave it credit for: it was pacing me. A build that took four minutes gave me four minutes to sit with whether the plan behind it was even right in the first place, and that's a different kind of time than the four minutes I get back now, because now I usually spend it starting the next thing instead of questioning the first one. A colleague who genuinely couldn't get to my pull request before the next morning put a hard, natural stop on a decision — I made my case, and then I was done for the day whether I liked it or not, because there was nothing left for me to do about it until he woke up. Nobody designed either of those as a rest mechanism. They were just how slower systems worked, and slowness happened to leave gaps, and it turns out my attention had been using those gaps the way a body uses sleep, without me ever noticing the arrangement, let alone thanking it.
The Limit Moved, It Didn't Disappear
An AI-native company has almost none of those gaps left, and the handful it still has, I put there on purpose. There's no such thing anymore as the agent being busy and me having to come back tomorrow. If I can imagine six things worth building tonight, I can start six things worth building tonight, and every one of them will hand something back to me before I've finished making coffee. The constraint that used to live out in the world — in someone else's calendar, in a machine that was slower than the one I'm running now — hasn't disappeared so much as moved. It's sitting inside my own head at this point, and my head was never built to carry that many open loops simultaneously, because until a couple of years ago, nothing had ever asked it to.
This is where I think the standard worry about AI gets the shape of the problem wrong. The version you hear most often is about judgment eroding — that people will stop thinking for themselves because the machine does the thinking instead. I don't see that happening to the people I know who use this seriously, myself included. If anything the judgment sharpens, because you exercise it constantly, on more decisions, at a faster clip than before. What I see instead is judgment running at a pace with no natural ceiling on it, applied by someone whose attention very much has one, with nothing left standing between the two to say when enough is enough. My problem was never that I'd stop thinking. It's that I wouldn't stop.
Building My Own Rate Limiter
I don't think the answer is using AI less. I've tried talking myself into that version of discipline and it falls apart the moment it meets the actual math — an afternoon with three agents genuinely replaces a week of the old way of working, and pretending otherwise just to protect my own pacing would be its own kind of self-sabotage, throwing away the best tool I've ever had because I hadn't yet worked out how to hold it properly. If there's a fix, it has to be a constraint I build on purpose, the way you'd put a rate limit on an API that has no natural ceiling of its own — not because the API is broken, but because nothing downstream of it will ever tell it to stop by itself.
So that's roughly what I've been doing, unevenly, and I want to be honest that I don't think I've solved it so much as started arguing with it. I try to keep the number of things genuinely open in my head small enough that I can hold the real state of each one, and for me that's landed close to what the BCG data found on its own — somewhere around three live threads, not six. I've started letting agents run without watching every step, on a delay, so that reviewing becomes something I schedule rather than a reflex I perform every time a notification lands. And I've begun treating the end of a working day as something I have to actively manufacture myself, because nothing in the systems I run does it for me — they would happily hand me a finished diff at midnight and wait, patiently, forever, for the next instruction, without judgment, without needing sleep, without ever once telling me that's probably enough for today.
That last part is the one that's actually changed how I think about what I'm building. Most of the infrastructure work in this company over the past year has gone into things that watch other things — health checks, monitors, alerts, systems built specifically to notice when another system breaks and say something before I have to go looking for it myself. It hadn't occurred to me until fairly recently that the one process running here with no watchdog on it at all was me. Every long-running job I operate has a limit written down somewhere on purpose, because I know from experience that an unbounded process eventually takes down whatever it's running on. I never wrote one down for myself. I don't think most people have, yet, for this particular version of the problem — it's new enough that most of us still seem to be finding our own limit the same way I found mine: by quietly running past it first, and only noticing afterward what it cost.
