正直、そのセクションの最初の数語を読んだとき、「だからClaudeを使ってHypothesisをRustで書き直したんだ…」って続くと思ってたから、かなり驚きました！

投稿の中で、Hegel/HypothesisとQuickCheckの間にデザインの違いがあることに言及していますが、それはPythonや非HaskellプログラマーとHaskellプログラマーの態度の違いによるものです。Haskellの世界から来た者として（Haskellが完璧な言語だとは思っていませんが）、これらの違いについて詳しく教えてもらえますか？

既存のRustのProptestライブラリの代わりに、これを使う理由は何？

これは質問じゃないけど、Hypothesisに感謝したくて。私は定期的に使ってるんだ。数年前、半形式的に検証されたファンドとアカウント管理サービスを構築しなきゃいけなくて、その正しさを確認するためにHypothesisの状態ベースのテストを使った。こんな小さなフレームワークがどれだけ貴重だったか、言葉では表せないよ。その後、製薬関連の人と話したとき、彼はAntithesisを使って自分の製品を検証しようとしてたんだ。その時、Antithesis（会社）は彼に合わないって言ってた。私は前のアプローチに似た提案をしたけど（Antithesisは含まれてなかった）、彼らが最終的にどうしたのかは全然知らない。でも、HypothesisとAntithesisがついに手を組んだのを見るのは嬉しいね。

実は、PBTが役立つ別の視点があると思うんだけど、それはブログ記事では探求されていなかったんだ。その視点は可読性です。AIが書いた雑なソフトウェアが正しいことをしているかどうか、どうやって確認するの？普通はコードを全部読むよね。残念ながら、それはAIを使わないのとあまり変わらないくらい手間がかかる。でも、包括的なプロパティベースのテストがあれば、ソフトウェアが正しいことをしているかを確認するために、プロパティベースのテストだけを読むことができる。たとえて言うなら、機械でチェックされた証明を見る必要はなくて、主張が正しいことを確認するだけでいい。

でも、問題はテストが本当に意図したことをテストしているかを確認することです。確かに。PBTでこれを偽るのは、例に基づくテストよりもずっと難しいけど、それでも悪いプロパティベースのテストを書くことはできるし、エージェントはそれを得意としています。一般的に、プロパティベースのテストを持つエージェントは、例に基づくテストだけのエージェントよりも自分を騙さないことが多いと感じていますが、それでもClaudeに対して叫ぶ時間はたくさんあります。 > だから「大きな部分」とは言えるかもしれませんが、他にも大きな部分がまだ欠けています。ここには異論はありません。エージェントによるコーディングを解決するとは言っていません。私たちはただ、テストを行う人々をテストしているだけで、エージェントの世界では良いテストツールが特に重要だと思っています。

確かに、テストは重要であり、AIの利用が増えるにつれてさらに重要になると思う。だから、より良いテスト、PBTも含めて、役に立つよね。カリー・ハワード同型性を考えると、PBTを実行する代わりに、HWモデルの仮定のもとでAIにバイナリ実行可能ファイルの特性を直接証明させることはできないかな？PBTを否定するつもりは全くないけど、これならもっと早くて信頼性も高いかもしれないね。

人間が手作業でテストを書くのに何年もかかり、エージェントは収束に失敗した。エージェントが今日失敗していることを、未来でも引き続き失敗するだろうと仮定するのは危険だと思う。つまり、エージェントが1年か2年の間に始めた軌道で改善を続ける楽観的な見方をするなら、彼らのためにどんなツールやインフラが必要になるかを考える価値があるということ。今からその未来に向けて構築を始める企業は、2年後に新しい現実に目覚める人たちよりも、より良い立場にいるだろう。

既存のエコシステムにどうフィットするかの短い答えは…競争かな。これらのライブラリに取り組んでいる人たちにはすごくリスペクトしてるけど、Hypothesisベースのアプローチが他の人たちが採用している様々なアプローチよりも良いと思ってる。最初に使う自然言語が、すでにかなり良いプロパティベースのテストライブラリがあるものだから、ちょっと気が引けるけど、結局それが正しい選択だったと思う。なぜなら、それらは人々が正しいソフトウェアを書くことに関心を持っている言語であり、私たち自身がツールを最も欲しい言語でもあるから！今のところ、もしプロパストを楽しく使っているなら、Hegelに切り替えるべきかどうかは明確じゃないかも。試してみた人の話を聞きたいけど、今の状態では心から「これが正しい選択だ」とは言えないな。最終的にはそうなると思うけど。Hegelのアプローチが明らかに良いと思う点は、以下の通り。もしグリーンフィールドから始めるなら、Hegelを試す価値があるかも。* プロパストよりもずっと良いジェネレーター言語（プロパストの選択は本当に好きじゃない。これは個人的な美的好みもあるけど、明示的に構築されたジェネレーターの方がアプローチとしてうまく機能すると思うし、Hypothesisでも証明されてる）。Hegelには、欲しいデータを生成するための柔軟なツールがたくさんある。* Hegelは、データの有効性要件を常に尊重した素晴らしい縮小を提供してくれる。もし何かが常に真であることを保証するジェネレーターを書いているなら、それは縮小されたデータにも当てはまるべき。これは…プロパストではせいぜい部分的にしか真実じゃない。オリジナルのクイックチェックとその純粋な型ベースの縮小ほどの足元をすくうような問題はないけど、良い結果を出す縮小と、有効なデータを確実に得られる縮小の間で選択を迫られることが多い。* Hegelのテスト再実行は、シード保存よりもずっと良い。失敗したテストを再実行すると、ほぼすぐに同じように失敗する。Hypothesisモデルを使わないアプローチでは、最善の結果はランダムシードを保存して、その失敗例から縮小を再実行することだけど、これはかなり遅い。多分他にも生活の質を向上させる改善点がたくさんあるけど、これらは私がプロパストを使ったときに際立っていた点で、Hypothesisモデルとより古典的なQuickCheck派生のものとの大きな対比でもある。

でも、これはまだ「盲目的な」ファズテストで、コードカバレッジからフィードバックを得るようなものを書けたらいいなと思ってる。これに関しては、単純な試みがあったりするけど、例えば100回テストをする代わりに、カバレッジが増えている限り続けるみたいな感じ。https://arxiv.org/pdf/2203.00652 のChoice Gradient Samplingアルゴリズムは、生成器をもっと繊細に操る方法としていい感じだと思う。その論文では、拒否サンプリングのときに廃棄を避けるために使われているけど、新しいカバレッジに基づいて「報酬」を与えるように再利用できる気がする。

そうだね、#[derive(DefaultGenerator)]とgenerators::default()がここでは正しいツールだよ。ここは私たちがあまり実際に使っていない分野だから、何か問題があればフィードバックをもらえると嬉しい！from_typeはHypothesisの最も強力で使いやすい戦略の一つだと思うし、Rustではそのレベルには達しないかもしれないけど、それでもかなり素晴らしいものが得られると思う。

うん、cargo testがuvみたいな別のバイナリを必要とするのはイディオムじゃないよね。99%の確率で、Rustプロジェクトに近づいてcargo testを実行すれば、そのまま動くはずなんだ。

[免責事項: Antithesisを始めました] HegelのテストをAntithesisで実行すると、これが無料でもらえるよ（さまざまな「非ローカル」アサーションや、並行または分散コードでも完璧な再現性なども含めて）。でも、Antithesisの外で基本的なカバレッジガイダンスをハックするのは難しくないよ。それは大きなクラスのプログラムにはうまく機能するけど、大多数には合わないね。