I'm a Senior Engineer and AI Is Frying My Brain

A honest account of cognitive debt, agent orchestration burnout, and why fundamentals matter more than ever.

I need to be honest about something.

For the past few months, I've been running multiple AI agents in parallel — every single day. Agents doing research. Agents generating PBIs and PRPs. Agents drafting RFCs and architecture documents. My job has become reviewing, orchestrating, shifting context between dozens of deliverables that I didn't write but I'm fully responsible for.

And I'm burning out.

Not the "I worked too many hours" kind of burnout. A different kind. My brain is fried by the end of the day — not because I coded too much, but because I supervised too much. I feel productive. The output is real. But the stress is accumulating in a way I've never experienced before in over 10 years of software engineering.

If you're a developer using AI coding tools daily, I suspect you know exactly what I'm talking about.

The Promise vs. The Reality

The promise was clear: AI would do the heavy lifting, and developers would gain time.

A few years in, the reality is different. AI didn't reduce our work — it changed the type of work. We went from builders to supervisors. From engineers to managers of autonomous agents. And no one warned us about what that shift would do to our minds.

There's already a name for this: AI Brain Fry. The excessive use of AI is mentally exhausting programmers and software engineers. And the mechanism behind it also has a name — cognitive debt.

What Is Cognitive Debt?

If you're familiar with technical debt, think of cognitive debt as its cousin — but applied to your brain.

A recent line of research has been mapping exactly this phenomenon: what happens to engineering teams when AI takes on a significant share of code creation and design decisions, and how the cost shows up not in the codebase, but in the heads of the people maintaining it. The work focuses on something traditional metrics don't capture — the erosion of shared understanding inside teams that ship fast with AI.

That research is led by Margaret Story, and she described cognitive debt perfectly: it is the accumulation of mental effort and lack of understanding that happens when we delegate a significant part of code creation and decision-making to AI.

When you write code from scratch, you build a mental model of the system in your head. But when AI generates hundreds of lines in seconds — and most of the time we just approve it — the gap between AI's generation speed and our actual human capacity for comprehension and review is our cognitive debt.

And the interest on this debt is brutal. When a bug hits production or you need to change an architecture that was "magically generated," the effort to debug and understand that maze of code is massive. That's when the mind breaks.

Story illustrated this vividly with a classroom experiment. Student teams were developing software products over a semester, shipping features fast to meet deadlines. Around week seven or eight, one team hit a wall. They couldn't make even simple changes without breaking something unexpected.

Initially, they blamed technical debt — messy code, bad architecture. But the real problem was deeper: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together. The shared understanding had fragmented. They had accumulated cognitive debt faster than technical debt, and that's what paralyzed them.

As Elemar Junior put it: "Speed without comprehension is just borrowing from the future. We're accelerating delivery and decelerating learning."

Story also references Peter Naur's classic insight: a program is a theory — it lives in the minds of developers, capturing what the program does, how intentions were implemented, and how it can be changed over time. Usually this theory isn't in one person's mind but distributed across many developers.

This is exactly what cognitive debt erodes. When AI agents generate code at scale, the theory fragments. No one fully holds the "why" anymore. As Story puts it: "Technical debt lives in the code; cognitive debt lives in developers' minds."

And Kent Beck's principle becomes more relevant than ever: the reluctance to slow down and do the work of "making the hard change easy" is precisely what leads to cognitive debt accumulating silently — until the team hits a wall.

The Agentic Context Switching Trap

Here's what my typical day looks like now:

One moment I'm an architect reviewing system design. The next I'm QA validating a PRP. Then I'm a tech lead reviewing an RFC. Then back to reviewing code generated by an agent. Each agent delivers an artifact that demands a different mental mode to review properly.

This isn't traditional context switching. This is agentic context switching — and it's significantly more taxing because you're not just switching between tasks, you're switching between roles.

By the end of the day, I've "produced" more than I ever could manually. But the mental residue is heavy. The anxiety is real. And worst of all — I start losing control of reviewing all those deliverables properly. I suspect many developers are doing the same: approving things they haven't fully understood because the pace is relentless.

My Vibe Coding Wake-Up Call

Recently, I decided to experiment with vibe coding on a personal project. I had an advantage most people don't: I've been building a methodology called FORGE that works with concepts like PRDs (Product Requirements Documents) and User Stories to maintain structure and traceability when working with AI agents.

So I went in with guardrails. And initially, it worked. The methodology gave me control over the features being created. I could trace decisions, review incrementally, keep the cognitive load manageable.

But then I hit a wall.

There was a specific technical decision I needed to make — something I wasn't deeply familiar with. I had two options: stop and study it properly, or delegate to AI and keep the momentum going.

I chose the second option.

The result was predictable in hindsight. I lost total control. When things broke, I had to spend more hours than normal to fix them because I needed to study the tool and understand the underlying problem. I'm an experienced programmer, but the language and stack completely changed the paradigm — my solid Java/Spring Boot mental models didn't transfer cleanly to this new context.

