I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.
That's a good point and honestly I occasionally do the same thing. Sometimes you have to build something wrong to understand what right looks like. I think the distinction is between exploratory prototyping (building to learn/think) and expecting the prototype to BE the product. The first is thinking, the second is where the 100-hour gap bites you in the ass.
This. It’s also much easier to tell someone what you don’t like if what you don’t like is right in front of you than to tell them what you want without a point of reference.
See "Programming as Theory Building": https://pages.cs.wisc.edu/~remzi/Naur.pdf