How I Fight AI Brain Fry

I've learned that rather than juggle too much, I just accept that I'm still more productive than ever before, even if I'm "idle", it's important to take time to have a break and to recharge, refresh and reflect.

So I limit myself to at most 2 or 3 things at once, and if all of those are in long running sessions, well so be it, I know I'll be deep back in it soon.

But it's tempting to start "just one more session", especially something like getting it to better profile and improve performance. That feels super productive, but is often just to stop me feeling "idle".

This only solves part of the problem, the other half is: ok so you have 3 chats going, at some point you realize you have 3 >10k line CLs to review, on top of code your colleagues are asking you to review.

Every review I’ve ever done I’ve found overfitting and brittle solutions and things tacked on instead of integrated so I refuse to give up on code reviews, but those are my real bottleneck, and having three is so much worse than one because my context and understanding is diluted and a bit muddled.

I want to time how long it takes me to land code and I suspect going serial on one thing will be faster than going parallel on multiple things. Parallel feels faster but the code review takes longer.

Why start several threads in parallel to begin with? If waiting is an issue, maybe you should break that one task into multiple steps. That would only produce more output at a lower quality. Nothing has changed about the human thinking capacity. Focus on one thing and get it done.

The system described here comes close to the new Projects (Beta) feature in Claude Code: capture work in Git, Agents (threads) work in cycles, decisions come back to you, each thread can be reviewed, and work is queued by Resolved, Idle, or Working.

I think the problem is context switching. "I can work on three different tasks at once thanks to AI" seems really empowering, but in reality, it's impossible to focus deeply on one task if your thought process is constantly interrupted every few minutes.

Every time I find myself idling in front of a screen, I feel the need to find something else to do, a distraction to fill those 54s before the agent sends a notification that needs my attention. This isn't healthy, and it's not how the human brain works.

Long, uninterrupted sessions of deep concentration are what helped humans produce their best work so far.

I’ve tried this kind of format too but it didn’t stick for me as i was missing the rich context the sessions were able to provide for me. Specifically the lack of diagrams and other nice formatting that is possible in HTML files. I also tried linear as a broker in between for a while but it just blew up and became too tedious to navigate and ran out of sync fast. Also expensive on token overhead.

Currently what I task it to do is have one or multiple agent threads tied to a project work it and have this really token light skill laid out that leverages eleventy heavily and renders it as markdown file. Than paired with thisbit.ai (I made this and still am developing it) i just comment / voice over on all the bits from the article and have the agent take it from there again.

Also neither codex nor Claude code come even close to the lovely TUI renders of Gemini (Argon 4)

It's interesting watching everyone build their solutions to this new world of problems. Mine has been to double down on my markdown notes, extending https://app.etherpk.com so that every task (plain markdown) can be viewed under it's wikilink (or several) on a kanban board. An MCP server knows how to interact with the notes graph. I copy a reference to the task, hand it to an agent, and the agent works with blocks under the task from there. It basically means I can give the agent really rich context up front - images, excalidraw drawings etc and the agent can update the task as it goes. Having everything on a kanban board makes it easier to step away from a task to work on whichever really needs my attention and come back. Putting this together with herdr has been very productive. I still have to watch the brain fry, but it is helping. Don't know if I'm selling the idea but I feel like I'm on to something after experimenting with various systems similar to what the author is suggesting. I'm working on making a product of it. The onboarding needs some streamlining but it's available to use for free for local graphs.

I’ve moved on from tmux to the apps that come with the agents at this point.

Mainly just for the overview of workstreams in flight and the ability to have a tree of tasks and subtasks (you can have a branching tree of agentic sessions) which are each their own session. These apps can remote into the tmux sessions too so it’s not even a change of workflow so much as presentation. Multimedia input/output is nice too.

Still not perfect but it’s pretty clear the dev environment of the future is going to be more and more focused on jobs management. What jobs do you have in flight? How do those jobs relate to each other? What needs your attention?

My setup is similar but it is still imperfect. Keeping track of what I am working on, and where I am in the process, as MD files in the same repo as the code has been a help.

But I still find myself coming back to a terminal window, the final summary of a long run (20-90min) on display, and asking the agent "where are we? what is next?"

