I'd say, in this analagy, step two is filling in half the numbers by gut feeling, and then three is seeing how wrong the guesses were and actually solving it.
Perhaps I'm uncommon in that I make diagrams and even sometimes pseudo-code (mostly in the form of mapping out function names, because they serve as a proxy for program flow paths) before I write actual code, but I don't find myself really going off gut feeling. I have a pretty good idea of what the program is going to look like and do before I start, and with e.g. Claude I give those to it, so it mostly looks like what I envisioned, unless it suggests changes.
For me, unstructured things (like non-formal diagrams, notes, pseudocode) are close to useless. I much prefer sketching the API surface in code right away and then iterating on it, building abstractions which cut the shapeless thought blob into neat, predictably interacting parts. The code is my notepad and the compiler is with me, every step of the way, catching contradictions and handwavyness.