Coding agents can generate in minutes what used to take us hours. Companies are pushing AI adoption. Social media is filled with developers claimin...
For further actions, you may consider blocking this person and/or reporting abuse
The slot-machine pattern shows up when the user keeps regenerating instead of tightening the task. Coding agents work better when the loop has memory: state the acceptance criteria, inspect the failure, change the constraint, then retry. Otherwise each run is just another pull of the lever with a bigger diff.
Exactly Alex, but for this to happen, a dev (or a company) actually needs to put some thought into this new way of working.
I see companies letting their devs use coding agents, without actually having a policy or some sort of training on how to best use this new tool. That can lead to an actual lost of productivity instead of a gain.
Exactly. Giving everyone a coding agent without a working policy is like giving everyone production access and calling it empowerment. The useful training is not prompt tricks; it is task framing, review expectations, when to stop regenerating, and what evidence needs to exist before generated code is trusted.
Yep, you framed it right! I guess that if companies stakeholders are blinded by hype and promises of productivity, then it’s for us devs to ring the alarm bell on those issues.
Absolutely. Blind endorsement from stakeholders creates a strange pressure: teams adopt the tool to look modern, then quietly absorb the coordination cost. The policy does not need to be huge, but it does need to say what good use looks like and what evidence is required before generated work is trusted.
The slot machine pattern is the clearest warning sign. If the loop is just regenerate, skim, hope, repeat, the agent is not improving the workflow. The healthier loop has a task frame, constraints, checks, and a decision about what evidence is needed before the output can be trusted.
Absolutely! I would add as well that there’s a clear way for the dev to extract learnings from this workflow as well. Otherwise we are at risk of skill atrophy.
The bottom line is simple: don’t delegate your thinking, don’t delegate your problem solving thought process.
Yes. The review moment should not just ask whether the code works; it should ask whether the developer understands the generated path well enough to own it later. That is where agent usage becomes engineering practice instead of output acceleration.
Comprehension debt is a good name for it. I've started having the agent review its own diff before I read it, which means I'm reading a second draft rather than a first, and I keep changes small enough that I still understand the design myself. The decision fatigue observation rings true as well. By the end of a day I accept things I would have questioned in the morning, so smaller sessions have done more for me than better intentions.
It's very smart of you then to catch yourself adrift with those 'good enough' sessions and to instead keep it small and manageable.
I do that as well, I keep AI sessions for the morning, then do some different kind of work in the afternoon when my attention is much less.
But as you said, one big necessity in my opinion is to keep things small enough that it's manageable without frying your brain fast.
The Loss Disguised as Wins mechanic maps onto coding agents better than most AI-addiction framings I've read, because the "win" isn't even fake, hundreds of lines really did get generated, the mismatch is between velocity and actual comprehension. Comprehension debt is the sharper term than technical debt here, technical debt is at least visible in the code, comprehension debt is invisible until someone has to change something they never understood in the first place. The part I'd push back on gently: the piece treats monitoring and reviewing as inherently more exhausting than doing, but that's partly a tooling failure, not a law of nature. A review surface that shows you the decision the agent made and its confidence, not just the raw diff, is a meaningfully different cognitive load than parsing a wall of generated code cold. Worth asking whether the brain fry is intrinsic to AI-assisted work or mostly a symptom of every agent handing you output instead of a decision to evaluate.
Thanks for you input Mike!
When I talk about brain fry and that 'reviewing is more exhausting than doing', I am also talking about reviewing a PR from a colleague, either AI-generated or not.
When you build something yourself, you build it piece by piece, so the mental load is incremental. While when you review something, you are faced with the entirety of it immediately, which is more consuming for your brain.
But as you said, a review task can be facilitated when you are shown with the decisions/trade-offs mad, the overall confidence and maybe some more explanation. That's what a good dev would hand over to you when you need to review something. And that's maybe what the AI agent should hand over to you as well.
Food for thought!