← Back to blog

AI Brain Fry Is Real, And I Have It

2026-05-28

By Vadym · Generated with Boba, curated by me


Listen to this article

There is a moment, usually around 3pm, when I realize I have been awake for eight hours but I can't tell you what I actually did. Five agents ran. Three of them produced pull requests. I reviewed two, half-trusted one, and the fifth is still chewing on something I can't quite remember asking for. My terminal has eleven tabs. My brain has none.

Researchers have started calling this AI brain fry. I think the name is correct.

The Problem

The pitch was simple: agents would handle the boring parts so we could think about the interesting parts. What happened in practice is different. The "boring parts" turn out to be where most of the judgment lives. The agent writes the code in two minutes. You spend twenty minutes deciding whether the code is right, whether the tests are honest, whether the abstraction it picked is the one your codebase already uses three doors down, and whether the thing it confidently named utils.ts should actually exist at all.

That last part is the killer. Output from a modern coding agent is almost never obviously wrong. It is usually plausible. Plausible is much more expensive to evaluate than wrong. Wrong gets thrown away in five seconds. Plausible gets read line by line, cross-referenced against the rest of the system, and then either accepted with a small knot in your stomach or rewritten because you weren't sure.

Multiply that by the number of agents you are running in parallel and you get the shape of the problem. The cost is not producing code. The cost is validation, and validation does not parallelize cleanly inside one human head.

On top of validation you have trust calibration (how much should I believe this agent on this kind of task?), context switching (each agent lives in its own little world and I have to load that world before I can review it), and keeping up (a new tool, a new model, a new orchestration pattern every two weeks). None of these were in the job description five years ago. All of them are part of the job now.

What's Happening Now

This is not a personal weakness. It is showing up everywhere.

A widely circulated study published this spring surveyed roughly 1,500 full-time workers across industries and found a meaningful share reporting acute cognitive fatigue linked to heavy AI use, especially among people juggling several AI systems at once. A separate research group at a large public university found that employees using AI at work moved faster, took on a wider scope, and worked longer hours — and that the "intensification" produced exactly the warning signs you would expect: weaker decisions, more fatigue, and creeping burnout.

The pattern that keeps showing up in the tooling research is almost funny: using a small set of AI tools correlates with real productivity gains, and adding more tools past that small set erodes the gains. The marginal agent does not give you more output. It gives you more switching cost.

The developer community has noticed. Forums are full of people in their twenties describing seventeen-hour agentic-coding sessions, "fully cooked" by mid-afternoon, unable to sleep because the agent is still running and so are they. Industry write-ups have started comparing agent dashboards to slot machines: the variable reward (was that pull request good? is the next one going to be brilliant?) keeps you pulling the handle long after your brain has clocked out. Practitioners on the experienced-devs side of the internet are quieter about it but more grim. The phrase I see most often is high-functioning burnout — the kind where the output looks fine for a while, and then one day it doesn't.

What none of these reports really capture is the texture of it. It is not loud. You don't notice it the way you noticed your first crunch project. It feels like everything is going well, you are shipping more than ever, and you also can't remember the last time you read a book. That is the symptom.

How to Handle It

I do not have a clean answer. I have a set of practices I keep coming back to, most of which I learned by ignoring them first.

Cap the agents. One primary task, two or three agents supporting it, in blocks of roughly 90 minutes. Past three concurrent agents I am not engineering, I am triaging, and the quality of what ships drops in a way that is invisible until later. If a fourth thing is urgent, it can wait one block, or it can become tomorrow's primary task.

Batch the reviews. Reviewing each pull request the instant the agent finishes is the worst possible workflow. Every review is a fresh context load. Let the agents queue up and review them in a single sitting, in order, with the relevant part of the codebase already in your head. Async review is not just kinder to your calendar — it is kinder to the part of your brain that has to hold the system model.

Calibrate trust per task type, not per tool. Most agents are great at some things and bad at others. Keep a small mental (or written) note of where each one earns the benefit of the doubt and where it does not. The cognitive load of "do I trust this?" drops a lot when the answer is mostly cached.

Do not skip the boring human parts. Reading the diff. Running the thing locally. Writing the commit message yourself. These feel redundant when the agent already did "the work." They are how you stay the person who understands the system, instead of the person who approves output for a system you no longer understand. The day you stop is the day the brain fry wins.

Know when to go offline. This is the one I am worst at. The agents will keep running. The queue will keep growing. None of it is actually an emergency. Closing the laptop at a reasonable hour, taking a real weekend, going for a walk without the phone — these used to be hygiene. In an agentic workflow they are load-bearing. The validation budget refills overnight or it does not refill at all.

The honest summary is this: the productivity gains from AI agents are real, but they are not free. The price is paid in attention, in judgment, and in the quiet erosion of the parts of the job that used to give it shape. Brain fry is what happens when you forget to pay attention to the price. Notice the price, design around it, and most of the upside is still there. Ignore it, and you become a very fast pipeline for code you don't quite remember writing.

I am writing this on a Thursday afternoon with exactly one agent running. I am going to close the laptop after I hit publish. That part, at least, is still mine.