Methodology held the boat, but it didn't replace deep understanding. When the foundational knowledge was missing in that specific context, AI amplified the problem instead of solving it.

And here's what hit me hardest: during that project, I felt more like a Product Owner than a Software Engineer. I was managing requirements and approving deliverables instead of building and understanding systems. The craft was gone. The stress was up.

The Data Backs This Up

This isn't just my experience. The research is catching up:

• Workers who reported high levels of AI supervision spent 14% more mental effort at work
• High AI supervision predicted 12% more mental fatigue
• More intensive AI supervision predicted 19% more information overload
• In the Brazilian developer salary survey, 29% of developers reported burnout, with 73% experiencing anxiety and stress

As the CDF research points out: AI isn't reducing work — it's intensifying it. We're being pushed to produce at an almost inhuman speed, and we can't keep up with understanding what's being created.

The Uncomfortable Truth

The tools are genuinely transformative. The capability is real. The productivity gains are real. I'm not going back to writing everything by hand.

But productivity was never the real bottleneck.

The real bottleneck is coherence, focus, completion, judgment — and knowing what you're building and why you're building it. That's what's getting lost in the agentic loop.

The most exhausting part of AI interaction isn't the prompting — it's the supervision. That moment when you're watching the agent generate a tree of code and you feel like you can't just sit there. So you start another task. And another. An hour later you have five things half-done and you can't remember which was the main task. You feel productive, but you're not. You're just busy.

What I'm Doing About It

I'm not going to pretend I have it all figured out. But here's what I've learned so far:

1. Fundamentals are your shield. My architecture and system design knowledge is what saved me from deeper trouble. When things broke, I had the mental models to diagnose and recover. Developers who skip fundamentals in the AI era are building on sand.

2. Methodology is your guardrail, not your replacement for understanding. That's why I'm building FORGE — a methodology specifically designed for the age of AI agents. One of its core concepts is the Blueprint: before any code is generated, FORGE produces a document that captures how the code will be implemented and why each decision was made. This directly addresses what Peter Naur called the "theory of the system" — the Blueprint ensures that the "why" is never lost, helping me maintain control, predict errors before implementation, and preserve the shared understanding that Margaret Story warns us is eroding. It helped. But it's not a silver bullet when deep knowledge is missing.

3. Know when to stop and learn. The moment I chose speed over understanding with the CrewAI project, I signed up for more pain later. The "just delegate it" instinct is the cognitive debt trap.

4. Single-thread your supervision. I'm actively resisting the urge to run 5 agents in parallel. One task, one review cycle, full comprehension before moving on. It feels slower. It's actually faster.

5. The craft matters. If you feel like you've become a P.O. instead of an engineer, that's a signal. Step back. Write some code yourself. Build the mental model. The agents aren't going anywhere — but your understanding might be.

A Message to Junior Developers

If you're early in your career and reading this: please, invest in fundamentals.

Learn architecture. Learn system design. Understand why patterns exist, not just how to prompt an AI to generate them. Because when things break — and they will — no agent will save you. Your mental model of the system is the only thing that will.

The developers in Margaret Story's classroom were moving fast with AI — shipping features, meeting milestones — until the shared understanding collapsed. Now scale that dynamic across every team adopting agentic workflows, generating 10x more code, 10x faster, with 10x less comprehension.

Cognitive debt is real. And unlike technical debt, you can't refactor your way out of a brain that never learned how the system works.

Final Thought

The question isn't whether to use AI or not. The market has moved. The tools are here to stay.

The question is: are you using AI, or is AI using you?

If you end every day with your brain fried, producing a lot but understanding less, feeling productive but anxious — it's time to slow down and recalibrate.

The code can wait. Your mind can't.

If you recognized yourself in any part of this article, I am building FORGE precisely to address this — a structured methodology and CLI for AI-assisted software development that keeps the "why" intact. FORGE captures the intent before code is written, so the agentic workflow runs against an explicit blueprint instead of accumulating cognitive debt. See how FORGE works and join the early access →

References

• Margaret Storey — Cognitive Debt. Research on cognitive debt, shared understanding, and the erosion of "the theory of the system" in AI-assisted teams.
• Harvard Business Review — When Using AI Leads to Brain Fry. The HBR piece naming the AI Brain Fry phenomenon.
• Código Fonte TV (CDF) — discussion on AI cognitive load and developer burnout, surfacing the studies behind +14% mental effort, +12% fatigue, and +19% information overload under high AI supervision.
• Peter Naur — Programming as Theory Building (1985). The foundational essay arguing that a program is a theory living in the minds of its developers.
• Kent Beck — "For each desired change, make the change easy (warning: this may be hard), then make the easy change."
• Elemar Junior — commentary on speed without comprehension as deferred cost ("accelerating delivery and decelerating learning").
• State of Brazilian Developers / dev salary survey — 29% reporting burnout, 73% reporting anxiety and stress.