And I still get the burnout feeling after dumping, reloading, dumping, reloading context for the 3 agents I have running simultaneously. That leads me to sometimes avoid the 4 or 5 open PRs, each with 20+ file changes I have to review, the stacked result of the last feature I asked the agent to start before I went out for a walk, or to eat lunch, or to sleep.

Starting loops is so easy now, so low friction. But closing things out, that last 20%, is still a slog. And I have a lot more of it now that agents can generate so much.

As an early adopter of AI coding, and someone who was working on Amazon's Kiro coding agent at the time, I wrote this a while back:

> AI does not feel anything. It has no existential dread, nor fear of the little death that comes at the end of every chat turn. You aren’t an AI, and you should never let yourself be treated like an AI. Give yourself space to be human. Rest, reflect, and resist the urge to match the pace of machines. You might just find that your productivity hits a new peak when you forget about productivity.

I liberated myself from the terminal/desktop and am now doing my stuff primarily via phone, so I can freely move around and handle stuff whatever I am. Feeling pretty fried right now because I started with 1 project, and over the session of that project 3 more got dragged in because dependency or tool issue, and they all have multiple features with multiple scenarios that I'm trying to review and unblock, ideally before auto-compact (I have a setup that kicks in after 40m of no activity) because then I have to instruct the agent to mine the previous session(s) for context and it still sometimes misses stuff and... I'm currently failing. I just let them compact now and take a break, and hope too much isn't missed when I get back at them. Definitely need to improve workflow here because it's a heck of a grind. Liberated, but not really.

Why inventing your own issue/work tracking system based on git? Wouldn't it be easier to work with, say, github issues the same way? You create it normally, agent picks up, works, updates the status on it or in the relevant wip PR, then potentially adding "needs more info" label. You'd get all the same tracking benefits and more: better UI, kanban, more tools.

I am in the fried brain soup but my solution of using git issues for stories (using forgejo) and my own release manager task-plus to coordinate it all is as far as I have got. I spend quite a bit of time trying to push down thinking into tooling which I have written which encodes the rules I want to follow. It is a work in progress getting Claude and my tooling to work together.

So instead of tabs, I do cmux’s named tab groups. From there I rank them in my sidebar by priority and makes sure I’m always staying on top of the top prio tab group. The others I’ll only navigate to when I’m free.

I can usually have 3-4 tab groups running at one time. More than that I find to be counter productive

I've been using herdr without much trouble. Very easy to use. You'll have to pry my terminal from my cold, dead hands.

This is a temporary problem. A 10x-100x speedup will allow us to simply wait for the response, instead of finding something else to do in the meantime.

I wonder what the experience is of people here with the ultrafast mode (8x) of Codex.

I’ve written about this approach to and it doesn’t work the issue is that even if the information is presented perfectly you don’t know how many iterations it might take.

Some information is better presented in artifacts, but some is better presented in text, f.e. abstract concepts.

You will run in the same issue even if the handover is optimized. I’m still trying to solve it for me, but perfectionizing the handover is just a part of it.

I’ve even had an ochestrator sessions to prioritize by a mix of easiness to approve/priority.

I think it’s better to focus on doing the right base line tasks instead of continious duct-taping. Clear resonsibilities, built workflows and all the good patterns that keep the amount of tasks and complexity down. The worst thing to happen is that all the agents overcomplicate your software.

I find it's useful to just ask Claude to help me. At least once a day, I tell Claude, "I've lost track of what's going on. Figure out what needs my attention right now and what should I focus on next." It almost always gets me back on track.

Sounds miserable

Claude Desktop should build this as an interface. It recently gained a lot of useful features that makes managing sessions and working on multiple things very easy. Only thing missing is the inbox now. A central place for summary of everything you are actively working on and what agents need from you.

I kind of enjoy the juggling between multiple tasks.

But the inherent goal is to reduce the human-interaction within a session. Telling the agent to make assumptions rather than asking and reduce any bump causing me to step in, making sure it does not happen again in another session. Soon you'll see you can juggle more balls but at a frequency which doesn't fry your brain.

Also, I don't read most of the verbose output anyway. I have configured the agent to visually highlight actionables or destructive actions.

