We are not all as smart as you are
Back in the day, we had COBOL, and sometimes CICS, and frequently a database -- or not. We also had teams. The best results came from communicating to the end users and the team members in some sort of common language. We used flow charts, pseudocode, and sometimes a sort of graphic prototype for screen flow. We also used something we called structured programming, which is more natural to the modern programming languages, starting with PL/1.
The prototype, if any, was contained in the structured program, in which control passed to PERFORMs, also known as subroutines. The comments at the beginning of each set of paragraphs in the PERFORM would be the statement of what it was supposed to do. While writing this non-code, we discovered errors in thinking and design.
We could do this as a group, because there were also CALLed programs, with parameters. The design team could say up front what should be in the program, and define its inputs and outputs. Common data definitions were put into the same sort of INCLUDE libraries used today.
There would have been no point in writing all this in the target language, COBOL (and sometimes assembly language). It isn't self-documenting, despite claims. Using and maintaining the comments, taken from pseudocode, was a best practice that lived on in some form through C and possibly Java. Anything larger than a single algorithm (e.g., an operating system, a compiler), requiring teamwork over a period of time, needs this thoughtful design phase. Even if, like Linus Torvalds, you ended up writing it all yourself.