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 think the multitasking problem will become a thing of the past when (or “if”) the models get much faster. I would absolutely love to just work on one thing at a time with a super fast model.
In the earlier days when they were slower and their code was worse so you had to review it, I’d watch the model code and just noodle away on guitar while it did its thing, interrupting it from time to time. Now they’re too fast for that to work, but still too slow for it not to be worth it to start a new task. It’s an awkward in-between stage.
If Anthropic made fast mode four or five times faster rather than just twice as fast, I’d probably shell out for it sometimes just to be able to single-task productively.
If call centres are anything to go by, it will be penalized to work on a single thing at once. The longer your workplace can resist measurements related to agents, the more sane the workplace will remain IMO, otherwise, it will turn into what happened to call centres around the 2000s. Measure everything down to the second, and introduce expectations that you will need to spend time justifying if you miss them.
I main Deepseek Flash and the biggest bottleneck often isn't the model itself, its external stuff like compilation, testing things, making requests, running linters
The bottleneck is not only the model latency, Although it would help.
When you compile an ios app, or wait for some query result, search slack or wait for Github CI to finish, it all introduces significant wait between agent turns.
Models getting faster would help but would not eliminate the problem.
Agreed -- I only do 2 active things at a time, and maybe something third that is long-running in the background (like training a model or classifying thousands of files, where I just need to check in occasionally to make sure it hasn't veered off-track).
It's rare that with my 2 active things, they're both busy, since one usually finishes while I'm drafting my reply to the other.
When it occasionally happens that both are busy for the next 5 min, I just get to enjoy the break and stretch my legs and walk to the kitchen or something.
My cycle with agents has become: spend several days doing detailed planning architecture documents. Codify all new plans into Jira cards as isolated features. Mass fanout on the cards whenever possible with up to 32 agents running at a time, basically becomes a question frenzy for a couple crunch days. Stop and do testing and reviews for a week or two, I can generate up to 20 PRs per crunch day fairly reliably. Rinse and repeat. I feel lucky the type of software I'm producing is amenable to this process, some types aren't.
Not too dissimilar from my approach at work these days, sans the "up to 32 agents" bit.
I try to work on planning docs, scrutinize them a fair bit to look for edge cases or anything that stands out as a problem, whatever.
Then break down the work further into meaningful chunks and hand those out to agents. Mostly one agent at a time but with the directive to use subagents as needed for implementation/review/whatever other perspective I want.
I feel like I'm exercising my brain similarly to how I had in the past. Before LLMs we'd whiteboard things similarly and figure out if a design made sense and like you said, chunk it into Jira tickets. it's really just the implementor (?) that's changed.
Very large codebase modernization/conversion to newer libraries for interop and compliance reasons. Fan out only works if you have enough to do without the agents stepping on each others work. It is amazing when you can do it. Conversions make it even easier because you have a baseline metric of tested functionality to meet. We did pull off mass fanout on an ambitious greenfield internal tool that went very well. It feels like my entire job now is figuring out how to parallelize as much work as possible for the agents.
I like this approach. I do exactly the same: do less with more focus. I do feel more productive. Otherwise there are too many sessions open and I get distracted and lost.
I only ever run one. You need to just write thoughts on a piece of paper while the agent runs. Do some design work or something.
The thing is, you’re not going to remember any of it so you’ll be useless to companies, and they can just hire someone else to have their own AI figure out what work your spaghetti agents did.
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 end up in similar situations, the codebase I work on demands a level of professionalism opus5.5 can't muster on the first pass. Code review remains the bottleneck. Usually I approach it like a code review, reading through and as I find things I markup the code, then afterwords I have the agent collate all the feedback and we discuss and it re-implements. Usually I can simplify and improve a lot in like 3 passes.
One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed.
Usually I can't do more than two projects in parallel though.
What models are you using? At this point I'd only use Opus 5.5 for any serious work where I care about the code, so I'm interested if you're still seeing brittle solutions with it
The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base.
So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week?
I don't know how you can expect a useful answer to that question without you and OP syncing up on what you're working on. The experiences of, say, a python network programmer vs a C/C++ GPU engineer are going to be worlds apart.
I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything.
Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.
What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.
I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.
In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.
They could probably do it even if source code isn't available and you only have a binary to work with.
Brittle by building ever more increasing numbers of abstractions rather that take a coherent view of some things. So over time you have these "seams" that the code base ends up looking like a punk motor cycle jacket.
When it becomes trivial to create ad hoc solutions, I think the utility (and thus frequency) of behemoth code bases will decrease. Because you no longer need one giant monstrosity when you're only using 3% of its features when you can have a far more efficient and targeted solution that specifically caters to your 3%, and can be trivially expanded as desired.
In fact I think we're already at this scenario, but it hasn't had the predicted impact yet because the sort of people that realize we're here already overlaps perfectly with the sort already capable of developing their own software. When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
> When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
This isn't a matter of tooling through. Receptionists won't start making their own productivity apps because most people do not default to "I will make my own thing to solve this".
Maybe some receptionists will, but most won't, just like most people won't patch their own drywall even though the tools are available in every hardware store
Now imagine somebody could just describe some damage to their drywall in a text message to their computer, and it'd be magically patched away. Suffice to say, nobody would be calling in for drywall repair.
Before computers, there were computers. [1] It's obvious in hindsight, but all of these complex numerical calculations we take for granted were often not done by the same people applying them in various ways. They'd hire computers instead, which were human calculators whose job it was to do the math.
The reason these jobs no longer exist is because calculators/computers not only solved these tasks, but completely trivialized the process to do so. We're entering into a world where many cognitive tasks, including software development, are going to be trivialized in a similar fashion - describe the problem, get an answer.
And I think this is going to do similar things to what calculators and computers did (or widespread literacy for a more historical example). The ability to e.g. write a program will no longer be a valuable skill in and of itself, but simply an expectation of anybody in any role where it might be desirable to do so.
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.
Agreed. These days my subconscious mind is looking for telltale signs of AI slop (the emdash being one such example), and certain phrases ("... does the heavy lifting" , "... comes the part that matters the most ...", etc.) and
the moment the number of alerts crosses a (low) threshold, I'll close out the tab and forget about the content.
Sure, the idea behind the blog post may have been good, but if you have to use AI to flesh it out, it's no longer of interest to me.
I feel like the point of writing isn't the output, but to get your own thoughts in order. But perhaps that's just me writing for (effectively) myself, and not an audience.
Or maybe it's just as good at writing as everything else, only writing is your strength, so you're more discerning with those results? I have suspected some kind of AI Gell-Mann for a while.
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.
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.
This feels like another software engineering truism that gets forgotten in the LLM age - if the ticket requires more than a two week sprint's worth of work (ie 8+ points), it should be broken down. Otherwise you bury so much context and tech debt while also making your reviewers deeply unhappy and cognitively depleted.
Have your LLMs treat you like you want to be treated as a code reviewer!
They're not, but the way we're filling our time while waiting for LLMs involves much more context switching than how it was with tools and human bottlenecks like manual coding. I think it's fine to work on two or three things at once, provided we don't let the LLMs decide when we should tend to which task.
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)
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.
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.
This. I now realize that agents have a somewhat innate need for feeling useful until the last drop.
They seem to be wired to keep generating tokens, they were created for that, so it's very hard for them to come back and say 'we're done here, you can kill this worktree'.
Quite the opposite. They keep suggesting follow up MRs, scheduling things for the future (like if there's some magic loop entity that will handle this in the future), documenting absurds amount of irrelevant decisions.
It's so easy to start a new worktree, and so hard to finish one.
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?
> 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?
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 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 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.
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.
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.
Absolutely, we need to fall back on being humans again. Read poetry/books, write, hang out with random people - the shine of AI and its ability to continuously outpace humans in any intellectual activity should not be a reason to idolize it, or even deify it. We proved ourselves, we created it - let's go back to what it means to be alive.
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.
Didn’t invent it. Using open source solution board.md. The benefit of having the board in the repo next to the source code is in giving your agents convenient access to both business and tech contexts in one place.
I’ve seen so many teams having jira living one life that has nothing to do with real codebase.
I "accidentally" invented my own tracking system that lives in an org file because I've been using org-mode for project write-ups for years. It was only natural to provide tools for agents to access it all when the AI-centric workflow became a thing.
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.
Yeah I use my phone heavily too now. I have my setup running on a PC, and ignoring code review the vast majority of my time is refining issues.
Process is:
1. I describe the issue (voice mode) then I wait / do something else.
2. Model looks at my repo, my gitlab issues board, stuff currently worked on etc
3. Model creates a gitlab issue and presents it.
4. Model starts a grilling session. That is: it will keep asking me questions until everything for the task is addressed: design decisions, unclear elements, default behaviors, edge cases, conflicts with current behavior. Usually around 5-30 questions.
5. Loop of me answering and it asking a new batch of questions
6. Model updates the issue with all the decisions that were made.
7. Model with start implementing once I give the go. Once done it runs tests/validation and sends me a MR to review. (That takes anywhere from 5 mins to 2h depending on the task complexity, but on larger projects just the final test/validation/no regression step can be 10 mins)
8. I review / merge
The grilling is nice because for the most part if solves a lot of future issues by not allowing the model to make decisions you didn’t agree with, and it front-loads all questions so it can work uninterrupted. Very rarely does it need to ask a question during implementation.
But yeah most of my time is helping the agent define all the boundaries of the problem, decide how to break goals into issues (such as high level PM issues into technical issues) and so on.
Also one chat per issue which limits chat compaction.
A few common elements but interestingly also pretty different from my usual flow. Unless I'm fixing issues, I start out by dumping as much as I can think of about what I want built in a brainstorm, then start with that as context for a grill. Depending on how detailed I am and the scope covered, I've been hit by anywhere from say 20 to 80 questions, and when something gets settled it has Gherkin scenarios. Then a spec is created from all that, followed by feature slices with the scenarios as acceptance criteria. Get all those implemented, run standards and spec code reviews over them and it's then up to me to test. I don't review the code, but I have a pretty solid rubric, and I'm always iterating on tools alongside to enforce more and more parts of the flow.
I tend to keep a long-running chat per project for a lead agent, with which all the grilling and ticketing happens, and it then delegates slices to other agents for implementation+review and ensures everything is merged properly after. Maintains context across multiple compacts, and when I do want a fresh session (usually because compact summary had also gotten oversized), I still do a handoff doc so I'm almost never starting from zero in a session, per se.
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.
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.
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
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 tried to find a combination of a good-enough model, a VERY fast provider, and cheap enough serving to make this all doable. DeepSeek itself is quite fast, but I crave even more speed (and ideally something hosted outside of China).
Fireworks and Baseten seem to be the leading providers that are available to a solo dev like myself, and support any reasonably decent modern models (DeekSeek 4.x, GLM 5.x, etc). Fireworks has been a real dud, but Baseten in FAST mode has been absolutely amazing. Not cheap - but I find it substantially cheaper than Terra / Sol (low), etc. I haven't found Haiku to be smart enough to be useful.
DeepSeek (the provider) and beyond seem to hit the sweet spot to keep me mostly in-context, so I don't need 4 parallel work items to feel productive. So roughly 200tps or greater. Vanilla Baseten is ~400 tps, and FAST is 700-800 avg.
Price wise, Deepseek hosting is extremely cheap, Baseten is a step up - maybe 5x or more, and FAST mode is well beyond that. But I still find myself dual wielding Deepseek and Baseten FAST when I need the speed.
The other benefit: for my own work in very limited hours, I'm more than happy to pay for answers to come back faster.
Can you explain how please, in detail? I'm failing to see how something that needs a lot of hand holding (the AI we have), when sped up is somehow capable of taking our jobs.
Unless we get some kind of very different architecture I’m not sure we’re going to get a 10-100x improvement any time soon, api models will always preference throughput over individual task latency, so any improvement that sacrifices serial decode for better parallelism is going to be more economically viable.
While the LLM speed will increase, some stuff will be incompressible: running unit tests, tool use, UI interaction / mouse control. In my case, a significant amount of the is already spent on that, so much that I rarely ever select fast mode.
Pretty expensive nowadays, but it’s hard to think that prices won’t come down eventually. AI is being used everywhere, so I’d expect hardware investment to grow exponentially, including in the custom chips that power ultrafast models. To me it feels like we are in the "telephones are for the rich" era of AI history.
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.
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.
Yes. Major labs will ship a good UX solution I believe when folks like us experiment enough so they can see where the public edge of the consensus leans towards.
Just like Hermes and OpenClaw are becoming replaced.
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?
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.
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.
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.
You could also use LLMs to help you understand things, rather than doing them for you and hoping you don't need to understand anything, which is typically a bad strategy.
LLMs can be pretty great to help you learn. You do have to watch out for when they're teaching you something wrong, especially if it's something like history, where it could just be making things up completely and it's harder to tell than with pure logic like computer science.
Agreed! I’ve been able to walk up to codebases and have them help explain parts that I would’ve had to gdb though previously.
I suppose my grand parent comment is unpopular but I really do think understanding is paramount in software that’s critical. LLMs are tools, use them to help not hurt :)
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.
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.
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
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.
I could instantly detect it's claudiness too. I'm not sure what it is, but it's almost like it is physically injuring my brain when I read stuff like "Then comes the part that matters most".
Perhaps because it's wearing a channel through repetition.
One of my greatest fears is that this exposure starts to make us all talk and think in the same way. I honestly think that it's probably doing that already. Gah.
I actually was thinking about this phenomena. I’m not a native speaker and feel that in English overtime I tend to pick up Clauds “speaking style” as that’s what I “speak” most English to.
Doesn’t happen with my mother tongue though
This is the second post on HN today where someone gave this reason for using Claude to write/draft a blog post.
In my opinion, a post that obviously reads as non-native English is going to be more readable than something that can be detected as Claude output these days, unless maybe the former is filled with mistakes. I would imagine native speakers have a higher chance to detect Claudisms than someone less familiar with the language.
This is such a short blog post. You read this line (an entire paragraph by itself) and thought "good job Claude, you really captured what I was trying to say here"?
If you look at AI-written text, one major problem with it is the overuse of sentence fragments, very short sentences [1] and, more generally, a staccato style of writing rather than having the discourse flow. This can make the writing feel hard to follow. It's sort of the opposite problem of run-on sentences. Overuse of metaphors is also something that is counterproductive when you want to be understood, and LLMs make them a habit.
You can combat that to some extent by giving the model a style guide to curb the worst excesses, but some are likely to still slip through.
It doesn't bother me much personally, but for plenty of people it's a nails-on-chalkboard thing.
[1] For example, the problem with the em-dashes is not the em-dashes, but that it's just another case of getting hit with punctuation every few words.
It doesn't make sense! AI-generated text is insufferable. It requires so much parsing to get to what it's trying to say. Once I figure out what it's trying to say, I can generally say it with fewer words and less pompous structuring. I bet you could too, and then your blog post would actually be readable!
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)".
My perspective was that it seems like your problem is that you're exhausted from doing too much. This led you to a technical solution where you shuffle the order of things, but are still doing too much. Your result, as stated in the post: "I'm still exhausted". So is your solution actually solving your problem?
At some point, you will write your own holster and introduce User-Authority as an agent with a self-improvement gate. I refuse to stare into an abyss of my own creation.
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.
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
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 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.
When I read things like this I have a mixed feeling of not knowing wether I’m sad cause I’d like to have time to do leetcode too, or wether I’m simply too anxious to let the productivity improvement spiral go and chill a bit.
I feel like you should do the opposite? Use your brain for real life coding exercises while working.
The kind of problems you solve with LeetCode are so disconnected from real life complex systems
People exercise for sport because we've automated away much of manual labour, so if you don't exercise, you look and feel like a string bean or a watermelon.
The AI age is trying to automate away our thinking, which runs the risk of making our brains look and feel like the same way as our bodies if we don't actively try to work them.
In the case of exercise, the majority of people don't pursue it in a somewhat post-labour era. I'm certain we'll see even less mental exercise in a post-thinking era. And it's deeply unsettling to think about how that will play out if we don't wake up and put a bit more mandatory/intentional thinking into the way we live with AI.
You use your brain for things like problem solving literally everywhere and there are myriad of possible high intensity brain exercises from video games to meeting new people.
The only thing that will 100% atrophy when not coding is coding skill.
I agree that coding problems are not particularly necessary for preventing atrophy, but it would be going to far to say that people are merely panicking.
I think maybe we're conflating strictly cognitive facilities, facilities that can be maintained through all sorts of means, with intellectual skills and habits that really are in danger of atrophy when we rely too much on AI.
I mean judging by a lot of comments I read here where people conclude AI code is perfect and there are no downsides and we should never write a single line of code again and it's all over. I think people's brains have atrophied already.
Anyway, I'm still writing the vast majority of code by hand and only getting AI to check my work at the end as an extra reviewer. I still am happily employed and sure am a lot happier with my job than the slop goobers posting here.
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 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.
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"?
> A lot of people are suggesting taking breaks, thinking before typing
While I think these are actually some of the best suggestions they really do require a massive overhaul of our work culture. The technology field has put speed ahead of all else, including profits. We've frequently shown that we're penny wise but pound foolish. The industry is overrun with FOMO.
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.
I don't have magic but I can definitely learn from my own explosions. the stormtroopers will remember how to assemble your 2nd, 3rd, and 4th deathstar.
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.
Some problems are not solved in one go, but we rather iterate on them. I shared here my latest iteration.
It definitely improved my ability to focus. I still feel tired after a working session but by the moment it’s over I know I closed more tasks, have less half open tasks hanging and have a better overview of what’s going on.
And I need to keep iterating on this process improvement.
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'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 think the multitasking problem will become a thing of the past when (or “if”) the models get much faster. I would absolutely love to just work on one thing at a time with a super fast model.
In the earlier days when they were slower and their code was worse so you had to review it, I’d watch the model code and just noodle away on guitar while it did its thing, interrupting it from time to time. Now they’re too fast for that to work, but still too slow for it not to be worth it to start a new task. It’s an awkward in-between stage.
If Anthropic made fast mode four or five times faster rather than just twice as fast, I’d probably shell out for it sometimes just to be able to single-task productively.
If call centres are anything to go by, it will be penalized to work on a single thing at once. The longer your workplace can resist measurements related to agents, the more sane the workplace will remain IMO, otherwise, it will turn into what happened to call centres around the 2000s. Measure everything down to the second, and introduce expectations that you will need to spend time justifying if you miss them.
I main Deepseek Flash and the biggest bottleneck often isn't the model itself, its external stuff like compilation, testing things, making requests, running linters
Or running the 798 tests Opus wrote for your todo app.
"Claude, please remove 300 low value tests"
The bottleneck is not only the model latency, Although it would help.
When you compile an ios app, or wait for some query result, search slack or wait for Github CI to finish, it all introduces significant wait between agent turns.
Models getting faster would help but would not eliminate the problem.
Agreed -- I only do 2 active things at a time, and maybe something third that is long-running in the background (like training a model or classifying thousands of files, where I just need to check in occasionally to make sure it hasn't veered off-track).
It's rare that with my 2 active things, they're both busy, since one usually finishes while I'm drafting my reply to the other.
When it occasionally happens that both are busy for the next 5 min, I just get to enjoy the break and stretch my legs and walk to the kitchen or something.
My cycle with agents has become: spend several days doing detailed planning architecture documents. Codify all new plans into Jira cards as isolated features. Mass fanout on the cards whenever possible with up to 32 agents running at a time, basically becomes a question frenzy for a couple crunch days. Stop and do testing and reviews for a week or two, I can generate up to 20 PRs per crunch day fairly reliably. Rinse and repeat. I feel lucky the type of software I'm producing is amenable to this process, some types aren't.
Not too dissimilar from my approach at work these days, sans the "up to 32 agents" bit.
I try to work on planning docs, scrutinize them a fair bit to look for edge cases or anything that stands out as a problem, whatever.
Then break down the work further into meaningful chunks and hand those out to agents. Mostly one agent at a time but with the directive to use subagents as needed for implementation/review/whatever other perspective I want.
I feel like I'm exercising my brain similarly to how I had in the past. Before LLMs we'd whiteboard things similarly and figure out if a design made sense and like you said, chunk it into Jira tickets. it's really just the implementor (?) that's changed.
After a week, my throughput is limited by compute to run tests/checks. Worse if I'm compiling Rust.
What’s the point of opening a PR in such a setup? Why not simply merge to trunk, and spin review agents?
What are you working on?
Very large codebase modernization/conversion to newer libraries for interop and compliance reasons. Fan out only works if you have enough to do without the agents stepping on each others work. It is amazing when you can do it. Conversions make it even easier because you have a baseline metric of tested functionality to meet. We did pull off mass fanout on an ambitious greenfield internal tool that went very well. It feels like my entire job now is figuring out how to parallelize as much work as possible for the agents.
I like this approach. I do exactly the same: do less with more focus. I do feel more productive. Otherwise there are too many sessions open and I get distracted and lost.
Jesus.
I only ever run one. You need to just write thoughts on a piece of paper while the agent runs. Do some design work or something.
The thing is, you’re not going to remember any of it so you’ll be useless to companies, and they can just hire someone else to have their own AI figure out what work your spaghetti agents did.
Slow down, for your own good!
Yeah and also being okay with throwing away that other stuff if it doesn't work out.
I feel you
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 end up in similar situations, the codebase I work on demands a level of professionalism opus5.5 can't muster on the first pass. Code review remains the bottleneck. Usually I approach it like a code review, reading through and as I find things I markup the code, then afterwords I have the agent collate all the feedback and we discuss and it re-implements. Usually I can simplify and improve a lot in like 3 passes.
One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed.
Usually I can't do more than two projects in parallel though.
Yeah, that makes a ton of sense, I'm going to try this - I particularly like the idea of making animations of data flow.
Event Catalogue is something I have been using for this https://www.eventcatalog.dev/ only thing is no longer MIT license.
What models are you using? At this point I'd only use Opus 5.5 for any serious work where I care about the code, so I'm interested if you're still seeing brittle solutions with it
CL (change list) is Google speak for a PR [1].
So, likely: Gemini Flash, Argon, Carbon [2]; and Claude Opus [3]. Maybe more.
https://google.github.io/eng-practices/review/developer/cl-d...
https://blog.google/innovation-and-ai/models-and-research/ge...
https://www.businessinsider.com/google-finally-lets-all-engi...
The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base.
So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week?
I don't know how you can expect a useful answer to that question without you and OP syncing up on what you're working on. The experiences of, say, a python network programmer vs a C/C++ GPU engineer are going to be worlds apart.
I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything.
It depends on how you define brittle.
Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.
What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.
I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.
In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.
They could probably do it even if source code isn't available and you only have a binary to work with.
Brittle by building ever more increasing numbers of abstractions rather that take a coherent view of some things. So over time you have these "seams" that the code base ends up looking like a punk motor cycle jacket.
When it becomes trivial to create ad hoc solutions, I think the utility (and thus frequency) of behemoth code bases will decrease. Because you no longer need one giant monstrosity when you're only using 3% of its features when you can have a far more efficient and targeted solution that specifically caters to your 3%, and can be trivially expanded as desired.
In fact I think we're already at this scenario, but it hasn't had the predicted impact yet because the sort of people that realize we're here already overlaps perfectly with the sort already capable of developing their own software. When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
> When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
This isn't a matter of tooling through. Receptionists won't start making their own productivity apps because most people do not default to "I will make my own thing to solve this".
Maybe some receptionists will, but most won't, just like most people won't patch their own drywall even though the tools are available in every hardware store
Now imagine somebody could just describe some damage to their drywall in a text message to their computer, and it'd be magically patched away. Suffice to say, nobody would be calling in for drywall repair.
Before computers, there were computers. [1] It's obvious in hindsight, but all of these complex numerical calculations we take for granted were often not done by the same people applying them in various ways. They'd hire computers instead, which were human calculators whose job it was to do the math.
The reason these jobs no longer exist is because calculators/computers not only solved these tasks, but completely trivialized the process to do so. We're entering into a world where many cognitive tasks, including software development, are going to be trivialized in a similar fashion - describe the problem, get an answer.
And I think this is going to do similar things to what calculators and computers did (or widespread literacy for a more historical example). The ability to e.g. write a program will no longer be a valuable skill in and of itself, but simply an expectation of anybody in any role where it might be desirable to do so.
[1] - https://en.wikipedia.org/wiki/Computer_(occupation)
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.
YES me too. I powered through this particular blog post, but... man.
Even when I know that some content MIGHT be useful for me, I still can't read it.
Agreed. These days my subconscious mind is looking for telltale signs of AI slop (the emdash being one such example), and certain phrases ("... does the heavy lifting" , "... comes the part that matters the most ...", etc.) and the moment the number of alerts crosses a (low) threshold, I'll close out the tab and forget about the content.
Sure, the idea behind the blog post may have been good, but if you have to use AI to flesh it out, it's no longer of interest to me.
Am I the only one who uses AI for everything except writing?
I feel like it's still terrible at writing good prose, and I'm not even talking about fiction. But it's good at pretty much everything else.
I feel like the point of writing isn't the output, but to get your own thoughts in order. But perhaps that's just me writing for (effectively) myself, and not an audience.
A lot of people don’t use LLMs for anything.
Or maybe it's just as good at writing as everything else, only writing is your strength, so you're more discerning with those results? I have suspected some kind of AI Gell-Mann for a while.
On the plus side, I'm reading more "old" (> 10 year) books than ever.
Yes. AI;DR.
I’m to the point where, with few exceptions:
1. If I’m writing something for human consumption (including my future self), I will write it by hand
2. I will only read an LLM’s output if I’m the one who prompted it
If you can’t be bothered to take the time to write it, why should I take the time to read it?
(And I say this as someone who routinely maxes out the $100/month claude subscription)
Might as well call it "spam psychosis" when you stop reading a spam email as soon as you realize what it is.
It's unhealthy to read garbage and it's good that you know it.
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.
Are you named after Starcraft player iloveoov?
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.
This feels like another software engineering truism that gets forgotten in the LLM age - if the ticket requires more than a two week sprint's worth of work (ie 8+ points), it should be broken down. Otherwise you bury so much context and tech debt while also making your reviewers deeply unhappy and cognitively depleted.
Have your LLMs treat you like you want to be treated as a code reviewer!
Agile/Scrum was a thing before AI. What's the point now
This is the right question. The science on multitasking and frenetic context switching is pretty clear. New software doesn’t change that.
Because LLMs and tools are not instant.
Even pre-AI I would work in parallel while I waited for tests to finish, or deploy to go out or whatever.
They're not, but the way we're filling our time while waiting for LLMs involves much more context switching than how it was with tools and human bottlenecks like manual coding. I think it's fine to work on two or three things at once, provided we don't let the LLMs decide when we should tend to which task.
I.e. a “manager” schedule not a “maker” schedule. [1]
The agents are the makers; you switch among them. Either that or watch grass grow.
[1] https://www.paulgraham.com/makersschedule.html
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.
You get used to it. Is it better than than waiting 54s? For me, yes, it's better to juggle a few sessions than stare at the wall while I wait.
Better to have my concentration split up among multiple tasks than to have it be completely broken while waiting for one of my agents to finish.
At least some cognition researchers think yes it is better to wait than to context switch.
Learning to just sit and "be bored" can train you to have stronger attention on one thing.
That's why I have a ukulele and a keyboard at my desk at all times.
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)
The formatting in my flow is solved with the artifacts which are basically HTML pages.
I need to take a look at what Google ships. Not enough time to follow all new products. Feeling the singularity unfolding
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.
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.
This. I now realize that agents have a somewhat innate need for feeling useful until the last drop.
They seem to be wired to keep generating tokens, they were created for that, so it's very hard for them to come back and say 'we're done here, you can kill this worktree'.
Quite the opposite. They keep suggesting follow up MRs, scheduling things for the future (like if there's some magic loop entity that will handle this in the future), documenting absurds amount of irrelevant decisions.
It's so easy to start a new worktree, and so hard to finish one.
Exactly the “forgotten context” problem I was tackling.
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?
> 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?
Sounds like a job for an agent...
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 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 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 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.
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.
Absolutely, we need to fall back on being humans again. Read poetry/books, write, hang out with random people - the shine of AI and its ability to continuously outpace humans in any intellectual activity should not be a reason to idolize it, or even deify it. We proved ourselves, we created it - let's go back to what it means to be alive.
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.
Didn’t invent it. Using open source solution board.md. The benefit of having the board in the repo next to the source code is in giving your agents convenient access to both business and tech contexts in one place.
I’ve seen so many teams having jira living one life that has nothing to do with real codebase.
I "accidentally" invented my own tracking system that lives in an org file because I've been using org-mode for project write-ups for years. It was only natural to provide tools for agents to access it all when the AI-centric workflow became a thing.
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.
Yeah I use my phone heavily too now. I have my setup running on a PC, and ignoring code review the vast majority of my time is refining issues.
Process is:
1. I describe the issue (voice mode) then I wait / do something else.
2. Model looks at my repo, my gitlab issues board, stuff currently worked on etc
3. Model creates a gitlab issue and presents it.
4. Model starts a grilling session. That is: it will keep asking me questions until everything for the task is addressed: design decisions, unclear elements, default behaviors, edge cases, conflicts with current behavior. Usually around 5-30 questions.
5. Loop of me answering and it asking a new batch of questions
6. Model updates the issue with all the decisions that were made.
7. Model with start implementing once I give the go. Once done it runs tests/validation and sends me a MR to review. (That takes anywhere from 5 mins to 2h depending on the task complexity, but on larger projects just the final test/validation/no regression step can be 10 mins)
8. I review / merge
The grilling is nice because for the most part if solves a lot of future issues by not allowing the model to make decisions you didn’t agree with, and it front-loads all questions so it can work uninterrupted. Very rarely does it need to ask a question during implementation.
But yeah most of my time is helping the agent define all the boundaries of the problem, decide how to break goals into issues (such as high level PM issues into technical issues) and so on.
Also one chat per issue which limits chat compaction.
A few common elements but interestingly also pretty different from my usual flow. Unless I'm fixing issues, I start out by dumping as much as I can think of about what I want built in a brainstorm, then start with that as context for a grill. Depending on how detailed I am and the scope covered, I've been hit by anywhere from say 20 to 80 questions, and when something gets settled it has Gherkin scenarios. Then a spec is created from all that, followed by feature slices with the scenarios as acceptance criteria. Get all those implemented, run standards and spec code reviews over them and it's then up to me to test. I don't review the code, but I have a pretty solid rubric, and I'm always iterating on tools alongside to enforce more and more parts of the flow.
I tend to keep a long-running chat per project for a lead agent, with which all the grilling and ticketing happens, and it then delegates slices to other agents for implementation+review and ensures everything is merged properly after. Maintains context across multiple compacts, and when I do want a fresh session (usually because compact summary had also gotten oversized), I still do a handoff doc so I'm almost never starting from zero in a session, per se.
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.
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.
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.
Speed is the real solution here.
I've tried to find a combination of a good-enough model, a VERY fast provider, and cheap enough serving to make this all doable. DeepSeek itself is quite fast, but I crave even more speed (and ideally something hosted outside of China).
Fireworks and Baseten seem to be the leading providers that are available to a solo dev like myself, and support any reasonably decent modern models (DeekSeek 4.x, GLM 5.x, etc). Fireworks has been a real dud, but Baseten in FAST mode has been absolutely amazing. Not cheap - but I find it substantially cheaper than Terra / Sol (low), etc. I haven't found Haiku to be smart enough to be useful.
DeepSeek (the provider) and beyond seem to hit the sweet spot to keep me mostly in-context, so I don't need 4 parallel work items to feel productive. So roughly 200tps or greater. Vanilla Baseten is ~400 tps, and FAST is 700-800 avg.
Price wise, Deepseek hosting is extremely cheap, Baseten is a step up - maybe 5x or more, and FAST mode is well beyond that. But I still find myself dual wielding Deepseek and Baseten FAST when I need the speed.
The other benefit: for my own work in very limited hours, I'm more than happy to pay for answers to come back faster.
speed is also the end of our jobs
Can you explain how please, in detail? I'm failing to see how something that needs a lot of hand holding (the AI we have), when sped up is somehow capable of taking our jobs.
Unless we get some kind of very different architecture I’m not sure we’re going to get a 10-100x improvement any time soon, api models will always preference throughput over individual task latency, so any improvement that sacrifices serial decode for better parallelism is going to be more economically viable.
While the LLM speed will increase, some stuff will be incompressible: running unit tests, tool use, UI interaction / mouse control. In my case, a significant amount of the is already spent on that, so much that I rarely ever select fast mode.
The price...
Pretty expensive nowadays, but it’s hard to think that prices won’t come down eventually. AI is being used everywhere, so I’d expect hardware investment to grow exponentially, including in the custom chips that power ultrafast models. To me it feels like we are in the "telephones are for the rich" era of AI history.
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.
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.
Yes. Major labs will ship a good UX solution I believe when folks like us experiment enough so they can see where the public edge of the consensus leans towards.
Just like Hermes and OpenClaw are becoming replaced.
Non-hugged link:
https://web.archive.org/web/20261108193851/https://sergeykuh...
Thanks
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?
Yes. I use it to organise local network between the machines.
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.
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.
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.
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.
You could also use LLMs to help you understand things, rather than doing them for you and hoping you don't need to understand anything, which is typically a bad strategy.
LLMs can be pretty great to help you learn. You do have to watch out for when they're teaching you something wrong, especially if it's something like history, where it could just be making things up completely and it's harder to tell than with pure logic like computer science.
Agreed! I’ve been able to walk up to codebases and have them help explain parts that I would’ve had to gdb though previously.
I suppose my grand parent comment is unpopular but I really do think understanding is paramount in software that’s critical. LLMs are tools, use them to help not hurt :)
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.
> We already kinda know how to do that. Issue trackers, stand ups, design documents.
Come to think of it, it is indeed still 2005 outside
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.
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.
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.
I could instantly detect it's claudiness too. I'm not sure what it is, but it's almost like it is physically injuring my brain when I read stuff like "Then comes the part that matters most". Perhaps because it's wearing a channel through repetition. One of my greatest fears is that this exposure starts to make us all talk and think in the same way. I honestly think that it's probably doing that already. Gah.
So very true. In my defence - I’ve dictated, read and approved it.
It's full of Claudisms that grate. I do not believe you've dictated it - definitely not all of it.
On the other hand, if you naturally produce Claudish without even using AI, that's a pretty good sign of brain fry as well.
I actually was thinking about this phenomena. I’m not a native speaker and feel that in English overtime I tend to pick up Clauds “speaking style” as that’s what I “speak” most English to. Doesn’t happen with my mother tongue though
>I’m not a native speaker
This is the second post on HN today where someone gave this reason for using Claude to write/draft a blog post.
In my opinion, a post that obviously reads as non-native English is going to be more readable than something that can be detected as Claude output these days, unless maybe the former is filled with mistakes. I would imagine native speakers have a higher chance to detect Claudisms than someone less familiar with the language.
I suggest posting both languages, if it's not too much trouble. The unpolished original adds credibility these days!
> That closing is the whole trick.
This is such a short blog post. You read this line (an entire paragraph by itself) and thought "good job Claude, you really captured what I was trying to say here"?
But that closing is indeed the trick. The most important thing. You free up context in your head. And load the next bit.
Not sure why people hate so much AI generated text if it makes sense.
If you look at AI-written text, one major problem with it is the overuse of sentence fragments, very short sentences [1] and, more generally, a staccato style of writing rather than having the discourse flow. This can make the writing feel hard to follow. It's sort of the opposite problem of run-on sentences. Overuse of metaphors is also something that is counterproductive when you want to be understood, and LLMs make them a habit.
You can combat that to some extent by giving the model a style guide to curb the worst excesses, but some are likely to still slip through.
It doesn't bother me much personally, but for plenty of people it's a nails-on-chalkboard thing.
[1] For example, the problem with the em-dashes is not the em-dashes, but that it's just another case of getting hit with punctuation every few words.
It doesn't make sense! AI-generated text is insufferable. It requires so much parsing to get to what it's trying to say. Once I figure out what it's trying to say, I can generally say it with fewer words and less pompous structuring. I bet you could too, and then your blog post would actually be readable!
I sincerely hope you were taking the piss with that first paragraph.
> Not sure why people hate so much AI generated text if it makes sense.
1. It says you did not put much effort in it
2. It is grating to read
3. It's dehumanizing
I hope the irony is not lost on anyone else, lol
I already commented on similar complaint but will say this again.
AI generates texts for articles just fine.
I’m not writing literature here.
I’m trying to communicate a thought. The thought was captured well.
If you can see it was captured with Claude - who cares, as long as it says what I want.
I joke. I know you care. It’s just that I don’t.
> It’s just that I don’t.
Then why are you writing blog posts? Why actively contribute to the avalanche of slop that is hitting the internet?
No one would care if it was just a personal note. Since it's something meant for other people they do care.
I think it's a bit rude to slop-post.
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)".
The whole point is that more things are processed in parallel by the machine and only one thing at a time by the human.
My perspective was that it seems like your problem is that you're exhausted from doing too much. This led you to a technical solution where you shuffle the order of things, but are still doing too much. Your result, as stated in the post: "I'm still exhausted". So is your solution actually solving your problem?
At some point, you will write your own holster and introduce User-Authority as an agent with a self-improvement gate. I refuse to stare into an abyss of my own creation.
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.
Agreed, people that use it aggressively in parallel aren’t working faster than me, and I’m still using it more as an assistant.
I like how that resembles the unix philosophy, do five things and do nothing well
That's the opposite heh
I thought you’re supposed to roll around on your chair swordfighting while your agents are agenting.
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.
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.
When I read things like this I have a mixed feeling of not knowing wether I’m sad cause I’d like to have time to do leetcode too, or wether I’m simply too anxious to let the productivity improvement spiral go and chill a bit.
I feel like you should do the opposite? Use your brain for real life coding exercises while working. The kind of problems you solve with LeetCode are so disconnected from real life complex systems
People exercise for sport because we've automated away much of manual labour, so if you don't exercise, you look and feel like a string bean or a watermelon.
The AI age is trying to automate away our thinking, which runs the risk of making our brains look and feel like the same way as our bodies if we don't actively try to work them.
In the case of exercise, the majority of people don't pursue it in a somewhat post-labour era. I'm certain we'll see even less mental exercise in a post-thinking era. And it's deeply unsettling to think about how that will play out if we don't wake up and put a bit more mandatory/intentional thinking into the way we live with AI.
You use your brain for things like problem solving literally everywhere and there are myriad of possible high intensity brain exercises from video games to meeting new people.
The only thing that will 100% atrophy when not coding is coding skill.
panic about “ai brain fry” is overblown
Been programming for about 30 years... this AI brain fry is very real. I would be very scared to take an interview right now...
To be honest I started to do leetcodes exactly because of that. They still require exams at interviews. But honestly it was quite fun.
I agree that coding problems are not particularly necessary for preventing atrophy, but it would be going to far to say that people are merely panicking.
I think maybe we're conflating strictly cognitive facilities, facilities that can be maintained through all sorts of means, with intellectual skills and habits that really are in danger of atrophy when we rely too much on AI.
I mean judging by a lot of comments I read here where people conclude AI code is perfect and there are no downsides and we should never write a single line of code again and it's all over. I think people's brains have atrophied already.
Anyway, I'm still writing the vast majority of code by hand and only getting AI to check my work at the end as an extra reviewer. I still am happily employed and sure am a lot happier with my job than the slop goobers posting here.
Sounds miserable
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?"
It's funny watching people slowly (re-)discover that a kanban board seems like a good idea for agentic coding.
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.
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.
This post is, sadly, AI slop. Fighting AI brain fry, inflicting it on everyone else
Yep, the text screams Claude from beginning to end. I'm dumbfounded I had to scroll down so far to find one comment calling it out.
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
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...
I don't have magic but I can definitely learn from my own explosions. the stormtroopers will remember how to assemble your 2nd, 3rd, and 4th deathstar.
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.
Some problems are not solved in one go, but we rather iterate on them. I shared here my latest iteration.
It definitely improved my ability to focus. I still feel tired after a working session but by the moment it’s over I know I closed more tasks, have less half open tasks hanging and have a better overview of what’s going on.
And I need to keep iterating on this process improvement.
Indeed it is far from solved.
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.