The use of AI is leading to burnout among its greatest advocates as they hit the limit of their meta-cognitive abilities:
“I end each day exhausted—not from the work itself, but from the managing of the work. Six worktrees open, four half-written features, two ‘quick fixes’ that spawned rabbit holes, and a growing sense that I’m losing the plot entirely.”
As someone with ADHD, this sounds painfully familiar. I’ve been spinning up workloads like that my whole life chasing the dopamine dragon. And as my fellow neuro-spicy siblings all know, there’s the thinnest of lines between “Oh wow I’m going so fast!” having fun being optimally stimulated and “Oh shit fuck no ow help cry ow” collapsing on the floor in desperation. It all reminds me of an old business book…
The Goal by Eliyahu M Goldratt is a charming bit of manager porn on the topic of fixing industrial bottlenecks that I think illustrates the problems of unthoughtful acceleration-ism1 2. Andrew Murphy cited the same book when he highlighted the problems of more code at the organizational level. More inventory (read: lines of code) does not equal more velocity, it leads to more lingering PRs and CI runs that need rebasing attention. It’s decaying work that creates more work. Each line of code is a future maintenance liability, a future addition to your context window. You didn’t fix the bottleneck, you moved it downstream.
The most eye-opening parts of The Goal for me was understanding that excess inventory isn’t free, it’s a pile of sunk costs that takes up space, costs to store, and takes more time and effort to process. As Andrew puts it, increasing velocity at one end of the production line without actually fixing the bottleneck at the other end…
Congratulations! You’ve built a factory that’s world-class at producing inventory that sits on the floor and rots.
This bottleneck is what’s happening in our brains. When you ask a machine to build infinite apps, it will do that. When you ask a machine that generates more tasks, it will do that. It will churn through it. Ultimately, the backlog of backlogs and all the endless microscopic UI bugs becomes a form of excess inventory you need to manage. It might not seem like a heavy price at first because you’re feeding it back to the machine, but there’s a compounding cognitive load tax that comes from context-switching between major projects. You need to load the entire project state into your context window each time the command line dings and that’s calorically expensive.
I’m not ashamed to admit I’ve abandoned at least two projects because the LLM generated more code than I wanted to read. I looked at all the folders of files and said “Meh” and closed my laptop.
Over-generating code leads to what Margaret Storey calls “Cognitive Debt”, a form of technical debt where the product exists beyond your understanding. This is where security, accessibility, and performance problems lurk. Most engineers have experienced being hot-dropped into a project-on-fire where you have no prior understanding of the codebase… it’s not a fun experience. You spend most of your time building a mental model of the codebase3 for what might be a one-line fix.
At the end of the chain of 10,000-watt GPUs sitting in a data center in Iowa is the 40-watt lump of meat inside your skull. It’s an incredible, efficient, miraculous lump of meat that has millions of years of bio-engineering behind it… but understanding is the new bottleneck. If brains are a scarce resource, then we should take care to not over-produce inventory. That goes for ourselves and our organizations.
-
If you want a more modern retelling of The Goal centered around a software shop, check out The Phoenix Project. ↩
-
The graphic novel version of The Goal is also great. ↩
-
The first thing I do when paratrooping into a new codebase is to annotate what’s inside each directory. AI can help with this now, but if I do it my mental model grows along with my exploration. ↩