AIで機能追加が高速化——だからといってもう一つ追加するべきなのか？

AIコーディングツールの進歩により、新機能の追加にかかる時間は劇的に減少した。かつて週末を要した機能が午後で済み、午後かかっていたものが1時間で完了する。これは一見良いニュースだが、著者はこれがスコープクリープという落とし穴を生むと指摘する。

各機能の単位時間コストが数日から数時間に下がると、開発者は「あと数時間だけ」と簡単に追加機能を検討するようになる。しかし、こうした「合理的」な小さな決定が積み重なり、プロジェクトは本来の目的から逸れていく。著者は自身の製品grithを例に、当初のMVPはLinux向けの2文で説明できるものだった（CLIエージェントのシステムコールをインターセプトし、多段フィルターパイプラインを通して、許可、拒否、またはレビュー待ちを返す）が、現在の製品にはライブセッション追跡、散布図、円グラフ、ダイジェストレビューフローを備えたダッシュボード、ベイズ更新による適応型レピュテーションシステム、長時間実行デーモン、通知チャンネル、プロファイルエディタ、リモートプロファイルオーバーレイ配布など、本来の範囲を超えた機能が多数含まれていると述べる。

ただし、すべての追加機能が不必要というわけではない。著者は追加機能を2つのカテゴリに分類する。第一のカテゴリはセキュリティモデルが要求する基本機能であり、ハッシュチェーンの完全性、AES-256-GCM暗号化、秘密スキャンパターン、機密パスヒューリスティック、エントロピーチェック付き出力フィルターなどが含まれる。これらは製品のコア競争力に不可欠な基本能力であり、「機能」というよりは当然の要件である。第二のカテゴリは真のスコープ拡大であり、複雑なダッシュボードや適応型システムなどが該当する。問題は、AIが後者の実装を加速させ、開発者が断りにくくなることだ。

この課題に対処するため、著者はいくつかの規律を提案する。まず計画を散文で書き、なぜそれを行うのか、制約は何か、代替案は何か、なぜこれが勝つのかを説明する。発売パスを明確に定義する。grithの場合、「監督下のClaude Codeセッション、本物のフィルターパイプライン、本物のダイジェスト、Linuxのみ」である。AIに異なるセッションで議論させる。つまり、計画を立てるセッション、計画を批評するセッション、実装するセッションを分ける。同時進行の機能数を制限する。「第二階の計画」——計画についての計画——に警戒する。著者は、これらの方法は新しいものではないが、AI時代では「時間予算」の制約がなくなったため、より積極的かつ頻繁に適用する必要があると強調する。

最終的に、grithのv1はLinuxのみでリリースされる。著者は、製品が第一のカテゴリの機能によって強くなった一方で、第二のカテゴリが遅延を引き起こしたと振り返る。真の教訓は「作る量を減らす」ことではなく、「第二のカテゴリの作る量を減らし、第一のカテゴリを謝らない」ことである。