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".

I feel like I’m starting to have my own psychosis where if I read a blog article and I get a whiff of AI smell my brain turns off and I can’t read anymore.

I’m not blaming the author maybe this is their original idea and its edited by AI but I physically can’t keep reading it. AI blindness or something.

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.

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.

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.

I have almost the exact same workflow. With just about everything I do, I create little websites to help me with code review, or multitasking on tickets, or reviewing a spec, or whatever I happen to be doing, any workflow gets turned into a throwaway site that works like a work queue or form. I've had trouble teaching this approach to others.

The way I cope with AI Brain Fry is owed to Starcraft. Starcraft is a deeply strategic game where you don't have time to think deeply. The game rewards the right intuition and speed over deep thinking, because attention is the most valuable resource, and it is demanded by dozens of different things at once. When engineering this way, the job is similarly bottlenecked by multitasking and attention. You have to learn to think deeply quickly. That's also why tools that let you organize your attention are so important.

In my youth I was a huge Starcraft player, not pro but close. Starcraft taught me to love intensity and multitasking. Training and continuous practice taught me how to be at near-100% for hours or days on end, and how to think faster and more intensely. I feel like that training more than anything is what makes me able to work this way. I do feel tired, mentally and physically exhausted, but so did I when I played Starcraft, and it's the same fun and rewarding feeling that I would get from playing the game all day.

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)

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.

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?

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.

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.

I use the OpenSpec[1] workflow with PRs at each step, proposal, apply, archive. I have the LLM do those steps but I review the results and have it make changes as needed.

OpenSpec specs make it easy to look back at what it was supposed to do if necessary, including a checklist of tasks.

I don't have a lot of parallel tasks running at once to reduce context switching. I prefer parallel tasks to be on different projects which I find makes it easier to track what is happening in each.

Just like manual work, break tasks down into small chunks that can be completed quickly. This also helps avoid the feeling you need to run a bunch in parallel and context switch. If you know something is going to be done in 5-15 min you can use that time to do non-product/code tasks.

1: https://github.com/Fission-AI/OpenSpec

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.

I went through a similar phase; "LLM coding psychosis" is a fair name for it. For about 2 months, I went to bed angry most nights, trying to finish a project that would have taken me longer by hand. Git fight was most of it, end of day trying to commit before bed and it messes it up so bad you just get so angry. I do feel accomplished, but I took a loss getting there.

My guess is this mostly affects people who care about code quality. If all you want is the final product, like the demos Anthropic shows of agents building an OS, and you never read the code, you seem to come out happy; I have the same feeling until I see the code.

I've stopped letting AI make large changes. Now I review small ones, and I abstract concepts in the code as hard as I can for my own sanity. I have the largest section in Claude.md for git workflows and have proper rules for branches in GitHub which I used to not care about before.

The problem the author describes is real. Expecting humans to consume and reason about pages and pages of technically dense, oddly packed prose with pointers to many external files (tickets, prs, plans, code) is not feasible. Perhaps models can hold that context, but I suspect it is incredibly inefficient. No idea why markdown became the lingua franca for the text stream interface outside of the llm tool calls--one must enable flags to get e.g. json streams. What's worse, models treat such markdown content as ground truth, almost at the level of a system prompt, especially when they receive it from, say, a call to the GitHub mcp to read some issues.

I have been developing a workflow that is strikingly similar to what the author describes. Github's new pr UI is solving the wrong problem. Pushing up buttons in the dom is not going to solve the root cause, which is context overload, incorrect global state (MEMORY.md, stale/superseded decisions). I think we just need a decent openapi thing that can be parsed, tagged, and validated in manageable chunks.

For me, just using GitHub issue and pr metadata, labels for typing, blocking/blocked-by as directional edges, then building a graph. Great for giving cheap context, at least for smaller projects. Goal is to then build a queue of issues to close, then stack the prs accordingly. Problem I've hit in dogfooding it is merge conflicts and restacking, but that can be automated to some extent. Not as easy when a design decision made during the initial approach is found to be insufficient or invalid partway through the stack, though.

The mailbox approach is exactly what I landed on as a first pass, but I'm sure one could develop much more sophisticated channels and a decent interface to work with them. I am waaay too obsessive to push one out, but looks like others are picking up on it, and my experience has been that these solutions usually become standard within months anyway. Just something I've been hacking on.

I just do one thing at a time, and if I have to wait on the AI, I go read HN. Still way faster than manually coding every line, and my brain is pretty relaxed, my boss is plenty happy with output.

