どの様な話？
プログラミングにおいて因果とは、
- 他のプログラムの部分で出来た値などを参照したり、
- 他のプログラムの部分を呼んだり、
して発生します。そして因果はグラフで表されます。
それに対して、仕様において確率とは、
- して欲しい事自体が曖昧で有ったりして、
- して欲しい事をある意味曖昧に言う事
で発生します。
因果推論は確率から因果を求めるのに役立つ手法だと思います。
2021年ノーベル経済学賞で、
- 「『自然実験』と呼ばれる手法を使って、労働市場に関する新たな知見を提供した」
事を受賞理由としたとの話もありますが（統計的因果推論 Wikipedia 日本語版）、実験し放題のプログラミングの分野においては、
- たまたま（自然に）起きた事象を取り上げて、
- 実験とする
とかいう迂遠な事をする必要が無いと思います。それこそがまさにテストだと思います。"実験くん"をしまくりで全く問題有りません。
確率の振れを減らす方向と、振れを許容する方向
COBOLの頃は、
- 確率の揺れを減らし（仕様・実行条件などを厳密に固定し）、
- ユニットテストのみを行うだけでテストが済む様に
していました。なぜならユニットテストを超えたテストなど、出来るマシンが無かったからです。
データ指向もそうですが、テスト駆動開発も、割と先祖返りの気が有る様に見えます。
「仕様・実行条件などを厳密に固定し」と言うのは20年、30年、50年単位で見ると不可能なので、ある程度以上、変化を抱擁しなければならない*1 のは必然で、
「仕様・実行条件などを厳密に固定することが好ましい」自動テストなど、それ(変化の抱擁)に棹さす存在かも知れません。
自動テストでなければ何か？
実務でテストをした時、
- 仕様の一覧（エクセルで出来ていましたが、別にそれに拘りません）を見て、
- 一項目、一項目、仕様に沿っている事を示せる様な操作をして、
- 逐一、ハードコピーを取り、
- 保存する（エクセルに保存していましたが、別にそれに拘りません）
をしていました。
- 確率である仕様を入力とし、
- 因果であるプログラムを操作し、
- 検証出来る操作過程を保存し
ました。技術的負債の返済などは、プログラム→プログラムの自己同型でしたが、テストとは確率→因果（別の見方ではプログラム→正しさ）を示す必要が有り、仕様・実行条件などを厳密に固定出来ない以上、それを成し遂げるのに、単なるプログラムである自動テストのテストドライバでは力不足だと思います。
その様なものの達成を尊び、プログラミングのKPIに組み込み、評価（給料に影響する）を壟断しようとする輩は反動だと思います。
（嫌でも）変化を抱擁するの必要とされています。
結論
これからも難敵で有る「因果と確率」の存在でプログラミングが嫌いになる人は存在し続けることでしょう。
*1:『ある物流大手の経営企画担当者に「システム障害はたまに起こったほうがよいのですよ」と面と向かって言われたことがある。』 50年トラブルなしは「単なる幸運」、全銀システム障害に見る構造問題 日経クロステック 木村岳史の極言暴論！ 2023.12.18
