For me it's their speed, yes. I only run 0-3 at a time, and often the problem at hand is very much not complex. For example "Take this component out of the file into its own file, including its styles." The agent may take 5 minutes for that and what do I do in the meantime? I can start another agent for the next task at hand.
Could also be a bug hunt "Sometimes we get an error message about XYZ, please investigate how that might happen." or "Please move setting XY from localstorage to cookies".
I rarely run 10 top-level sessions, but I often run multiple.
Here is one case, though:
I have a prototype Ruby compiler that long languished because I didn't have time. I recently picked up work on it again with Claude Code.
There are literally thousands of unimplemented methods in the standard library. While that has not been my focus so far, my next step for it is to make Claude work on implementing missing methods in 10+ sessions in parallel, because why not? While there are some inter-dependencies (e.g. code that would at least be better with more of the methods of the lowest level core classes already in place), a huge proportion are mostly independent.
In this case the rubyspec test suite is there to verify compliance. On top of that I have my own tests (does the compiler still compile itself, and does the selftests still run when compiled with self-compiled compiler?) so having 10+ sessions "pick off" missing pieces, make an attempt see if it can make it pass, and move on, works well.
My main limitation is that I have already once run into the weekly limits of my (most expensive) Claude Max subscription, and I need it for other things too for client work and I'm not willing to pay-per-token for the API use for that project since it's not immediately giving me a return.
(And yes, they're "slow" - but faster than me; if they were fast enough, then sure, it'd be nicer to have them run serially, the same way if you had time it's easier to get cohesive work if a single developer does all the work on a project instead of having a team try to coordinate)
For one of the things I am doing, I am the solo developer on a web application. At any given point, there are 4-5 large features I want and I instruct Claude to heavily test those features, so it is not unusual for each to run for 30-45 minutes and for overall conversations to span several hours. People are correct that it often makes mistakes, so that testing phase usually uncovers a bunch of issues it has to fix.
I usually have 1-2 mop up terminal windows open for small things I notice as I go along that I want to fix. Claude can be bad about things like putting white text on a white button and I want a free terminal to just drop every little nitpick into it. They exist for me to just throw small tasks into. Yes, you really should start a new convo every need, but these are small things and I do not want to disrupt my flow.
There are another 2-3 for smaller features that I am regularly reviewing and resetting. And then another one dedicated to just running the tests already built over and over again and solving any failures or investigating things. Another one is for research to tell me things about the codebase.
People are doing this lots of different ways. Some run it in its own containers or in instances on the web. Some are using git worktrees. I use a worktree for anything large, but smaller stuff is just done in the local files.
Sloppy? Perhaps, but Claude has never made such a big mess that it has needed its work wiped.
> Sloppy? Perhaps, but Claude has never made such a big mess that it has needed its work wiped.
I think a key thing to point out to people here is that Claude's built in editing tools won't generally allow it to write to a file that has changed since last time it read it, so if it tries to write and gets an error it will tend to re-read the file, adjust its changes accordingly before trying again. I don't know how foolproof those tests are, because Claude can get creative with sed and cat to edit files, and of course if a change crosses file boundaries this might not avoid broken changes entirely. But generally - as you said - it seems good at avoiding big messes.
It just happens automatically. Once you set it running and it's chugging away there's nothing for you to do for a while. So of course you start working on something else. Then that is running ... before you know it, 5 of them are going and you have forgotten which is what and this is your new problem.
I've been reading Steve for a long long time. He's had a lot of good ideas, issued some solid advice, but has always had a quirky sense of humor. A few pages into it I thought "this has to be a joke". But I couldn't find the punchline. This is the most depressing comment section I've read in a long time. I might have to enter the lottery to become an apprentice electrician.
When I've looked at the power and energy requirements of vehicles it seems to follow some sort of log(size) law when it comes to speed and energy per mass distance. But not for acceleration which is linear.
What that means is a small vehicle like a motorcycle needs more energy and hp per lb than a car to have the same range.
So could see higher performance batteries being very useful for motorcycles. Have heard noises that electric motorcycles and bicycles are heavy feeling. So lighter probably would be considered better.
A guess: existing charging infrastructure is too slow/low power to charge this fast enough to be useful over currently standard batteries for car sized batteries
It can be many things, like large car companies staying away from unproven tech or them demanding production capacities too large to gamble with brand new tech.
This niche motorcycle brand has already established business relationships with Donut Lab, they were using Donut Lab's electric motors. Probably the Donut people easily worked out a release pipeline together in a bar or something, which would have taken years with VW.
+1. There’s also more upstart motorcycle makers than car makers willing to take a bet on new tech. Plus the difficulty of scaling manufacturing to serve much larger capacity car batteries.
I run a few projects that support me; this is one of them. This project did allow us to buy another neat domain, though: onions.com (used profit from one season to purchase)
Volumetric capture like this allows you to decide on the camera angles in post-production
reply