My current issue is not brain RAM but MacBook RAM, so I'll need more metal. Anyone got experience with Tailscale with agents?

Non-hugged link:

https://web.archive.org/web/20261108193851/https://sergeykuh...

This seems to center around managing the endless context switching. But... is context switching really the root issue here? I'd say it's the general lack of understanding (or the impression of understanding) that's the issue when working with agent-heavy workflows.

Perhaps a radical suggestion but you could also just write the code and use LLMs to check for errors, different patterns that might be better (I.e parse don’t validate). They don’t necessarily have to be code generation tools if you feel that it’s not better to do so. This will probably fall of deaf ears but personally I like doing it this way.

Setting a conversation title that you can see in the bar across the top and where you send the message, now you know what is each one... without that all of them are a square-ish box with letters

https://github.com/alainnothere/privibe

I also have this problem, started on a similar solution. Mine is a visual board with cards and discussion threads. Cards have context at an abstraction level I deal with (I don't review code) and agents ask me questions below it. Tooling is very early, very rough but I am feeling more productive than juggling 2-5 sessions.

With agentic development, we're saying every software developer is now managing a team (of agents). We already kinda know how to do that. Issue trackers, stand ups, design documents. I'm using GitHub issues to manage the queue and it works ok. I don't need to know all of the context for every task, so maybe an aggregated "stand up" would be better.

I feel like sharing a blog post you let Claude write for you is a pretty good sign you have not successfully evaded AI Brain Fry.

  > "The page is only a viewer — git is the record."

  > "Then comes the part that matters most."

  > "That closing is the whole trick."

I hope the irony is not lost on anyone else, lol

The author's problem is that the are doing too many parallel agent things. It's very interesting that their solution space is "keep doing tons of parallel stuff, but with different tooling" instead of... "do less parallel stuff (and provide stronger attention)".

I got a laugh from this. Own writing isn't one of the ways.

> Then comes the part that matters most.

> I take one item. I load its context. I make a decision or request an action. And I close it, by putting it back into the queue.

> That closing is the whole trick.

Or perhaps their mind has been infiltrated and this is their writing.

Anyway I choose the lowest latency model that can interactively design a system before I set it out to build it out. It's hard to find these since so much is batched agentic looping.

I like how that resembles the unix philosophy, do five things and do nothing well

It's weird to me how many people treat an agent running as a signal to run another one in parallel, instead of just taking a break and doing something else you enjoy. If "code is compiling" was an excuse to get a break (https://xkcd.com/303/), why isn't "agent thinking"?

Its funny that there isnt a word yet to describe these moments where one waits for the agent to finish its work, something which has taken over our whole work experience nowadays

Maybe vibe-idling? Videling? Vibeling?

Good heavens, you have to write your own harness, orchestrate a few agents, and recursively self-improve your agents with the express goal of completely remove yourself from the equation. I will not stare into an abyss of my own creation. plan your time and drive your agents, not the otherway around. will it be slower? you'd be suprised how much you don't care when you let the stormtroopers finish your 2nd deathstar.

I thought you’re supposed to roll around on your chair swordfighting while your agents are agenting.

It's funny watching people slowly (re-)discover that a kanban board seems like a good idea for agentic coding.

I read this and I think, OK, that seems like a strategy. And then a bit of my brain says "dude, dude, you've seen Metropolis right?"

Thought it was “How I'm fighting the AI Brian Ferry”. Sad it wasn’t that. (Bryan, I know.)

HN hug of death strikes again.

I still do LeetCode problems occasionally. It feels weird to write code and work through complex logic manually again, but I think it's more crucial than ever these days. It's like physical exercise. If you don't use your brain and keep challenging yourself, your problem-solving skills will eventually atrophy.

This post is, sadly, AI slop. Fighting AI brain fry, inflicting it on everyone else

I go about this somewhat differently.

First, having forced breaks in your coding activity is not something new. Heck, there is even an XKCD about it: https://xkcd.com/303/

What I did under these circumstances was to think ahead, revisiting code, examining my assumptions. (Obviously, not swordfighting. :) )

This still keeps working for me, as I mostly use agents as virtual pair programmers, as I've noted before. I prefer faster models at lower reasoning ability to get quick turnaround to questions, but for the most part this feels not so much different from before. (I also think that fast inference is going to be a very attractive value proposition going forward that has not gotten enough focus.)

