Why AI-Assisted Development Is More Exhausting Than It Should Be | Tony Alicea

Why AI-Assisted Development Is More Exhausting Than It Should Be

The promise of AI-assisted development is that it should make developers' lives easier. In some ways it does. Yet I see many developers suffering from post-LLM burnout and exhaustion.

In part, it is because of the unrealistic expectations of the organizations they work for, caught up in AI hype and FOMO.

However, I am seeing another issue. And it's one rooted in the psychology of human-computer interaction (HCI).

Cognitive Modes

When you consider user behavior from an HCI perspective, you might think about "modes". A "mode" is a distinct state in which the same interface produces different behavior. But modes aren't just states of the interface. They're states of the user.

Imagine someone using a project management app. When they're scanning the board, they're in a reading mode, absorbing the state of things. When they're creating a task, they're in input mode, making decisions about what to write and how to categorize it. When they're reviewing a teammate's task before marking it done, they're in an evaluation mode.

Same app, perhaps the same screen, but three different cognitive states. Each uses different mental resources, and rotating between them is part of what makes the work feel varied rather than grinding.

Software development has always had these kinds of modes. And until recently, the natural rhythm of work kept developers moving between them.

Planning, Implementation, and Integration

There are at least three modes of work in software development: Planning , Implementation , and Integration .

Planning

Planning is about understanding the problem and designing an approach to solve it. What are the problems we need to solve? What are the constraints? What is the best architecture for the circumstances? How do the pieces fit together?

I would argue that this is the most cognitively demanding mode. It requires holding multiple concerns in your head at once, reasoning about tradeoffs, and making decisions that will impact every step that follows.

Implementation

Implementation is about making the solution a reality. Writing the code and solving the unexpected challenges along the way. Debugging, testing, fixing, and getting it all working.

But implementation also served a deeper cognitive function. It was a cognitive reset . After the taxing, uncertain work of planning, you could drop into the flow of building. The plan is defined, at least enough to start. And writing code, which is really the act of solving a series of small problems within a larger context, provides a rhythm of frequent, tangible success.

You write a function and it works. You connect the backend, frontend, and the database and see data appear and update. You style a component and it looks right. These are small wins, but they accumulate, creating momentum. They produce the feeling of progress that sustains motivation through the harder parts of the work.

Even debugging, which can be frustrating, is a different kind of frustration than planning uncertainty. Debugging is traceable. There's a bug, eventually you find it. The satisfaction when you do is immediate and concrete.

Implementation was the mode where the abstract became real. It was the mode that, for many devs, recharged you for the other modes.

Integration

Integration is about quality control. Code review, both your own and others'. Making pull requests and merging code. Careful inspection of the choices made. Catching regressions, enforcing standards, verifying behavior.

But integration, like implementation, provided other benefits. It was a period of cognitive feedback . When you reviewed your own code before a merge, you were meditating on your own work with fresh eyes. You'd catch things you missed, notice patterns you'd repeated, see implementation that could have been clearer. Self-reflection was built into the workflow.

When others reviewed your code, you got the benefit of a different perspective, which is a key part of learning and growth. Integration was also a space for debate, process refinement, and team alignment.

While you may have felt the pressure of getting code reviewed, the act itself seldom had back pressure. It happened, on a broad scale, at the speed of code or faster, and thus was rarely a bottleneck. You could reflect, review, consider, and rethink. The cognitive equivalent of stretching after a long morning run.

Mode Collapse

AI-assisted development has not only changed the ratio of time developers spend in each of these modes, but the very nature of each mode and the back pressure involved.

Planning

Now that AI can theoretically implement features in minutes instead of days, organizations expect more output. That means more planning. More specs, more architectural decisions, more prompts. The pace of planning used to be gated by how long it took to build. That gate is gone,...