これは、最近のシリーズに対する補足 / サイドクエストのようなものです。メインの記事にきれいに収まらなかったため、独立した記事として公開します。[Why Software Factories Fail](https://x.com/dexhorthy/status/2080697380379427275) のパート 2: [Turning the lights back on](https://x.com/dexhorthy/status/2081058573556306030) で簡単に言及されています。
レバレッジを求めて
AI 登場以前から、機能をリリースするまでの時間のうち、実際にコードを書く時間は 25～50% に過ぎませんでした。残りの時間は、調整 / 計画、コードレビュー / 修正、そしてソリューションのテスト / 検証に費やされていました。
コードを書く部分だけに AI を使っているなら、2～4 時間のコーディング時間を 10～20 分に短縮できても、その他の部分は何も加速できていません。
しかし、計画や調整にも AI を活用すれば、実際に 2～3 倍の高速化を達成できます。
AI コーディングにおけるレバレッジの 80/20 ルール
例えば、あなたが動画ファクトリーに 2 文のプロンプトを適当に入力した場合、完全にマージ可能な結果が得られる確率は約 50%、修正が必要になる確率は 50% だとしましょう。
ここで、あなたが 10 年の経験を持つプリンシパルエンジニアだとします。100 のリポジトリにわたるコードベース全体を頭にダウンロードしています。そこで、半日かけて手動で完璧に詳細な仕様書を書きます。そうすれば、確率は改善されますが、それでも *何か* 重要な部分をやり直さなければならない確率はおそらく 10% 程度は残ります。
そして、極端な例：すべての行を自分で書きます。エージェントが間違える余地は何もないので、修正の確率はゼロになります。
注: この例では、
「何かを変更しなければならない確率」に「変更の痛みの大きさ」を掛け合わせたもの
をひとつのパーセンテージにぼかして説明しますが、明らかにこれらは 2 つの別個の変数です。モデルがボタンのスタイルを間違える確率が 50% でも、修正が 1 回の安価なプロンプトで済むなら、複合的な「期待される痛み」は低くなります。
期待される痛み = P(変更しなければならない確率) × 変更の痛みの大きさ
これを図にすると、事前に費やす労力と期待される痛みの間には逆相関の関係があります。
避けるべきなのは、最初の 10 分で期待される痛みの 80% を排除できたはずのタスクに、6 時間もかけて計画を立てることです。
これを行うには、一段階深く掘り下げなければ答えられない質問に過度に焦点を当てないようにする必要があります。例えば、「プロダクト」レベルである程度の作業を行い、未解決の質問にすべて答えていない場合、現時点での作業を終えて、技術的な詳細レベルにズームダウンし、何が実現可能かを理解する必要があるかもしれません。これに対する完璧なプロセスはありません。
これこそが私たちが レバレッジ と呼ぶものです。そして、それには実用主義であることが求められます。複数のフェーズにわたって計画を立て、50,000 フィートの視点から 10,000 フィートの視点までズームインする場合、各フェーズで少しずつ方向性を調整し、可能な限り多くの期待される痛みを排除する ことを確実にしたいものです。
幸運を祈ります。
