Remix.run Logo
pllbnk 3 hours ago

I don't know how and if people really manage to run many tasks in parallel and also not check the output. Very recently I had two items that for a reasonably intelligent engineer wouldn't be very complex, but would take time to implement.

One of them was vibe-coding an Electron app for myself that was running a Llama server. Claude couldn't find out why it wasn't running on Windows while it worked fine on Linux and Mac. I obviously didn't check all its output but after several hours had a feeling that it was running in circles. Eventually we managed to cooperatively debug it after I gave it several hints but it wasted a a lot of time for a rather simple issue which was a challenge for me also because I didn't know well how the vibe-coded app worked.

The second one (can't go into details) was also something that's reasonably simple but I was finding awfully many bugs because unlike the first app, this one was for my job and I review everything. So we had to go back and forth for multiple hours.

How can someone just switch to another task while the current one requires constant handholding?

jeapostrophe an hour ago | parent [-]

My personal experience matches this. When I'm "succeeding", I am at the 5-to-7 minute cycle time and when I (or Claude) are failing, there's constant attention and no ability to switch away.

My human programming experience is encouraging me to keep going on the debugging, like I did when it was my code that I invested a lot of time and energy into.

Now that the code is cheap, I am trying to "learn" to throw away everything, go back to a stable checkpoint, and try a different approach that is more likely to succeed. (Probably having the new plan incorporate the insights I gained the first round.)

It is hard to do that when you coded for a week (or even a weekend) but it should be much easier when you got it faster with Claude. I think people (me at least) need to learn new norms.