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.

a.k.a. the waterfall model

that straw man that someone came up with to illustrate bad software processes and then people started actually using it

There’s a middle ground between not writing any sort of design documentation at all and insisting that every little detail is nailed down in a Word document and carefully laid out on a Gantt chart before a single line of of code can be written.

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.

Most spec dev/designs doc are written by bots because this is what management forces us to do... ( by doing same in all other areas of company).

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.

Initial design and specs are very important.

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

An unambiguous spec is indistinguishable from code.

This works for nothing but the trivial or almost trivial software.