(I assume the question is made from the code-design/architecture point of view, not game-design one, though the answer at least to some degree applies to both.)
As already said, you need both, and you need to balance it. Both overdesigning and underdesigning your code flow/structure can cause problems. It is hard to say what the right balance is, but generally I find that I need to have at least a vague idea how the rest of the code will join up with what I'm programming at the moment, and think about possible issues, otherwise I tend to "code myself into dead end" - get into a situation where I realize "okay, now thanks to how I solved this problem, I created a new problem which rendered my whole previous solution (or even more, in worst cases) futile".
Generally, in my opinion, you can roughly judge whether you have the right balance by thinking about "what if" scenarios as in "what if I later (when everything is fully implemented in the similar paradigm as I'm using now) find out that part A needs to work slightly differently which will mean I have to completely rework part B that connects to it accomodate the changes?". If architectural change in one part doesn't require you to change more than one or two other parts, and the changes do not cascade (meaning that in turn you have to change also next parts connecting to the part B, and then parts connecting to them, etc.), the code is compartmentalized in a relatively good way.
But really, this is something you'll get a feel for after gaining some experience. This is partially why everyone gives the beginning gamedevs advice to first code something known and easy (Breakout/Tetris/Snake) and to do it completely, with all the menus, sounds, effects, everything to make it fully finished game - it is better to screw up smaller project, and doing it (whether in a good or bad way) will exactly help you to get a feel how far effects of various architectural decisions span.