[PaulHoule]

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.

[brunaxLorax]

With git worktrees you can you have your agents working on literally different folders so they don't step up on each other.

[PaulHoule]

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)

[brunaxLorax]

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.