Here are a few examples of what I thought was clearly understandable from my "1-10% non-determinism in LLM coding output":

- Variations in code patterns used. Might be a chain if if/else-s and not a case/switch statement;

- Different decomposition of a hierarchy of functions/modules/classes;

- Uses RED->GREEN test discipline, or not;

- Writes the tests before the code, or not;

- Different saga patterns (call 3rd party API before our own DB transactions, or vice versa);

- Use sleeping and not message passing wherever the latter is applicable.

There are dozens more. The innate non-determinism of the LLMs flips the dice sometimes and that leads to subtle bugs -- which is maddening, especially if the disciplines on how to write one thing or another are clearly spelled out in `AGENTS.md`.

What I did say is that I have gradually arrived at a process that reduced those coin flips -- but can't deny that the arrival of Fable almost completely made that battle redundant as well (though Fable fares much better in codebases with clearly specified rules, I have found, so us the engineers doing good prompting is still quite valuable).

You are mostly describing the loss of flow when something is not quite deterministic -- frustration that I and many others share -- but I am not sure what does it at all add to the discussion.

Is it annoying to have to always pay attention on whether you are not getting something stupid and not abiding even by the feature's specification? Sure. No denying that. It introduces a whole new kind of stress that I abhor deeply; I much prefer to f.ex. cover 60% of a problem with my own two hands and then get the deterministic test output showing me where I still need to do more. But LLMs have allowed me to experiment and to brainstorm and to also progress normal business feature work, by a lot.

Hence, I will not stop using LLMs because they are not 100% deterministic. ¯\_(ツ)_/¯