Where the Automation Has to Stop

I feel the same, but still believe there is a way to organize my work to make it happen. It’s more like leading a team of juniors: don’t let them drag you into their private rabbit holes, enable them to implement how ever tiny or big chunks they are able too. The common problems is exactly a Junior habit: always inventing new stuff instead of moving existing pieces, always adding never removing and punching holes in blackboxes to workaround mystery.

> I can do it for my toy projects where I don’t have a fucking clue what’s going on, even though I actually read the code

This is arguably harder than releasing a bunch of agents to try different approaches to the same problem, the latter resembling more of what I do when I’m working.

If I’m running five random toy projects that have nothing to do with each other, that’s five separate context windows I have to simultaneously maintain. You quickly learn not to do that because it’s just ADD multitasking with fancy new tools. If, on the other hand, I have a single problem where I feel there are a couple approaches that work, having agents simultaneously build each of them while I go back and forth monitoring what they’re doing, nudging them (from both experience and seeing what the other agents are doing) and occasionally killing a branch when it proves unworkable, that really only involves a single problem context to be maintained. It’s closer to working with a team of colleagues in a white boarding exercise while a couple furiously work through independent approaches on pen and paper.