コードでは、大きな乱数を生成し、選択肢の数で modulo を取ることでリストからランダムな要素を選ぶパターンがよく見られます：`choice = items[rng() % n]`。このブログ記事では、これにより各アイテムが等しい確率で選ばれない理由を示しています。乱数ジェネレーターが 0 から 9 （10 の可能性）まで一様に値を生成し、3 つのオブジェクトからいずれかを選びたい場合、対応付けは次のようになります：値 {0,3,6,9} → 第1オブジェクト、{1,4,7} → 第2オブジェクト、{2,5,8} → 第3オブジェクト。したがって、第1オブジェクトは 10 回中 4 回（40 %）選ばれ、他の2つのオブジェクトはそれぞれ 10 回中 3 回（30 %）しか現れません。この一様性の喪失を modulo バイアスと呼びます。
一様性を保つ正しい方法は、望む範囲内で一様に整数を返す関数を使うことです。例えば `random_between(l, h)` などです。3 つの選択肢の場合、`random_between(0,2)` を呼び出して結果を直接マッピングします。より表現力豊かな API は、相対的な整数の重みを受け取る `random_choice(options)` です。たとえば `[(A,4),(B,3),(C,3)]` とすると、本当にその分布が意図されている場合は同じ 40/30/30 の分布になりますが、プログラマーが望む確率を明示的に指定できるようになります。この記事では、ほとんどの標準ライブラリ（たとえば Python の `random.randrange`）はすでにこのアプローチを実装していること、`random_between` が利用可能だと `random_choice` の構築が簡単になることを指摘しています。
この図は、記事で説明されている modulo バイアスの例を可視化しており、10 のランダム値が 3 つの選択肢に不均等にマッピングされ、選択確率が 40% と 30% になる様子を示しています。
Antithesis で、著者のチームはファズコードを見直し、 ad‑hoc な `random_u64() % n` 呼び出しをすべて、`weighted_choice` ヘルパーに置き換えました。このヘルパーは Blob のサイズ分布（例えば 88 % Small、4 % Medium、4 % Large、4 % XLarge）を駆動します。この変更により、テストカバレッジにおける非決定的バイアスの隠れた原因が排除され、より良い抽象化が導入されるまで新しい `random_u64()` の使用を見合わせるモラトリアムが導き出されました。このエピソードは、見かけ上無害な利便性がランダム化実験を歪め得ること、そして意図を明らかにする上位レベルの API が望ましい理由を示しています。