> someone still has to explain what needs to be done in natural language unless the end customer is also the programmer

You're conflating requirement analysis with design. The customer only needs to describe the problem — a set of constraints on what comprises a valid solution. The software engineer is then free to design and develop a particular valid solution (and show it to the customer, which will result in more feedback, which will feed back into design, and so on.)

Formalizing this split is the premise behind Domain Driven Design (DDD): you can sit with the customer and pin down a problem description (= set of design requirements) together with them, expressed in exactly the natural language the customer-as-problem-domain-expert uses, without any reference to any particular potential design's solution-space domain. You can then turn around and reuse that set of natural-language statements as the skeleton of a test suite, that "enforces" the customer's expectations upon any potential design you create.

It's a lot like an artist sitting with a customer who's commissioning them, with the artist sketching something the customer is describing; and then the artist going away to actually illustrate/paint/craft/design/etc the thing, constrained by that sketch.