You’re a Software Engineer and you’ve felt more tired since AI showed up? That’s probably the clearest symptom that your approach isn’t right yet. The paradox is brutal: we’re sold tools that are supposed to offload a massive chunk of our work, and yet many of us come out of it more drained than before.
I’ve recently watched this fatigue play out across several teams I work with. And it puzzles me. Not that fatigue is inherently illogical, but because we’re talking about tools that should, in principle, take part of the effort off our shoulders. The same way I’d expect to be less tired using a power drill rather than a manual screwdriver. If the tool meant to multiply your strength leaves you wrung out, something about the way you’re using it is off.
Where this fatigue really comes from
Digging into it with these teams, three causes come up every time. None of them is the fault of AI itself: they all stem from how we use it.
Drowning in code
AI produces code in huge volumes, and very fast. The problem is that this code isn’t code you wrote. Every generated line becomes a line to read, to understand, to verify. The cognitive load doesn’t disappear: it shifts. We move from a writing activity, where you gradually build your understanding of the problem, to a bulk-review activity, where you have to reconstruct after the fact the intent behind dozens or hundreds of lines that appeared all at once. And reviewing code you didn’t think through yourself is one of the most expensive activities there is.
Permanent context switching
Writing prompts “Vibe Coding” style, where you fire off a broad instruction and let the agent run with it, generates enormous amounts of code and ties up the agent for several minutes, sometimes several dozen minutes. Meanwhile, what do we do? We switch to another topic. Then to a third. With each switch, we pay the cost of context switching again, and above all we reproduce the previous problem: code to read and understand, but this time multiplied by the number of topics open in parallel. The fatigue is no longer additive, it becomes multiplicative.
The illusion of productivity
This is probably the most insidious trap. It’s now very easy to feel like you’re producing a ton and moving at full speed. But one question remains: are you actually more productive working this way? What’s the real lead time of the increments you produce: the time between starting a piece of work and its effective deployment to production?
Four topics started and 60% done isn’t 60% of value delivered: it’s zero value delivered and four open sources of mental load. That’s exactly what the diagram below contrasts: on the left, the illusion of productivity: lots of things started, nothing finished, and at the end of it the cognitive load, the context switching and the fatigue all rising; on the right, one-piece flow, a single topic taken from A to Z all the way to production before tackling the next.
One-piece flow, inherited from the Toyota Production System, invites us to favor finishing a single topic at 100% over partial progress spread across several fronts. As long as an increment isn’t in production, it creates no value: it only piles up work in progress and mental load.
Back to the fundamentals of Software Engineering
The good news is that the solution is nothing new. It takes us back to the fundamentals of software engineering, the very ones software craftsmanship has championed for years. AI doesn’t replace them: it makes them more accessible and more powerful.
- Baby steps and micro-iterations. Move forward in small steps, backed by automated tests that sustain a fast feedback loop. Each iteration stays small, verifiable, and keeps your understanding up to date rather than diluting it in a flood of massive code.
- Dialogue with the product. Identify small, high-value increments in close discussion with the business, rather than launching the agent at vague, sprawling work.
- End-to-end delivery. Carry a value increment from A to Z, without interruption, all the way to production. That’s where, and only where, value materializes.
- An obsession with quality. Intensive refactoring and continuous improvement, so the codebase stays healthy over time instead of degrading under the weight of generated code.
The upside, now, is that you have less and less code to write by hand, and your striking power is multiplied. A huge number of once-tedious tasks can be automated. But that power shouldn’t be used to open ten projects at once: it should be used to close each one faster and more cleanly.
Agentic Coding done right
This is the whole point of Agentic Coding as I advocate it with my clients. It’s not about blindly delegating to an agent and watching the code scroll by, but about orchestrating the tool as a direct continuation of the foundations of Software Engineering and Craftsmanship.
Concretely, this means keeping your hand on the flow: one topic at a time, short increments, tests that validate each step, and a review that stays manageable because it covers small amounts of code whose intent you understand. The agent becomes an accelerator in service of a discipline, not a generator of work in progress that piles up faster than you can absorb it.
Practiced this way, the result is exactly what we expected from the start: you go faster, you do better, meaning you produce fewer bugs, and you end your days less tired. The tool finally lives up to its promise.
Conclusion
Fatigue in the AI era isn’t inevitable, and it isn’t the price to pay for going faster either. It’s a signal. The signal that we’ve let the tool dictate the pace (drowning in code, context switching, the illusion of productivity) instead of embedding it in a proven engineering discipline.
Agentic Coding done right doesn’t reinvent the craft: it extends its best practices. Baby steps, one-piece flow, end-to-end delivery, continuous quality. The power drill is no more tiring than the screwdriver, provided you use it to drive screws, not to run in every direction at once.