Well, I don't think anything can force the programmer to keep the prose and code in sync. The best we can do is give you an incentive to do so. The argument that was presented is that comments will get out of sync with code, but we're trying to provide tooling that will incentivize you to keep code and comments in sync.

I'd also like to say that if code is easier to read in the first place, there will be more eyes on it, and discrepancies will be resolved sooner. In most programming environments, a comment might describe a part of a much larger function. But the output of this code is far removed from the actual source. So discrepancies between comment and source are harder to spot.

It Eve, we intend these documents to be for more than just programmers. Who again, might not understand your code, but would understand the written prose and see the output /right there in the code/ that contradicts it. A bug like this would be brought to your attention much sooner than if your code was simply hosted as on GitHub.

Actual thing that will happen, if you're lucky: Dev changes the code to fix a bug, tests it, modifies it etc., finally gets it done. Deletes loving paragraphs of now obsolete text and writes in a one-liner description ("handle gravity effects")

Actual thing that will happen, if you're not lucky: Same as above, but they don't delete the obsolete paragraphs.

You can simply use BDD to keep in sync the requirements with the code. But BDD is not just prose, it is much much more powerful and useful.

Every company needs a human-readable definition of what a product does. There is no way to eliminate the problem of keeping prose and code in sync. Traditionally, we just hide the problem by keeping the prose and code entirely separate. Keeping them together makes it harder for them to drift apart.