AI in Software Development: Why It Can Increase Cognitive Load

There is a strange thing happening in software teams right now.

On paper, AI should be making development work lighter. We have code assistants, chat-based debugging, AI-generated tests, documentation support, refactoring suggestions, and now even agent-style tools that can handle larger chunks of work. If you only look at demos, it all feels like a huge leap forward.

And to be fair, sometimes it is.

But after reading the recent Harvard Business Review piece on so-called “AI brain fry,” I think it puts words on something many developers and engineering leaders are already starting to feel: AI can speed things up, while also making the work more mentally tiring.
That sounds contradictory, but it really is not.
The issue is not that AI is useless. The issue is that in software development, AI often does not remove thinking. It just changes the type of thinking required.

The new workload nobody talks about

When people outside engineering imagine AI helping developers, they tend to picture a simple productivity story: less typing, less boilerplate, fewer repetitive tasks.
That part is real. AI can absolutely help with all of that.
But that is not the whole story of day-to-day development work.
In practice, AI often creates a second layer of work on top of the original one. Instead of only writing code, developers now also spend time:

• checking whether generated code is actually correct,
• spotting hidden assumptions,
• reviewing logic that looks convincing but is subtly wrong,
• fixing code that is syntactically fine but architecturally poor,
• rewriting prompts,
• comparing multiple generated approaches,
• and trying to decide whether using AI was faster than just doing the task properly from the start.

That is not “no work.” That is a different kind of work.
And in many cases, it is more mentally fragmented than writing the code yourself.

Why AI-assisted coding can be surprisingly draining

Writing software has always required concentration. That is nothing new.
What feels different with AI is the constant switching between creation and verification.
When you write something yourself, even if it takes longer, your thinking often follows a cleaner path. You know why a piece of code exists. You know what assumptions you made. You know where you are uncertain. The process may be demanding, but it is coherent.

With AI-generated code, the burden often shifts from creation to judgment.
Now you are reading code that appeared instantly. You did not build the logic step by step, so you have to reconstruct the logic after the fact. You have to inspect it, challenge it, mentally simulate it, and decide whether it only looks good or is actually good.
That is tiring in a very specific way.

And the more experienced the developer, the more obvious this becomes. Senior engineers are not impressed just because something compiles. They are thinking about maintainability, edge cases, performance, system boundaries, testability, security, and whether this piece of code quietly damages the architecture six months from now.
AI can generate an answer quickly. It cannot remove the need for that judgment.

The trap: more output, less clarity

One of the risks in software teams is that AI creates the feeling of momentum without always creating real clarity.
Suddenly there is more code, more suggestions, more test cases, more documentation drafts, more options. Everything moves faster. But more artifacts do not automatically mean better engineering.
Sometimes it means the opposite.

A developer who would normally think through one good approach now has to evaluate three mediocre ones. A team that previously had one clear implementation path now has five AI-assisted variants floating around in a pull request or chat thread. A technical discussion that used to begin with careful reasoning now begins with generated output that someone has to validate.
This is where mental fatigue starts creeping in.
Not because developers are doing nothing, but because they are being asked to absorb, filter, and verify more than before.

This gets worse with AI agents

The HBR piece also points to something that is especially relevant for engineering teams: the growing use of AI agents and multi-step AI workflows.

This is where the conversation becomes more serious.

It is one thing to use an assistant for autocomplete or quick code suggestions. It is another thing to supervise multiple AI-driven steps across implementation, testing, debugging, and documentation. At that point, the developer is no longer just coding. They are orchestrating.
And orchestration sounds glamorous until you actually do it.

Because then the job becomes: monitor what the tools are doing, notice when they drift, catch bad assumptions early, decide when to intervene, and keep track of what happened across a chain of automated actions. That kind of oversight creates exactly the sort of cognitive overload the article describes.
For software teams, this is probably one of the most important warnings in the whole discussion around AI.

The future problem may not be “developers refusing AI.”
It may be “developers quietly getting exhausted by supervising too much of it.”

Not every part of the development process benefits equally

