PDD Kitはagent製コードのreviewを行単位から仕様へ移す

Microsoft ResearchとGitHub Nextは、開発者の意図をVerus仕様へ変換し、Rustコードの証明を機械的に検査するプロトタイプを公開した。強い保証が及ぶのは、明示された信頼境界の内側だけだ。

約5,000行のRustアプリで仕組みを試した

PDD KitはChopin内で動く。開発者へ質問し、回答から読みやすい意図の地図と形式仕様を作り、agentにコードと証明を書かせる。証明の成否は別のモデルではなく、VerusとZ3が決定論的に判定する。

チームは約5,000行のRustでできたPet Storeを使い、loginとアカウントや役割の関係を検証した。2文の依頼は主要なlogin flowに対する8条件になった。検査時間は小さなmoduleで秒、大きなコードで分単位だという。

人は生成コードの全行ではなく契約を読む

開発者は意図、曖昧な解釈、形式仕様を承認する。agentが実装と証明を書く一方、VerusがbuildとCIで妥当性を判断する。

PDD Kitは仕様の各条件に対して意図的なバグも入れる。verifierが拒否できなければ条件が弱いため、修正へ戻す。大量のagent製コードに対するreviewの場所を変える発想だ。

証明はデータベースと暗号と時計の手前で止まる

アプリ全体を形式検証済みと呼ぶのは正確ではない。Verusは現在Rustだけを対象とし、例ではbcrypt、SQL、token署名、システム時計の内部を検査しない。開発者は6個の信頼部分を承認し、そこは証明ではなくtestで支える。保証は仕様の正しさにも依存する。

PDD Kitはresearch prototypeである。1つのアプリのloginを扱った実演であり、大規模製品で証明を保守する長期費用は測っていない。

別のRustプロジェクトが保証の費用を示す

今後は、別チームが速い変更の中で仕様を保守できるか、信頼境界を小さく保てるかが焦点になる。Chopin外での提供と他言語対応も重要だ。

最初の対象にはlogin、権限、決済のように失敗が高くつく狭い領域が向く。開発者がverifierへの説明だけに追われずregressionを減らせれば、このreview方式には価値がある。

Lilithの判定

agentは閉じた扉の向こうで100,000行を書ける。PDD Kitは先に人へ契約を読ませ、その契約を破るコードをverifierに止めさせる。