Too Fast to Think: The Hidden Fatigue of AI Vibe Coding
Getting to the limits of what developers can do
After vibe coding for some time, I feel fatigue. I’m coding Marvai - a package manager for prompts on my own, with a combination of Claude Code and Cursor.
I use Claude Code for code generation, bug fixing, test writing, test fixing, security checks etc.
Claude Code is especially useful to fix linting errors from nilaway or staticcheck - for a developer those are boring and tedious.
I use Cursor for augmented coding, generate functions, adapt copy&pasted code, for refactoring, fix error handling, and many other tedious tasks.
I have been a coder for 40 years and I have seen many tools for developers that haven’t worked, like Model Driven Development MDD/MDA and executable UML.
With AI I’m now much faster at generating code and building features than I ever was before. The combination of Claude Code and Cursor is a real speedup.
I encountered a new phenomenon.
Again and again I feel fatigue. I finish a feature, and another feature, concetrate on reviewing the code the AI generated, and fix a bug and finish a feature with such velocity and I feel fatigue after some hours - sometimes as soon as one hour. AI working at such speed, finishing things to accept or review, feels too much for my brain to process or keep up with. I need to pause for some time before I can start again.
I haven’t felt this before as a developer.
I first encountered the concept of cognitive load in the book Team Toplogies. The idea there is to structure teams in a way that the cognitive load for developers is not too small and not to big. The more responsibilities a team and it’s members get, the bigger the cognitive load. And if you put many different topics on a team, the cognitive load for the team becomes too big for the team to work.
As a young adult I was working in a plastic factory, sitting at a machine. The machine produced vacuum cleaner cases, had it’s rhythm, it finished vacuum cleaner cases on it’s own schedule, made a “PING” when finished, opened the door and I had to grab the casing and put it down (and package it in fine paper etc. which took some time). The machine would close while I was finishing the casing. And for some time it was stressful, working to the rhythm of the machine. Then I got accustomed to the speed and rhythm, until my boss increased the frequency. Living by machine time is what I sometimes feel with Vibe Coding and Cursor generating code or Claude fixing a bug.
I had waiting times with compiling and waited for the machine to finish, but it feels differently, with vibe coding it feels like the machine is in control not me.
With traditional coding, the speed of your output matches the complexity of the task and the speed of your coding. This gives your brain time to process what is happening. With vibe coding the coding happens so fast, that my brain can’t process what is happening in real time, and thoughts are getting clogged up. Complex tasks are compressed into seconds or minutes.
My brain does not get the baking time to mentally process architecture, decisions and edge cases the AI creates - not enough time to put the AI output into one coherent picture. I’m running a marathon at the pace of a sprint - speeds don’t match.
One reason developers are developers is the dopamine loop.
You write code, it doesn’t work, you fix it, it works, great! Dopamine rush. Several dozens or a hundred times a day. Now this loop speeds up. Faster and faster we run around that loop, and get washed with Dopamine - and your brain gets overwhelmed. And stress hormones at the same time! You get fatigue - instead of the usually happiness and satisfaction of coding.
With coding there is a limit to context switching. A context switch in coding is like dumping the cache of your brain and reloading the cache of your brain with a new context. This takes time and energy. You need to build a mental model of the code, to decide what to change and how to change it and then writing the changes out into source code, the essence of coding.
With vibe coding the frequency of content switches speeds up tremendously - with the AI fixing and creating many different things in different packages or modules with one go. Even when I <tab>, <tab>, <tab> in Cursor, each change is a micro-content switch from function to function.
Each context switch takes energy, every context switch is heavy lifting for your brain. Normally this materializes as the fact that it takes time to context switch. With AI in the driver seat, context switches are forced on you faster and faster.
When each context switch takes energy, fast energy switches from feature delivered to feature delivered, vibe coding drains your energy - fatigue!
With AI it seems we all become managers, we all become reviewers. The core of the role is changing from turning requirements into code to managing AI output - more like a team lead manages the output of a team, but on a much deeper level. Your responsibility grows to manage a team of five with vibe coding, while still being a developer being responsible for the code. It’s like being a traffic officer in the middle of a busy intersection - which is a stressful job on it’s own - while also overseeing five intersections in parallel.
Reviewing, directing and guiding an AI puts more stress on you than writing code, where your writing matches your thinking and doesn’t jump ahead, with you in a rush to catch up.
What can be said:
Me and many more I assume feel fatigue from vibe coding
We need deliberate pacing when working with AI tools
We need AI-aware retrospectives to understand what is going on - perhaps having a daily retrospective to get the mind and the code in sync again
We need to be aware of new mental health challenges for AI coders
We might need to let go of micro managing AIs and trust the AI more - stop trying to bridge the gap between managing an AI and controlling it’s output
I don’t think we’ve figured out yet where this is going. AI has made us faster than we’ve ever been, but our brains haven’t caught up to the pace. We’re like early pilots flying with autopilot—capable, but drained. We need new rhythms, new boundaries, and new ways of thinking about what it means to “code.”
Maybe the future of coding isn’t just faster. Maybe it’s also slower in a way, on purpose.
This is a great summary of how I've been feeling recently too. As you say, even with just tab completions, there's additional context switching now.
While you're thinking about the code you're about to write, in comes the suggested completion, and you have to switch to review mode and very quickly decide whether to accept it or not, before you can get back to thinking mode again. This used to happen a few times a day with PRs, now it happens several times a minute.
My recent article (linked below) talks about my practical conclusions, but doesn't really explore the feelings that come along with them. Thanks for writing this Stephan and helping me start to think a bit more about them!
https://open.substack.com/pub/thecurioustechnologist/p/why-i-dont-vibe-code-any-more?r=mzky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false