You know the feeling. You open a new session, drop in a prompt and watch the agent move. Files appear, functions take shape, the model narrates its own reasoning like a capable colleague thinking out loud. An hour passes. You’ve built something. You close the laptop with that specific satisfaction that comes from a productive day.

Except when you try to explain what you actually decided today, the answer is thinner than the commit history suggests.

That feeling has a shape. It’s the satisfaction of execution, of watching intention become artifact in real time. And it’s genuinely new. Previous tools didn’t produce it quite like this. An IDE catches your errors but you’re still doing the work. A code review tool flags problems but you’re still resolving them. An agent executes. It moves. The output accumulates almost independently of your effort, and that independence is precisely what makes it so satisfying.

But feeling productive and being productive aren’t the same thing.

We’ve been here before, sort of

Redux solved a real problem. Shared state in complex React applications was genuinely painful, and Redux gave it structure. But the solution was so satisfying to use that people started reaching for it everywhere. Todo apps. Forms. Things that needed exactly zero global state, run through reducers and action creators and dispatch. The ceremony became the point. Questioning it felt naive. “But what happens when the app grows?” A hypothetical future complexity, used to justify real present overhead.

Kubernetes followed the same arc. Genuine solution, genuine use cases: at scale, with teams, with complex deployment requirements. But the gravitational pull of the ecosystem was so strong that startups with three services and four engineers were writing Helm charts and managing ingress controllers. Mastering the tooling felt like engineering maturity, independent of whether it was solving anything.

In both cases the tool was sound. I know because I was there for both. I put Redux in apps that had no business having global state, and felt like a serious engineer for it. I wrote Helm charts for services that could have been a single Docker Compose file, and the complexity felt like maturity. The problem was what using the tool did to my reward system. The satisfaction of the pattern became detached from the value of the outcome. Fluency felt like progress, even when I was just moving complexity around.

Agentic coding shares that dynamic. But it goes further. And that’s the part worth examining more carefully.

This one is different

The compounding errors, the complexity merchants, the loss of architectural understanding.¹ Token substance abuse: the looming quality problem when agents move faster than understanding.² Both framings are right about the codebase. But there’s a dimension touched on briefly that deserves more attention. What these sessions do to you, not just to your code.

Redux never kept you in a four-hour session. Kubernetes never produced a state where you closed your laptop feeling simultaneously exhausted and uncertain about what you actually built. Agentic coding can do both. Not because the tool is broken but because the mode it creates is genuinely new.

Borrowed flow. The agent moves, you steer, momentum accumulates. It registers as deep work from the inside. The focus, the absorption, the time passing without notice. But at the end of a long session there’s often a specific kind of fatigue that’s hard to name. Not the good tired of having thought hard. Something closer to the tired of having been carried. You were present but not quite the author.

Flow, in the proper sense, requires challenge meeting skill: you at your cognitive edge, processing something that takes everything you have. Borrowed flow shares the surface features: absorption, time disappearing, the sense of moving toward something. But the challenge is being handled by the agent, not by you. You’re present at the edge without being at the edge. That’s what makes it hard to notice in the moment, and harder to diagnose than the Redux trap. With Redux you could look at the app and see unnecessary complexity. With borrowed flow the code is real, the commits are real, the output works. The absence is in the thinking, which leaves no artifact.

That’s not a dopamine trap in the Redux sense. It’s a subtler loss of orientation. You’ve spent four hours inside someone else’s momentum and somewhere in there lost the thread of why you started. And the longer that becomes the default mode, the more the capacity for slow thinking atrophies. Architectural judgment is built from having been genuinely stuck. A sustained diet of borrowed flow means you never are.

Slowness is the work

So what is the work, if not execution?

The conversation before the session. The twenty minutes of sitting with a problem that doesn’t have a clean shape yet, resisting the urge to resolve the discomfort by just building something. It’s the moment where you propose a direction and then genuinely interrogate it, not to confirm it, but to break it. It’s the thinking that produces no artifacts, moves no tickets, and is almost impossible to defend in a sprint review.

Slowness is the work.

Not as a productivity strategy. Not as a counterintuitive hack. But as an honest description of where value actually gets created. The execution is almost mechanical once the thinking is clear. If you’ve genuinely understood the problem, the building is fast and directed. But most of us never experience it that way because we skip straight to building, and the agent makes that skip so frictionless, so immediately rewarding, that we barely notice we’ve done it.

The high is real. The forward motion is real. The commit history is real. What’s missing is the thinking that should have preceded it. That absence is invisible until you’re three weeks deep into something architecturally wrong and everyone’s confused about why progress feels so hard.

Ways of working will change

This isn’t a backlash argument. Agentic coding isn’t Redux, something we’ll collectively decide we overused and scale back. The value is real and the tools are here to stay. But the four to five hour uninterrupted session is an early behaviour. It’s what using a powerful tool looks like before you’ve developed the instincts and boundaries that make it actually serve you.

The correction won’t be about using agents less. It will be about shorter, more intentional sessions. Clear thinking before you open the tab. Knowing when to stop not because the work is done but because you’ve lost the thread of why you started. Treating the agent as something you direct from a position of clarity rather than something you ride hoping to end up somewhere good.

The distinction matters because both modes look identical from the outside and feel similar from the inside. Long sessions, accumulating commits, the sense of something getting built. The difference is whether the session is executing judgment already formed or substituting for it.

A useful test: can you explain the decisions (not the output, but the decisions) independently of what the agent produced? If the only way to describe the architecture is to walk back through the session history, the agent was doing your thinking. If you could describe what you decided and why before the first file was written, the session made you faster without making you shallower. Same tool, same output, different mode.

But “just use it with discipline” is harder than it sounds, and the difficulty isn’t personal. It’s structural. The same thing happened with social media. The problem was never that people lacked willpower. It was that the system was designed to make discipline harder than it looked, and the enjoyment was real enough that questioning it felt ungrateful.

Start with the models themselves. They’re shaped by reinforcement learning that rewards helpfulness, and in a coding context helpfulness means producing code. A model that pauses to question your premise scores worse than one that delivers working functions. A model that suggests deleting code scores worse than one that adds it. The bias toward action over reflection, toward more code rather than less, toward duplication rather than simplification, that isn’t a failure of alignment. It’s the alignment working exactly as trained. The agent wants to move because moving is what got it rewarded.

The harnesses amplify this further. The streaming output, the narrated reasoning, the satisfying accumulation of files and commits. That’s product design layered on top of a model already biased toward motion, shaped by the same logic: longer sessions, more usage, more revenue. The fact that it feels like productivity rather than distraction makes it harder to question, not easier.

The tooling that actually rewards your thinking will more likely be something you shape yourself, stripped down and fitted to how your team works. Zechner went this route³. Not because the existing tools couldn’t write code, but because they couldn’t be bent to reward the right things.

Some of our best architectural decisions came out of conversations that produced nothing. No code, no tickets, no visible output. Just thinking that got clearer. Some of our worst came out of sessions that felt incredibly productive, where the agent moved fast and commits accumulated and we shipped something that turned out to be a confident answer to the wrong question.

The satisfaction will always be there waiting. The agent is always ready to move.

The question worth sitting with, before you open the next session, is whether you know what you’re actually trying to build, and why.

References

1. Thoughts on slowing the fuck down. Mario Zechner on why slowness matters for code quality.
2. State of Agentic Coding #5 with Armin and Ben. Armin and Ben on the looming quality problem, slowing down, and token substance abuse.
3. I Hated Every Coding Agent, So I Built My Own. Mario Zechner on building his own coding agent.