Coding assistants are slow. So we multitask
8 comments
Personally I'm careful about multitasking. If you had two agents working on things in parallel you are going to have more problems stomping on each other's work even if they are working in two different checkouts of the same code. Also in terms of your effort supervising them if you are going back from one to the other you're more likely to get confused.
I wouldn't say "never multitask" but I think you should think carefully about a portfolio of things you can work on that don't conflict with each other.
One possibility to to race analysis of situations with an LLM. For instance punch in a prompt asking if it can figure out the cause of a bug and go off and try figuring it out yourself in the debugger. Or read or write documentation when it is off on a mission.
I wouldn't say "never multitask" but I think you should think carefully about a portfolio of things you can work on that don't conflict with each other.
One possibility to to race analysis of situations with an LLM. For instance punch in a prompt asking if it can figure out the cause of a bug and go off and try figuring it out yourself in the debugger. Or read or write documentation when it is off on a mission.
With git worktrees you can you have your agents working on literally different folders so they don't step up on each other.
that solves the problem of "stomping on things" in the short term but it might not be trivial to merge these later. depending on what kind of tasks you're giving them and the style in which they do them it could be anything from "no problems" to "lots of headaches" -- the same is true for human developers.
(I've definitely seen 20 developer teams that were spinning their wheels because they were stomping on each other despite using version control as well as teams that had code rot because they had a "no refactoring/don't touch a file you can possible avoid touching" policy)
(I've definitely seen 20 developer teams that were spinning their wheels because they were stomping on each other despite using version control as well as teams that had code rot because they had a "no refactoring/don't touch a file you can possible avoid touching" policy)
I agree. However as you said, you can consider code agents like human contributors. My feedback is that an army of Claude Code instances with a strict CLAUDE.md file is more rigorous than a human team.
I recently came across https://claudecode.run/ (not affiliated). There are currently several similar products that help that multi-instance Claude Code layout
Genuinely curious: how quickly do you need new code written? What kinds of things are you working on that still aren’t being done fast enough?
How quickly? There is no limit to that. If I can do my day of work in few hours I would be glad to take the afternoon off or to go twice as fast (importunately that's more the second!)
Why build software slower than possible? Do you just enjoy wasting people’s time?
Obviously they are extremely fast in comparison to the best human programmers, but they are still too slow to be our one-to-one enhanced pair programmer. Our current solution is multi-instances, toggling between tasks. However, Multitasking is known to be a poor method, with low productivity and causing harm as it increases cognitive load, stress and fatigue levels.
I am sure that this is temporary and we will soon have coding assistants fast enough for deep focus on single tasks. What do you think?