I don't get why people are letting AI run them ragged. Maybe some of it is raised expectations from management? But good managers don't want to burn out their employees.

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 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.

Maybe we just need to get comfortable doing less. While an agent is working, look out the window, think about something, or do a bit of tidying. You don't have to turn every spare minute into productive work.

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 wrote a software to do it. It's not that difficult to make something like this now, it's just a Tauri2 app that has a kanban, priorities, history of everything the agent does. https://github.com/oscscull/quarterdeck

I don't think necessarily I'd recommend using or forking it (though go ahead if you like) but rather building something like it. It doesn't take that long.

The model I use is similar to yours, but revolves around the concept of "your turn". So you have a task or something, if the ai can work on it it's their turn. This creates a log of their actions and writes code. Then when it's time to e.g. review the draft code, it's your turn. That way, you can keep 5 things in progress, and just alternate turns, and you keep a history so you know what the context is. Then you apply this same model to other people, so reviewers, pr's that came to you. That's on "their turn". Your turn, ai turn, other people's turn.

For me, the most important thing is reducing the need to keep a mental map of all the work, software is cheap now so move the map (however you organise it) into a software (of your own creation). The problems you need to solve are how to retain context on the tickets so you can make judgement calls, and have the system prompt you in return, more like a human would, rather than a one way flow of requests. It's helped me with the burnout a lot.

I usually do three sessions when there are two. Once I started handling more than three tasks simultaneously, I felt that context switching consumed more energy and the risk of making wrong choices increased, which actually reduced efficiency.

Rather than running multiple contexts simultaneously, I think the key to efficiency lies in how to run one context more in parallel.

I just try to make 1 thing, at most 2, at a time. This means I get more downtime to think, or (if I give the model a big task) take a walk, play some guitar...

It's not maximizing productivity, but it's at least maintaining or slightly improving productivity while not being too exhausting.

