PR コントラクトは、プルリクエストの作成者がそれをレビューする人に対して何を負うのかを示す短いフレームワークであり、AI はコードを速く書く。それが動くことを証明するのは依然としてあなたの仕事だ。 で示された。項目は 4 つある。what/why は変更の意図を 1〜2 文で述べるもの、proof it works（機能することの証明） はテストが通ったこと、およびスクリーンショットやログといった手動での手順を示すもの、risk and AI role（リスクと AI の役割） はリスクの段階と、変更のうち AI が生成した部分を明示するもの、review focus（レビューの焦点） は人間の意見を特に求める 1〜2 の領域を示すものである。
Osmani はこれをプロセス上のオーバーヘッドとしてではなく、レビュアーの時間への敬意として、また作成者の説明責任を強いる仕組みとして提示しており、その判定基準を率直に述べている。このコントラクトを埋められない作成者は、自分の変更を他人に承認してもらうよう求められるほどには理解していない、というのである。
用法
このコントラクトは、同じ記事が AI のスピード下でのレビューについて説明する分業のうち、作成者側の半分にあたる。これに付随する原則は次のとおりである。約束ではなく証明を求めること（新しいテストか変更が動作するデモのいずれかがないプルリクエストは出さず、AI エージェントにはコード生成後にコードを実行したりユニットテストを走らせたりするよう指示すべきである）。AI のレビュー出力を助言として扱うこと（最終的な裁定者ではなく一次レビュアーであり、編集者ではなくスペルチェッカーだと説明されている）。人間のレビューを、セキュリティ上の穴、既存コードの重複、アプローチの保守性といった AI が見落とすものに向けること。明確なメッセージを伴う小さなコミットによるインクリメンタルな開発を徹底し、自分が説明できないコードは決してコミットしないこと。そして、AI を使ってエッジケースのテストを下書きしながら、高いテスト基準を維持することである。
これらは、記事のより広い捉え方の中に位置づけられている。すなわち、AI はボトルネックをコードを書くことから、それが機能することを証明することへと移したのであり、機能することの証拠を伴わないプルリクエストは速く出荷されるのではなく、作業を下流に移すだけだ、という捉え方である。
適用される場面
このコントラクトは、作成者以外の人間がその作業をレビューする変更を想定して書かれており、添付できるテストや再現可能な手動のデモがあること、そしてそれらがない場合に承認を保留する権限を持つ人がいることの両方を前提としている。開発者が 1 人で作業していてもチームで作業していても適用されるものとして提示されているが、なぜ 必要なのかについての記事の説明は両者で異なる。1 人の開発者は自分自身の速度に対抗するためにこれを使い、チームは AI がレビューキューに加える量に対抗するためにこれを使う。述べられている失敗モードは作成者側にある。4 つの項目を埋められない作成者は、自分の変更を他人に承認してもらうよう求められるほどには理解していない、というものである。
どの程度確立しているかについて言えば、記事はこれを、最も成功しているチームが収束してきたフレームワークであり、台頭しつつあるベストプラクティスだと説明しているが、研究に裏づけられたものではなく 1 人の実践者の記事で提示されたものであり、4 つの項目の文言もその記事独自のものである。