"Parallel Processing" - having two programmers code the same requirements as quality control?

I joined an office several years ago in which the dominant method of testing/QC is to have two programmers code up the same set of business requirements and then check the output as a way to "test" the code, identify ambiguities in the business requirements themselves, etc. To be clear, the programmers are NOT pair programming - they are intentionally silo'ing themselves in order to achieve a kind of "blind replication" (the programmers in the office mostly have backgrounds in statistics and research rather than in software engineering).

I understand the method here, but think it's tremendously expensive time-wise, and doesn't actually achieve test coverage that's replicable over time. I am advocating for a more built-in and automated testing approach and so am looking for pros/cons arguments about various methods, but can't find anything online that actually discusses this "blind replication" approach currently in use in the office. At present, the programmers don't see anything problematic with the current approach.

Does anyone know of a resource that discusses this approach?