Fast prototyping helps when the prototype forces contact with the problem, like users saying "nope" or the spec collapsing under a demo. If the loop is only you typing, debugging, and polishing, you're mostly making a bigger mess in the repo and convincing yourself that the mess taught you something.
Code is one way to ask a question, not proof that you asked a good one. Sometimes the best move is an annoying hour with the PM, the customer, or whoever wrote the ticket.
I completely agree with this. I actually spent some time recently working on the design for a project. This was a side thing I spent months thinking about in my spare time, eventually spec'ing an API and data model.
I only recently decided to take it on, given how capable Claude Code has become recently. It knocked out a working version of my backend pretty quickly, adhering to my spec, and then built a frontend.
The result? I realized pretty quickly that the (IMO) beautiful design just didn't actually work with how it made sense for the product to work. An hour with the prototype made it clear that I needed to redesign from the ground up around a different piece to make the user experience actually work intuitively.
If I had spent months of my spare time banging on that only to hit that wall, it would've been a much more demotivating experience. Instead, I was able to re-spec and spin up a much better version almost immediately.