This is a Tyranny of Structurelessness sort of thing. In that essay there is a structure in structureless organizations but it's implicit and unarticulated which makes it inscrutable, potentially more malleable (which could be good), but also constricting to those who don't know the actual structure when they try and accomplish things.
If you don't have explicit specifications (which don't have to be complete before starting to develop code), you still have specs, but they're unarticulated. They exist in the minds of the developers, managers, customers, and what you end up with is a confused mess. You have specs, but you don't necessarily know what they are, or you know something about them but you've failed to communicate them to others and they've failed to communicate with you.
If you define “specifications” as a formal document with that title atop, then you’re right.
If you define it as a description of what needs to be built then by definition you can’t build what is not described.
User stories are a type of specification. “Build me a Facebook clone” is a type of specification. A well-refined Figma doc is a type of specification. They all specify what needs to be built at various levels of fidelity.
And TTD would say "start with a failing test, it is an executable specification for the code that you will need to make it pass. Then make it pass, then refactor to make nice code that still passes all tests - red, green, refactor under tests"
In contrast they're still the standard in the hardware design world.