[florianherrengt]

I do agree that I should take responsibility for my work. This is why I experimented on a small side project with a limited user base instead of my main app, which generates my income.

What really sold vibe Coding to me was the idea that I could be significantly faster by working on multiple features in parallel. I'm an agent orchestrator. I send them off in the right direction, regularly check on them and correct if needed. They run all the tests and keep working until they all pass. Once they're done, I review their work and if I'm satisfied, merge it.

The hard reality is that properly reviewing code at this scale is extremely difficult and I inevitably let errors slip through.

Maybe I should spend more time reviewing it. But I'm almost certain it would take me more time and effort than writing the code myself and I'm not even sure I'd ever reach the same level of understanding.

If I ask Claude to do one thing at a time and monitor it, I need to get the prompt right, wait for it to respond with some changes and then review them thoroughly before accepting them. I can imagine this being an alternative way to build software. But I doubt it's faster.

[hotpotat]

In my experience limiting myself to two projects in parallel is most productive, with a clear primary project whose agent’s completion take precedence over the other’s. It lets me still have concurrent work going on, but I’m very clearly still taking care to be precise and targeted with my prompting. Too many things going on, and I’m no longer optimizing for doing the task but for having as much parallel execution and progress as possible, and that’s a trap of perceived productivity.

[florianherrengt]

I mean it is right there at the beginning:

> “I went from 4-5 parallel branches down to 2, sometimes just one. […] I had to stop to think things through.”

Where do you see me drunk on power here?

My point is that it isn’t faster because producing the code isn’t the bottleneck.