But those breaks are relatively short, and often I am even reviewing or otherwise digesting code when the agent comes back; i.e. the agent may be waiting for me rather than the other way around at times.

Obviously, sometimes you do have agents doing autonomous work, such as a thorough code review in the background. Again, this is not per se something new. Longer breaks, whether due to e.g. a really long fuzz test or CI run or waiting for a colleague to come back to you to answer a question you have is nothing new.

This is a perfect time to switch tasks, or go for your lunch break.

I'll note that I have yet to see a study that has amortized net productivity gains from agentic coding above 30%; nothing to sneeze at, but also not something you should drive yourself to burn out over. What we do seem to get is a lot more ability to iterate, which can go into feature refinement or improving code quality. What I think we need to be careful about is not to run up a lot of tech debt just because we can generate a lot of code faster. That is ultimately going to bite you. My preferred metric is not raw development velocity, but velocity that does not come at the cost of quality.

I'll add that things do tend to get exhausing even without continuous context switching. Agents eliminate a lot of the tedium of coding, but the tedium, while generally disliked, also was some downtime for our brains. If it becomes too much, I do switch to lower intensity tasks, of which there still tend to be quite a few.

I basically made a jira for my agents. It's super handy for context switching.

i've been using git-bug for this and it helps a lot in complex projects

  > A lot of people are suggesting taking breaks, thinking before typing

I think so much of this is because everything is hype driven, from the core. To even get funding we have to promise hopes and dreams. While that started out reasonable it has escalated into selling promises that are obtuse at face value. Things that are more fantasy than Sci-Fi, or things that while they're even possible they're wildly impracticable simply due to the laws of physics (data centers in space?). Hell, people even propose things that would violate tons of international treaties AND have little to no practical value[0].

AI isn't the cause of any of this, but it is a catalyst. We need to have serious discussions about this now before the snake eats itself[1]. I don't know why we pretend that these things aren't foreseeable. Many of them are widely discussed long before they come to fruition. But I do also believe that this lust for speed forces blinders onto many. They don't have time nor energy to think creatively[2] or they fool themselves. AI increased speed, but that doesn't mean it increased velocity. That velocity still comes down to the engineers using this tool[3].

This new tool has forced us to come face to face with one of our oldest and greatest enemies: understanding. And I do mean old, Dijkstra wrote about it long ago[4].

We still can do great things in this age, but we're forced to take a step back and look at what has actually driven progress in the past. And if anyone claims to have a clear fool proof formula, well... that's just magic.

[0] Yes, giant mirrors in space are, in fact, space weapons. If you couldn't figure that out on your own you have some serious reflecting (pun intended) about your career choice as an engineer https://www.reflectorbital.com/

[1] At least fully. Google's latest earning reports already show that. And it isn't like years ago people called out Google's plan for AI search and how it would affect ad revenue. That discussion even started long before Gemini!

[2] Something that drives innovations and consequently, profits!

[3] It is still a tool. It is not magic. It never has been and it never will. Maybe you don't call it magic. Maybe you give it a "technical explanation" and conclude that it isn't. But actions speak louder than words and it isn't hard to see that people have treated code like magic since day one, it shouldn't be surprising that it's become more prolific with AI.

[4] https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...

Reading books is critical.

I don’t have this problem and it might be because I have skills and workflows that focus on decisions. When I open each session what I am looking at is mostly a series of decisions presented to me and if one of them doesn’t have sufficient context I ask for clarification but provide answers for all the ones that do. The agent can keep track of the overall goal and then produces either a document or a fix at the end.

So to me having 50 concurrent sessions is like playing 50 games of chess simultaneously: I can’t possibly remember my previous analysis or planning but that doesn’t matter because everything I need to know in order to make a decision is in front of me.

> It is still exhausting. But I don't feel distracted or lost.

So not really solving the issue, just feeling productive for the hell of it. To me, this sounds like those X posts of some techbros LARPing with multiple screen setups where agents are running wild and generating summaries of stuff and are stacked over each other etc, all in the hope of optimizing something (no one knows what exactly).

Just have decent workflow across agents and you won't have to reinvent JIRA hell.