[SystemSafety] N-version programming moves the goal posts

[Derek M Jones]

Steve,

> Clearly the participants were all human developers. The conclusion they drew, however, was that N-Version programming by humans was not that beneficial because the different programmers all tended to make the same mistakes. So one line of reasoning could probably be this:

There has been lots of criticism of studies in psychology
being based on a narrow cultural range, i.e., undergraduate
students in the US, e.g.,
https://en.wikipedia.org/wiki/Ultimatum_game

> 1) As shown by Brilliant, Knight, and Leveson in the 1990s, human developers tended to inject the same kinds of defects into the code they wrote

van der Meulen's PhD thesis
"The Effectiveness of Software Diversity"
provides a more nuanced analysis.

> 2) Based on the kinds of repeated defects they reported, there is probably no valid reason to believe that any of that has changed since the 1990s, meaning most existing code today suffers from those same common defects

Employing developers from different cultural background is
difficult.  However, LLM primarily trained on text from
different cultures is another matter.
For instance, Chinese models vs US models.

> 3) LLM-generated code comes from models that have been trained on contemporary, available code and thus, is trained to include those same common defects
> 
> Why should anyone expect that LLM-generated code would NOT suffer from the same commonly-repeated patterns of defects that have always been there?

Diversity of LLMs used and diversity of generated programming
language reduces the amount of commonality.

> Then you wrote, “So the correctness issue has now shifted from the code to the specification.”
> 
> I counter-propose that the correctness issue has ALWAYS been in the specification. Code can only be correct with respect to 

The correctness issue has been both specification and code.
As (if?) LLMs get better the correctness of the mapping between
specification and code will become a much smaller issue.

some specification, it cannot be its own definition of correctness (despite what Microsoft and others would like to 
claim). Incidentally, the most common defects found in the Brilliant, Knight, Leveson study included things like 
boundary conditions (“corner cases", "edge conditions”) that were unspecified and thus not properly addressed because 
they did require special handling. So even their results can be seen as pointing a very clear finger at incomplete 
and/or ambiguous specifications.
> 
> I believe the critical question has always been, and will continue to be, “what is the form of a specification that would give the highest probability of resulting in correct code?” without regard to whether the code would be generated automatically by some machine or manually by some human. In the end, both producers of code would need the same kinds and amounts of detail.
> 
> 
> — steve
> 
> 
> 
> On Jun 10, 2026, at 5:20 AM, Derek M Jones <derek at knosof.co.uk> wrote:
> 
> All,
> 
> N-version program is a great idea, but it is is also a lot
> more expensive.  At least until LLMs came along.
> 
> This paper
> https://arxiv.org/abs/2606.07828
> 
> creates five implementations of a 23k line specification.
> Five different languages were used for the implementation,
> but that is just for bragging rights.
> 
> So the correctness issue has now shifted from the code to
> the specification.
> 
> A few months ago an LLM generated a C compiler.  The compiler
> did very well on correct code (which is the vast majority of
> the training data), but very badly on incorrect code.
> https://shape-of-code.com/2026/02/22/investigating-an-llm-generated-c-compiler/
> 

-- 
Derek M. Jones           Evidence-based software engineering
blog:https://shape-of-code.com