Coding agents can generate in minutes what used to take us hours. Companies are pushing AI adoption. Social media is filled with developers claiming they're suddenly 10x more productive. If you're not using AI, you're afraid of falling behind. If you are using it, you're wondering whether you're actually becoming a better engineer.
I don't think the conversation we should have is about adopting AI anymore. Rather, it should be about us. About how these tools are changing the way we think, the way we learn, and ultimately the way we build software.
The real question isn't whether AI makes us more productive, it’s rather what we're trading away in exchange for that productivity.
The Junk Flow
Casinos have developed an expertise in manipulating people into spending more time and money on their games. As an example, modern slot machines use a Loss Disguised as Wins (LDW) mechanism to keep gamblers engaged.
How does that work? Say you bet 20 cents, the machine produces a celebration sound showing you won 15 cents, you get excited and you roll it again, even though you lost 5 cents. The gambler enters a state of flow, even when losing.
The machine isn't trying to help you win. It's trying to keep you pulling the lever. That's the Junk Flow.
Generative AI can deliver this exact addictive Junk Flow experience. LLMs are engineered to maximise our psychological reactions. They are fine-tuned to give us human-like answers, most of the time going in our direction, reinforcing our beliefs, all while encouraging a certain level of sycophancy so we keep coming back.
Coding agents deliver that same dopamine hit through their high-velocity feedback loop. You effortlessly prompt them, they generate hundreds of lines of code, you feel empowered by this new productivity superpower, while slowly getting addicted to a superficial experience that might undermine your long-term growth.
You might think you suddenly became way more productive, but some studies show that individuals are terrible judges of their own productivity.
The Trap
It's not entirely our fault though. Our brains are wired to choose the path of least resistance.
Now combine that with the constant pressure from some stakeholders and managers to deliver faster. Add the fear of AI replacing jobs. Add the collapse of junior opportunities. Add the social pressure of seeing developers everywhere claiming to be 10x engineers overnight.
It's only natural that many developers jump on the train before asking where it's actually going.
Some developers feel AI is being forced down their throat. Others have already lost motivation for the craft because they're spending their days reviewing AI-generated pull requests instead of solving problems themselves.
Who is benefiting from this situation?
Sure, companies selling AI tokens are profiting. But even some of them are warning us against blindly outsourcing our thinking to their own products.
The Slop Machine
You have probably seen countless content promoting the workflow of launching as many AI agents as possible (with little to no quality checks), chasing this holy productivity perfection.
Yes, a machine can produce unlimited code and reflection tokens. But there's only so much our human brain can read, digest and truly understand.
And we know AI isn't a silver bullet. It cannot be left unsupervised on complex tasks. Developers themselves acknowledge this.
Just because we can generate thousands of lines of code in minutes doesn't mean we should. Generating more code isn't the same as making progress. Software engineering isn't measured by how quickly code appears, but by how confidently that code can be understood, maintained and safely shipped.
As Uncle Ben said, “with great power comes great responsibility”. And we're already seeing the consequences of this kind of unchecked usage.
Open-source projects might be the group hardest hit by AI code slop. A few years ago, motivated junior developers could cut their teeth on "good first issue" tickets and learn from experienced maintainers. Today, many projects are flooded with low-quality AI-generated pull requests.
Maintainers are burning out filtering the noise. Trust in new contributors is declining. It's a double-edged sword where almost nobody wins.
The Brain Fry
So far we've mostly talked about the technical consequences of code slop. But there's also a quieter human cost.
Monitoring is more exhausting than doing. Reviewing is more exhausting than doing. Those activities require sustained attention. The moment your focus drops, something important might slip through the net.
When you write code yourself, your brain digests each step. It builds mental models. It understands why one solution is better than another.
With coding agents, you're making high-level decisions back-to-back, all day long. It's almost like compressing hours of engineering decisions into minutes.
That constant filtering comes at a cost. When your brain gets tired, you start developing decision fatigue, you stop questioning every suggestions and start accepting code because it looks “good enough” without a second thought. That’s often the moment where code slop begins.
The Comprehension Debt
Code slop is visible, so it gets most of the blame. But the bigger problem might be comprehension debt.
When a system grows faster than the team can understand it, you end up pushing code into a codebase that nobody fully understands anymore.
You then stare at code you didn't architect, trying to understand tradeoffs you never made.
Every time we let agents think for us, we slowly lose the mental models that allow us to solve difficult problems, debug complex systems and come up with genuinely creative solutions.
The code might still work. But our understanding slowly disappears.
Don't Outsource Your Brain
The problem might not be generating code faster. The problem is outsourcing the very thinking that makes us engineers in the first place.
Every shortcut has a cost. Sometimes it's code quality. Sometimes it's comprehension. Sometimes it's motivation.
And because these costs accumulate slowly, we rarely notice them until they've become part of our daily workflow. The goal shouldn't be to reject AI, nor to blindly embrace every new coding agent workflow that promises another productivity boost.
The goal is to stay intentional.
For me, that means using AI to remove repetitive work, explore ideas, challenge my assumptions and accelerate learning. It specially doesn't mean letting it make every important decision for me.
Because at the end of the day, the real competitive advantage isn't how many lines of code you can generate. It's your ability to understand systems, make good decisions and solve problems that nobody has solved before.
That's still our job. And hopefully, it always will be.
Top comments (12)
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!