This is where I think a lot of companies need to become more honest.
AI is not equally useful across the entire software delivery process.
It tends to help most when the task is narrow, repetitive, or easy to validate. Boilerplate generation. Basic test scaffolding. Routine transformations. First drafts of documentation. Maybe some low-risk refactoring suggestions.
But the closer you get to ambiguous, high-context, architecture-heavy work, the more careful you need to be.

For example:

• AI can help draft code, but not own architectural responsibility.
• AI can suggest tests, but not decide what matters most to protect.
• AI can summarize a bug, but not truly understand product trade-offs.
• AI can accelerate a pull request, but it does not remove the need for experienced review.

That means leaders should stop asking, “How do we use more AI in engineering?”
A better question is, “Where in the engineering workflow does AI genuinely reduce effort without increasing review burden?”
That is a much more useful lens.

The management mistake to avoid

A common mistake is to measure success too early and too narrowly.
A team starts shipping some tasks faster, so leadership assumes the AI rollout is working. But speed in isolated tasks is not the same as improved engineering performance.
What often gets missed are the second-order effects:

• developers spending more time reviewing generated code,
• more shallow implementation choices slipping through,
• more context switching,
• reduced sense of ownership,
• mental fatigue from supervising tools all day,
• and senior people becoming bottlenecks because they are the ones who must validate everything.

If that starts happening, the team may appear productive while quietly becoming less effective.
This is why AI adoption in software development cannot be treated as a tooling decision alone. It is a workflow design problem. It is also a leadership problem.

What smart engineering teams should do instead

I do not think the takeaway is to slow down AI adoption out of fear. That would be the wrong lesson.
The better lesson is to use AI more deliberately.
In software development, that usually means a few practical things.

First, use AI where correctness is easy to verify and the cognitive payoff is real. Do not force it into every part of the process just because the tool can technically be used there.

Second, treat developer attention as a scarce resource. If a new AI workflow creates more review overhead than real acceleration, it is not helping.

Third, be careful with agent-heavy setups. Once engineers are monitoring chains of AI behavior instead of doing focused engineering work, the mental cost rises quickly.

Fourth, do not confuse generated output with completed work. In engineering, a lot of the real effort is still in validation, integration, trade-off analysis, and responsibility.

And finally, listen carefully to how your strongest developers talk about the tools. Senior engineers often notice the hidden costs first. If they say a workflow feels noisy, fragmented, or mentally draining, that feedback matters.

My own takeaway

The most useful way to think about AI in software development is this:
AI is excellent at producing candidates. Humans are still responsible for producing decisions.
That distinction explains a lot.

Candidate code.
Candidate tests.
Candidate explanations.
Candidate refactorings.

Useful? Often yes.

Finished engineering work? Not automatically.

And when a team forgets that, it can end up in an odd place: more output, more motion, more tooling — but also more fatigue, more ambiguity, and more cognitive clutter. That is why this research matters.

Not because it says AI is bad.
Not because developers should go back to doing everything manually.
But because it reminds us that the real bottleneck in software delivery is not always typing speed.

Very often, it is attention.

Where this matters for technology leaders?

For CTOs, engineering managers, and technical leads, I think the practical implication is simple:

Do not judge AI adoption by how impressive the tool looks in isolation.
Judge it by what it does to the team’s mental workload.

If it reduces routine effort and helps developers stay focused on meaningful problems, that is valuable.

If it floods the team with plausible-but-untrusted output that must constantly be reviewed, corrected, and managed, then the organization may be buying speed at the cost of clarity.

That trade-off rarely ends well.

Final thought

AI will absolutely become part of the software development process. That is already happening.
But the teams that benefit most will not be the ones using the most AI.

They will be the ones that are disciplined enough to use it where it helps, skeptical enough to notice where it adds noise, and experienced enough to redesign workflows around how engineering work actually feels in real life.

Because in software development, faster is only better when it also makes thinking easier.

And that is a much higher bar than most AI demos admit

How Nine Brains Can Help

At Nine Brains, we help companies introduce AI into software development in a way that is practical, sustainable, and grounded in real engineering work. Through consulting and tailored training, we support teams in choosing the right use cases, improving workflows, and building the skills needed to adopt AI without creating unnecessary complexity or cognitive overload.