| ▲ | 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. | ||