There are a lot of reasons anyway I like to have the design doc around. A few:
* I think the designs are often better when people write down their goals, non-goals, assumptions, and alternatives rather than just writing code.
* Reading previous designs helps new people (or even LLMs I guess) understand the system and team design philosophy.
* It helps everyone evaluate if the design still makes sense after goals change.
* It helps explain to upper management (or promotion committee in a large company) the work the author is doing. They're not gonna dig into the code!
...so it's usually worth writing up even if not as a stage before implementation starts. It can be a quick thing. If people start using a LLM for the writing, your format is too heavy-weight or focused on style over substance.
There's definitely a negative side to approval stages before shipping, as this article points out, but when quality (reliability, privacy/security, ...) is the system's most important attribute, I can't justify having zero. And while getting the design approved before starting implementation isn't necessary, it should avoid the bad experience tombert had of having to redo everything.