> How is this a problem? I never said this was a problem. > Again, PMs and engineering managers get by just fine with standard natural language. I agree only

> How is this a problem? I never said this was a problem. > Again, PMs and engineering managers get by just fine with standard natural language. I agree only to some extent. At least in my experience, edge cases are often hashed out between the PM and engineers in spontaneous meetings, Slack conversations, or <insert medium of choice>. If ticket descriptions / acceptance criteria then get adapted accordingly, great. (Most of the time they don't – since we're so fucking agile.) Though, even if the descriptions/criteria do get updated, they often still lack precision and require interpretation – which is no problem, since all engineers now know what is meant by the ticket description and how to handle the edge case. However, if your entire spec is natural-language-based and you want your AI to reliably generate the same code every single time without needing to provide additional context, you better make sure to remove any ambiguity from the spec. But removing ambiguity from natural language basically comes down to speaking like a mathematicion / programmer, so the natural language spec will end up being rather similar to (pseudo) code again. So you're essentially back to programming.