This is why you should start with design spec before starting a line of code.
If the spec cannot resolve ambiguity you refine the spec not the code.
If the spec cannot resolve ambiguity you refine the spec not the code.
However, as other folks have pointed out, it is not possible resolve all things initially. Especially with customers who have feedback. Building and iterating is critical.
IMO It’s important to have a way to collaborate and move forwards together as a team while building. Keep everyone working off the same abstraction so mental models don’t drift and people start building the wrong things
and yes you're describing waterfall as sibling comment said...
Development is about building shared understandingbwhat we want including code as physical manifestation. Not only code matters.
that straw man that someone came up with to illustrate bad software processes and then people started actually using it
Sometimes jumping straight in and seeing what happens is the right path, other times the changes you’re making will impact a bunch of systems and teams so coming to some agreement on what’s being done is valuable.