When both programmers are the same model, double programming breaks

Double programming is one of the oldest habits in clinical statistical work, and for good reason. Two programmers take the same specification, work separately, and produce the same output twice. Then the outputs are compared. Where they match, you have reason to trust the result. Where they differ, you have found something worth checking. It is a simple arrangement that has protected countless submissions, and its strength rests on one quiet assumption: that the two programmers are independent of each other.

Generative AI does not attack that assumption head on. It erodes it, quietly, in a way that can leave the process looking exactly as sound as it always did while no longer delivering what it promised. This is worth understanding before AI-assisted programming becomes routine on both sides of the check.

Why independence is the whole point

Independent programming, sometimes called double programming or independent QC, works like this. A primary programmer builds the production version of an analysis dataset or a table from the specification. A second programmer, working separately, builds an independent version of the same thing. The two are compared, often with an automated diff, and any discrepancy is investigated until it is explained.

The assurance does not come from having the work done twice. It comes from having it done twice by people who are unlikely to make the same mistake. If the primary programmer misreads a derivation rule, the QC programmer probably reads it correctly, the outputs disagree, and the disagreement forces the error into the open. Two people rarely misread the same rule in the same way at the same time. That unlikelihood is the entire source of confidence. The comparison is a detector, and what it detects is disagreement.

How a shared model breaks it

Now put a foundation model on both sides. The primary programmer asks a model to write the production code from the specification. The QC programmer, independently and in good faith, asks a model to write the QC code from the same specification. If it is the same model, given a similar prompt and the same source text, the two requests are not independent at all. They are two draws from the same system, and that system has consistent tendencies.

Suppose the specification is ambiguous about how to handle a partial date, or which visit window a record falls into, or whether to carry a value forward. A human might guess either way, so two humans disagree and you catch it. A model tends to resolve the same ambiguity the same way every time. So it makes the same assumption in the production code and in the QC code. The two outputs agree. The comparison passes clean. And the result is wrong in both places, in exactly the same way.

Correlated errors are more dangerous than random ones, because your check was designed to catch disagreement, not a blind spot the two sides share.

This is the part that should give any programming lead pause. A clean comparison has always meant something. Once both sides can flow from the same model, a clean comparison can also mean that the model was confidently wrong twice and the two wrong answers matched. The green result looks identical either way.

Do not let a system grade its own work

A closely related rule follows from the same logic. Do not ask an AI to validate its own output. If the same system both produces a result and then judges whether the result is correct, you have not added a check. You have asked the same source for a second, more confident opinion. It will tend to defend the assumptions it already made, because they are its assumptions. This is not a matter of the model being careless. A separate mind is what independent QC is built on, and one model asked twice is not two minds.

Keeping the two sides genuinely different

The fix is not to ban AI from clinical programming. It is to make sure that at least one side of every check stays genuinely independent of the other. A few practical ways to do that:

Keep one pathway different in kind. If AI assists the production code, let the QC pathway be a human, or deterministic code, or at the very least a different model family driven by a prompt that someone wrote independently rather than a copy of the first one. The goal is for the two sides to have different failure modes.

Prefer deterministic validation wherever the output can be checked directly. If the thing you are verifying is a number, a count, a total, or a value that must satisfy a rule, compare it mathematically. Recompute it, or test it against the constraint. Do not ask a second model whether the number looks right. A deterministic check either passes or fails for a reason you can name, and it does not share the first model's assumptions.

Reserve AI-versus-AI checking for the cases where deterministic checks genuinely do not apply, such as open-ended narrative or free-text artifacts where there is no exact answer to recompute. Even there, keep the checker independent of the producer, and treat its verdict as a prompt for human review rather than a pass.

A plain hierarchy of validators

It helps to state the order plainly and use it as a default. Use deterministic code whenever a deterministic check is possible, because it is exact and it does not share anyone's blind spot. Use a qualified human when the question calls for domain or scientific judgment that cannot be reduced to a rule. Use AI-assisted evaluation only for genuinely open-ended tasks where neither of the first two fits, and even then keep it structurally independent of whatever produced the work. The failure of the last few years has not been AI itself. It has been reaching for the AI check first, when a deterministic one was sitting right there.

More models is not more independence

One tempting response is to throw more models at the problem: run the output past a second model, a third, a fourth, and count agreement as assurance. Be careful with this. Models that share training data, training methods, and the tendencies that come with them also share blind spots. Four models that all resolve the same ambiguity the same way do not give you four independent opinions. They give you one opinion, repeated, wearing four labels. Counting their agreement can feel like rigor while adding almost none. It can even be worse than a single check, because the show of consensus makes the shared error harder to doubt.

Independence is not a headcount. It is a property of how differently two things can fail. Two checks are only independent to the degree that a mistake in one does not imply the same mistake in the other.

Checks to confirm your QC is actually independent

• Can the production and QC pathways make the same wrong assumption? If both run through the same model and prompt, assume they can, and change one side.
• Is at least one side of the check deterministic or human whenever the output allows it?
• Where the output is a number or a value bound by a rule, are you verifying it by recomputation or constraint rather than by asking a model to eyeball it?
• If both sides use AI, are the model family and the prompt genuinely different, and written independently rather than copied?
• Does any system anywhere in the flow validate its own output? If so, that step is not a check.
• When several models agree, do they share training and therefore blind spots? If so, count their agreement as one opinion, not many.
• Can you name, for each check, the kind of error it would catch and the kind it would miss?

Design for independence on purpose

For decades, independence in double programming came almost for free, because two people were naturally two minds. That is no longer safe to assume. A single model can now sit on both sides of a check without anyone deciding that it should, simply because it was the convenient tool for each programmer. Independence has become something you have to design for, verify, and defend, rather than something you inherit from the fact that two names appear on the work.

The good news is that the discipline is the same one clinical programming has always practiced. Know what your check can catch and what it cannot. Keep the two sides different where it counts. Prefer the exact test over the plausible-sounding one. If you are working out how AI fits into your programming and QC process without quietly hollowing out your independent checks, talk to our team.