Comment by wildzzz
1 day ago
It happens with Opus when I leave too much up to interpretation and the AI doesn't do what I had envisioned but didn't specify. Like sure, what it did may be a technically correct solution but it's not the correct solution that allows for further development of my idea. I'm not sure how others do their projects but I start small with proof of concepts and develop in layers until the project does what I want. I use plan mode first to layout everything I can think of that I ultimately want and describe features in the best detail I can manage. I work with Claude to figure out the best framework or find whatever existing projects can serve as a starting point. The first milestone is the proof of concept, take the framework/existing project and build something that does the bare minimum of what I need in the way I want it done then build a test suite to make sure it works. Once that's proven out, we start adding more features (both mine and the ones Claude has suggested) and adding/revising tests along the way. For small things, I won't bother with a plan since I generally already know what I want or any ambiguities can be solved in a single response. But for larger things, I try to take a waterfall approach with well defined milestones.
If I knew exactly how I was going to build something, I would have built it myself. But since there's some ambiguity in the portions of the project I'm less familiar with, I rely on the plan to not only help me understand the decisions Claude has made for me but to keep Claude constrained to the decisions I've made. It's very frustrating to waste tokens on having to refactor something because
I can relate to this. But this part doesn't make sense to me.
> But for larger things, I try to take a waterfall approach with well defined milestones.
> If I knew exactly how I was going to build something, I would have built it myself
Aren't these contradictory? If you don't know exactly what/how to build, how can you do waterfall?
Yeah IMO there's two entirely different traps I've seen in startup codebases in the last year or so:
1) "Maybe waterfall works now" - plan mode, take care of all the nits and issues that the bot leaves on your PR, wildly overengineered "enterprisey" solutions with a lot of bells and whistles all over the place but very poor end-to-end user story test coverage that results in user experiences with a lot of good test coverage of the edge cases of how a given step might fail but little thought towards overall user flow and throughput. Because part of the issue with waterfall was assuming you could design the right tool for your user up front.
2) "Maybe code doesn't matter anymore" - The just ask for something when you need it approach, which results in weird janky individually-sorta-working but strangely-overlapping six-variants-of-the-same-thing that makes it hard for your users to develop a single consistent mental model of the thing they're using, and that changes super frequently.
They both end up with a lot of other bad-for-velocity things that I assume are inherent to how the tools have been refined in response to last year's criticism, too. Super verbose comments. Extensive - without much eye toward runtime - low-level test coverage that might miss the forest for the trees and also slows down the next round of iteration cycles. A plethora of new proper nouns all over the place that make the documentation an ouroboros without a good entry point.