I also run as many as 12 at once, but since coding, research, docs, and handling requests from customers and colleagues are all mixed together, it seems hard to do it in one unified way. But I think the reason I end up doing this is, in the end, inference speed. Even if I want to focus on one thing, once I run it, it goes for 5 minutes to an hour, and even 5 minutes is hard to just sit there doing nothing, so I end up like this. The number of parallel tasks ends up proportional to how much time is left after kicking off each task. Even with a parallel work tool set up like this, if the inference speed problem gets solved (not sure it's possible, since there's also the power problem that's hard to solve), I might end up not using it. Just like early this year, when I built out a whole harness, and then Anthropic and OpenAI made their built-in harnesses solid, so I stopped using mine.

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.

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’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 don't think this workflow really solves the core issue for the author, which seems to be context switching. It reduces the friction to providing the agent with an answer, but coming up with a considerate answer itself is the hard part IMO.

Regardless, the workflow outlined here sounds very similar to Plannotator Inbox! I've been trying it out for the last week or so, and it seems like it might fill the tooling gap the author talked about.

https://plannotator.ai/inbox/

Non-hugged link:

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

I've started to look back to what I learned form Jonathan Levi's Super learner and speed reading training for years ago. To work with AI is to try and fill your memory bucket with an information fire-hose. You can reduce the flow, or upgrade the bucket. There is lots of thing about human memory and information processing, that are yet to be done to make the AI output and interactions more Human friendly. Openai's new diagram based responses in chatgpt is one example of this, making thing visual. Notion is doing som research about this too i believe.

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.

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?

This resonated with me, as a non-dev using AI and someone with ADHD. While this is not my project (or any association), I'll scream it from the mountaintops that it's incredibly helpful in reducing fatigue and will allow you to build a system similar to OPs:

Pinrail.dev (thanks https://news.ycombinator.com/item?id=49995778)

That is interesting I have tried to use planka kanban boards, but was missing the all decisions go through a single channel instead of individual chat windows.

I also have a pretty much abandoned tool to take individual items and run them in non interactive sessions in individual containers which I may get back to because the brain fry is indeed real.

I think a lot, I think, about my code. While agents are doing their task, we should spehnd the time thinking about thee problem and its solution, and, are we on the right track with the project. Human's role is not to be in charge and that is not an easy task. So let's focus on it while AI is working on coding.

Multi-tasking is fine for computers, but not so much for human brains.

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.

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.

Here’s what I do:

I sit down for 45 min to 1 hour and write up in English a detailed explanation of what I want. Then I hand it over to my agent to implement. Then I go on to the next task.

Really I’m just writing. Not so much prompting.

I define prompting as an interactive and often reactive interaction mode with AI. Instead, I just write.

I do a similar thing using an open source tool (kata) that is a lightweight local issue tracker that also serves as a de facto roadmap planner and memory tool.

It's good but like most people I'll probably fall prey to the "have AI make a version tailor made to my flow" impulse sooner or later.

When we learn things, we naturally chunk a topic. We go breadth-first - getting the basic what, why, and how of several subtopics before we decide to deep-dive into any specific one. But the second we open an LLM chat, this natural way gets tossed completely out the window.

Why? Because the UI forces us into a List! (Linked List)

You ask an initial question, and the LLM spits out an answer that contains several interesting subtopics. Intuitively, your brain sees multiple branches to explore. But the chat interface treats it as a single sequence.

And it's totally fine, for some types of conversations where most of the topic's breadth is often small and you need context throughout the list. Like the following:

But not always!

Obviously, the architecture of LLM is in such a way that the entire context is just processed in parallel (thanks to Attention, Positional Encoding and K-V cache) therefore it won't cause TTFT delays, etc. But the point here is, even with growing context sizes (a million is common now), you don't want to stuff up your conversation with unnecessary details. That may only lead to hallucinations or unwanted bias (skewed). There are a some patterns why we may want initial context but a few queries down the line doesn't need to be inside the context. It's because they may pollute the conversation. And those ideas/queries are usually divergent in nature to the original context.

If you look closely, you can understand these are just Acyclic Graphs (or Tree in this case)

Every node you create newly would just need to traverse to the root node and that becomes the context and not any other branch (most of the times).

You can apply few tree algorithms like common ancestor path finding, merging subtrees, etc. And some of those actually makes sense to implement to reduce the context size of growing subtrees.

It's quite absurd why almost all vendors provide sequential UI (except for edits which would create a complete separate branch). I think this will become normal UI/UX design in the future. Of course, there would be other reasons like induced complexity of handling branches, dealing with design like spatial canvas, etc but it feels like it's worth it.

I have checked a few apps who provide these like TypingMinds, ChatTree, etc. Since these applications are obscure or poorly SEO indexed, we might struggle to find them. Comment out if there are any better tools (or we can vibecode this for personal use)

Cheers,

Aditya.

This seems unusually complicated. Why not reduce the amount of things that you are working on?

Is it really that unacceptable to be idle between queries? You can always review the code and stay focused on the things that you are building.

The more you think, the less your brain will feel fried. The more you write yourself, the more you will think.

Stop publishing stuff you didn't write, and you'll go a long way towards solving your problem, while also winning back readers who feel disrespected by AI slop writing.

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.

Everyone is talking about their setup and how to manage 3+ workstreams and context switching, and so on. And here i am finishing one thing at a time, mostly writing code by hand, completing tasks faster than everyone on my team.

it really feels like everyone around me in this profession has lost their mind.

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

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

> 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.

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 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.

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

Why people all of sudden try to behave like an octopus? Never understood this. Even if you use just one window, you are already much more productive than ever. This heavy multitasking will burn you out in no time.

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.

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.

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

Remember when we got interactive collaborative text editing?

The future will be this, but it will be interactive collaborative agent sessions, and stuff like pi durable is already heading that direction.

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?"

Sounds miserable

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

The article itself being subtly written by AI is a deep irony I was not ready for.

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. :) ) Also, note that compilation delays do not go away just because an agent kicks off builds.

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.

Not trying to be rude, but I think if you had read about DeepSeek's superagents blog, you would not have to build this.

IMO This is a solved problem. You just have to find the solution and use it.

Super agent prototype. You can tell your Clanker to install this and set it up for you on the laptop: https://github.com/deepseek-ai/dsh-superagent-prototype

I have successfully used this on my own workstation, which then I manage via Discord, as well as my work in a startup. At work I have this installed on a Hetzner VPS, which then connects to Slack and GitHub. Works like a charm, with deepseek pricing.

Reading books is critical.

  > 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...

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

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"?

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

Anyone use hive

https://hive.hivecommons.dev/

I appreciate, recognise and share the sentiment here, but I also recognise massive loadbearing claudisms??

I'd be very supportive of HN having a policy of no AI sloppy written articles.

This is clickbait slop.

[flagged]

[flagged]

[flagged]

[dead]

[flagged]

[flagged]

[dead]

[flagged]

[dead]