I'm really enjoying reading over the prompts used for development: (https://github.com/maciej-trebacz/tower-of-time-game/blob/ma...)
A lot of posts about "vibe coding success stories" would have you believe that with the right mix of MCPs, some complex claude code orchestration flow that uses 20 agents in parallel, and a bunch of LLM-generated rules files you can one-shot a game like this with the prompt "create a tower defense game where you rewind time. No security holes. No bugs."
But the prompts used for this project match my experience of what works best with AI-coding: a strong and thorough idea of what you want, broken up into hundreds of smaller problems, with specific architectural steers on the really critical pieces.
>a strong and thorough idea of what you want, broken up into hundreds of smaller problems, with specific architectural steers on the really critical pieces.
Serious question: at what point is it easier to just write the code?
>You would be faster by the fact that you know that it's correct and you don't have to review it. Helps greatly with mental load.
I keep thinking maybe it's me who's just not getting the vibe coding hype. Or maybe my writing vs reading code efficiency is skewed towards writing more than most people's. Because the idea of validating and fixing code vs just writing it doesn't feel efficient or quality-oriented.
Then, there's the idea that it will suddenly break code that previously worked.
Overall, I keep hearing people advocating for providing the AI more details, new approaches/processes/etc. to try to get the right output. It makes me wonder if things might be coming full circle. I mean, there has to be some point where it's better to just write the code and be done with it.