3 ms·

Daily agentic user here, and to me the problem here is the very notion of "vibe coding". If you're even thinking in those terms - this idea that never looking a

Daily agentic user here, and to me the problem here is the very notion of "vibe coding". If you're even thinking in those terms - this idea that never looking at the code has become a goal unto itself - then IMO you're doing LLM-assisted development wrong. This is very much a hot take, but I believe that Claude Code and its yolo peers are an expensive party trick that gives people who aren't deep into this stuff an artificially negative impression of tools that can absolutely be used in a responsible, hugely productive way. Seriously, every time I hear anecdotes about CC doing the sorts of things the author describes, I wonder why the hell anyone is expecting more than quick prototypes from an LLM running in a loop with no intervention from an experienced human developer. Vibe coding is riding your bike really fast with your hands off the handles. It's sort of fun and feels a bit rebellious. But nobody who is really good at cycling is talking about how they've fully transitioned to riding without touching the handles, because that would be completely stupid. We should feel the same way about vibe coding. Meanwhile, if you load up Cursor and break your application development into bite sized chunks, and then work through those chunks in a sane order using as many Plan -> Agent -> Debug conversations with Opus 4.5 (Thinking) as needed, you too will obtain the mythical productivity multipliers you keep accusing us of hallucinating.

swordsith 8mo ago
good take, I wish opus 4.6 wasn't so pricy its great for planning.
- peteforde 8mo ago
  I've been using 4.6 to do planning, and then switching to 4.5 for agent/debug. 4.5 sticks to a 200k context window, which is how you keep costs sane.
lanstin 8mo ago
Things that claude code/vibe coding is great at: 1. Allowing non-developers to provide very detailed specs for the tools they want or experiences they are imagining 2. Allowing developers to write code using frameworks/languages they only know a bit of and don't like; e.g. I use it to write D3 visualizations or PNG extracts from datastores all the time, without having to learn PNG API or modern javascript frameworks. I just have to know enough to look at the console.log / backtrace and figure out where the fix can be. 3. Analysing large code bases for specific questions (not as accurate on "give me an overall summary" type questions - that one weird thing next to 19 normal things doesn't stick in its craw as much as for a cranky human programmer. It does seem to benefit cranking thru a list of smallish features/fixes rapidly, but even 4.5 or 4.6 seem to get stuck in weird dead ends rarely enough that I'm not expecting it, but often enough to be super annoying. I've been playing around with Gas Town swarming a large scale Java migration project, and its been N declarations of victory and still mvn test isn't even compiling. (mvn build is ok, and the pom is updated to the new stack, so it's not nothing). (These are like 50/50 app code/test code repos).
- peteforde 8mo ago
  I just don't get it. Why do all of that when you can just keep a tight hold on an agent that is operating at the speed that you can think about what you're actually doing? Again, if you're just looking to spend a lot of money on the party trick, don't let me yuck your yum. It just seems like doing things in a way that is almost guaranteed to lead to the outcomes that people love to complain aren't very good. As someone getting excellent results on a huge (550k LoC) codebase only because I'm directing every feature, my bottleneck is always going to be the speed at which I can coherently describe what needs to be done + a reasonable amount of review to make sure that what happened is what I was looking for. This can only work because I explicitly go through a planning cycle before handing it to the agent. I feel like if you consider understanding what your LLM is doing for you to be unacceptably slow and burdensome, then you deserve exactly what you're going to get out of this process.

swordsith 8mo ago

good take, I wish opus 4.6 wasn't so pricy its great for planning.

peteforde 8mo ago
I've been using 4.6 to do planning, and then switching to 4.5 for agent/debug. 4.5 sticks to a 200k context window, which is how you keep costs sane.

lanstin 8mo ago

Things that claude code/vibe coding is great at: 1. Allowing non-developers to provide very detailed specs for the tools they want or experiences they are imagining 2. Allowing developers to write code using frameworks/languages they only know a bit of and don't like; e.g. I use it to write D3 visualizations or PNG extracts from datastores all the time, without having to learn PNG API or modern javascript frameworks. I just have to know enough to look at the console.log / backtrace and figure out where the fix can be. 3. Analysing large code bases for specific questions (not as accurate on "give me an overall summary" type questions - that one weird thing next to 19 normal things doesn't stick in its craw as much as for a cranky human programmer. It does seem to benefit cranking thru a list of smallish features/fixes rapidly, but even 4.5 or 4.6 seem to get stuck in weird dead ends rarely enough that I'm not expecting it, but often enough to be super annoying. I've been playing around with Gas Town swarming a large scale Java migration project, and its been N declarations of victory and still mvn test isn't even compiling. (mvn build is ok, and the pom is updated to the new stack, so it's not nothing). (These are like 50/50 app code/test code repos).

peteforde 8mo ago
I just don't get it. Why do all of that when you can just keep a tight hold on an agent that is operating at the speed that you can think about what you're actually doing? Again, if you're just looking to spend a lot of money on the party trick, don't let me yuck your yum. It just seems like doing things in a way that is almost guaranteed to lead to the outcomes that people love to complain aren't very good. As someone getting excellent results on a huge (550k LoC) codebase only because I'm directing every feature, my bottleneck is always going to be the speed at which I can coherently describe what needs to be done + a reasonable amount of review to make sure that what happened is what I was looking for. This can only work because I explicitly go through a planning cycle before handing it to the agent. I feel like if you consider understanding what your LLM is doing for you to be unacceptably slow and burdensome, then you deserve exactly what you're going to get out of this process.