The Human-in-the-Loop Is Tired: Why AI Makes Programming More Exhausting
Programming with LLMs is genuinely useful but destabilizing, creating a unique fatigue from constant supervision rather than creation. While AI automates the satisfying parts of coding, it leaves developers managing incoherent outputs and losing the dopamine hits of solving problems. This shift intensifies work, isolates teams, and breaks the natural feedback loop, turning the craft into a lonely, exhausting cycle of review and correction.
Programming with an LLM is an intensely solitary activity where the satisfying part shrank, the exhausting part grew, and there are no new rewards to fill the gap.
- appplication
> Here's a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.
Say what you will about the Claudisms in this piece, this bit certainly rings true for me. With old school coding, there was always a reward at the end, the harder it was, the more satisfying it felt.
With agentic coding, I really doesn’t feel like that, at least not in the same way. It feels more like continually riding a wave of productivity, where small features or huge features have similar levels of interaction required. And that’s exciting in the beginning but quickly becomes very tiring.
- zem
unlike the op, I've been having a wonderful time using claude, both at work and for my own personal projects, so I will share what has worked for me, just in case it resonates with anyone else.
my anecdotal advice is to avoid the entire "agent" temptation, and treat the LLM as a code generator. have a single session running at a time. come up with a plan, iterate on it until you are satisfied, then tell it to execute the plan, and watch it. not necessarily to the extent of reading the scroll (though I sometimes do do that too!) but as it finishes each step look over what it has done, suggest improvements and course corrections, and then let it go on to the next step. at the end you will have a pretty good grasp of the state of the code, and the overall time it will take you isn't really any longer than trying to churn out reams of code and then go through it all at once.
the other option if you want something closer to a one shot workflow is to go into far more detail during the planning stage, have it describe not just architectural details but actual code (if you're a senior engineer especially you probably know what the key pieces of code that will drive a lot of other decisions mechanically are likely to be).
also refactoring is cheaper than it has ever been, if something feels hard to grasp to you stop and work with the LLM until you like the looks of it better.
and again, the key bit is to have one LLM doing one thing at a time, and to stay engaged in the process while […]
- bad_username
> Yes the code (sorta) writes itself, but the human reviewing, directing, and course-correcting feels worse, not better.
I noticed the opposite. When reviewing and directing a colleague or subordinate, I spend probably 30% of my brain cycles, and 70% of my activation energy, to weigh the technical merit of my feedback against the human impact it will make: bruised egos, differing architectural convictions, correct and polite tone of comments, additional workload for the colleague. The dread of potentially seeing that the code is not good at all, and needing to decide _what to do in that situatuon_, trading off technical debt in the future vs team dynamics and psychological impact right now.
LLM does not care about any of that. It is so much easier.
- BrandonM
> But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part.
I keep wondering what I’m missing in the AI enthusiasm, and maybe this is a big part of it? Writing code has never felt like the hard part to me.
In my 20s, I was excited about using a computer. AIM trained fast touch typing. I learned modal editing with vim. I learned all the common Unix commands to transform text files and filesystems in myriad ways. I learned to script and to create my own productivity keyboard shortcuts. I ran Gentoo Linux at home. Then I started my software career.
There, I learned git inside and out. I learned that IDEs all have vim keybindings, so you can have seamless language integration alongside speed-of-thought text manipulation. I became an expert in Java.
When I’m programming, if I know what I’m building, I’m moving at maximum speed. I’m not thinking about typing or syntax or using my mouse much. I’m learning the shape of the code I’m changing. I’m figuring out the right changes to make for myself and future work. When I pause, I’m pausing to think. Sometimes I realize the entire approach won’t work, but I learned something valuable, and I restart the work in a better direction with fewer pauses.
The code was never the bottleneck. Coding never feels like the hard part. When it does feel hard, I build a better abstraction or use […]
- roomey
We've started calling it "Human on the hook" instead of human in the loop in work.
It is more accurate, in terms of, it only matters when something goes wrong.
Edit:"On the hook" is a general expression that means if something goes wrong it lands on you as the responsibile party, generally in a negative way. As in, if it goes right, you don't get kudos, if it goes wrong, you're on the hook for it
- Terr_
> I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought. [...] And it's addictive in a way that makes the isolation worse.
Right, it's more like pulling the lever on slot machine. Oooh, 677, bad luck, do a ritual and try again, and maybe this time...
Sure, regular programming also has a feedback loop, but normal errors are--as much as possible and by design--things that happen consistently for reasons, reasons that force you to engage you mind to discern them and then eliminate them (hopefully) forever. Experienced developers don't just try something random, hope it works, and if it works you just dismiss it as unknowable.
> But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part.
Unless, perhaps, you were already fatigued trying to deal with many stakeholders who can't agree what the system even is. :p
- doginasuit
I think that the fatigue that many people are feeling is coming from the loss of control that is the inevitable result of more momentum combined with more chaos.
Coding has generally been a slow and deliberate process, now we can go much faster if we let the LLM drive. As an intelligence, it is somewhere between a savant and a toddler, and watching from the backseat is both thrilling and terrifying. I think people will do it for a while and then realize that walking wasn't so bad, it's kind of nice. You are more likely to end up in a place you want to be.
- applfanboysbgon
> The honest truth
> That loss is real and it's worth naming
I think I will not heed the first sentence and bear with this. What motivates people to do this? What do they get out of prompting Claude for some vapid "thought piece" and spamming it on the internet?