Regenerative Software

全体のサマリー

本書は、コードの生成コストが下がると、価値は実装そのものから、システムの意図、境界、評価、証拠、来歴へ移ると論じる。実装を交換可能にするには、正しく動作させるための知識を、削除するコードとは別の場所に残す必要がある。

交換可能性を調べる基準として、コンポーネントを削除して再生成できるかを試す「削除テスト」を置く。重要なのはコードの小ささではなく、削除したときに何が壊れ、どう検知できるかという爆発半径が既知で境界づけられていることである。

そのための構造として、意図、コンパイル、評価、来歴、ペース、削除、圧縮というプリミティブを挙げる。最後に、これらを小さく検証可能な段階へ分け、要件をアーキテクチャへコンパイルし、制約付きの合成と段階的な評価を行う再生成パイプラインとして組み立てる。この設計の根底には、確率的なフロントエンドを、決定論的な後段が依拠できるほど安定かつ自己整合的にできるかという、まだ実証されていない賭けがある。

感想メモ

Regenerative Softwareを読んだメモ。 O’ReillyのEarly Preview版を読んだ時点の内容で、関連してThe Generative Stack - The Phoenix Architectureも参照した。 一番面白かったのは、確率的なフロントエンドと決定論的なバックエンドを組み合わせるという、まだ実証されていない賭けの部分。削除テストと爆発半径、来歴・プロベナンスの話も面白かった。

• 確率的なフロントエンドを、決定論的なバックエンドにつなぐ賭け
  • LLMをLLVM的な意味でのフロントエンドとして扱い、その後ろを検証可能で決定論的な段階にする。
  • 今までのコンパイラには確率的なフロントエンドがなかったため、この構成が十分に安定するかはまだ証明されていない。
  • パイプラインの他の部分は既存の信頼できる考え方の再構成に見えるが、ここは本当に新しく、自分たちで証明する必要がある。そこが一番面白い。

つまり、この設計全体の根底にある賭けは、確率的なフロントエンドを、決定論的なバックエンドが依拠できるほど安定かつ自己整合的に構築できるという、たった一つの主張に尽きる。

• 小ささではなく、削除して再生成できるかを見る
  • 「これを削除して金曜日までに再生成できるか」という基準が具体的。
  • 何が壊れるか、どう検知するかが本番でしか分からないなら、アーキテクチャに足りないものがある。
  • PRDやDesign Doc、評価方法、依存関係が実装の外に残っているかを見る問いとして使えそう。

（4つの特性: 境界の明確さ、評価の網羅性、結合の深さ、アーキテクチャの一貫性）

これら4つの特性の根底には、命名に値する単一の量、すなわち「爆発半径」があります。これは、コンポーネントが代替なしで削除された場合に劣化するコンポーネント、動作、データフロー、およびユーザーに見える結果のセットです。

2つの質問を自問してください。これがなくなったら何が壊れるのか、そしてそれをどうやって知るのか。両方の質問に対する正直な答えが「本番環境で判明する」であれば、それはアーキテクチャ上のギャップです。

• 来歴・プロベナンスを実際にどう残し、どう使うかが気になる
  • 生成されたコードやGitの差分だけを見ても、なぜその実装になったのかは残らない。
  • 仕様、アーキテクチャ上の判断、評価結果、生成のきっかけ、人間の判断までつなげて残す必要がある。
  • ドキュメントを維持するコストが生成で下がるなら現実的な選択肢になるが、コミットに残すだけで後から使えるのかはまだ分からない。

来歴とは、コンポーネントの派生履歴を記録するものです。つまり、どのような意図で作成されたのか、どのアーキテクチャにコンパイルされたのか、どのような評価によって検証されたのか、どのような証拠が影響を与えたのか、そしてどのような決定によって変更されたのか、といった情報です。

• 「AIがコードを書く」は本題ではなく、価値がどこへ移るかを見る
  • システム理解、判断、境界、評価、運用上の証拠の方が重要になる、という整理がよかった。
  • これは他でも見かける話だが、削除テストと組み合わさると判断基準として具体的になる。

だからこそ、「AIがコードを書くようになった」という解釈は、ソフトウェアの歴史におけるこの時点の最もつまらない解釈なのです。

• 「アーキテクチャへコンパイルする」は、PRDやrequirementsからDesign Docを作る話として読んだ

  • 通信方法、データ所有、フレームワーク、許可する副作用、評価方法などを制約として強制するところまで含むなら、単なる文書生成より広い。
  • 「アーキテクチャ」という言葉を使う意味と、どの部分が新しいのかはまだ整理しきれていない。

• 評価、削除、圧縮を一つの流れにする

  • integration test、performance test、障害時の評価など、実装から独立した複数の評価方法が必要。
  • 再生成で残骸が増えるなら、古い実装や不要な制約を削除・圧縮する工程も最初から流れに入っている必要がある。

読んでもまだ不明瞭だったところ

考え方は分かったが、読んでも実現方法の具体像まではつかめなかった。

• 境界、データ所有、通信方法、フレームワーク制約、評価面を、実際の生成へどう強制するのか。
• 仕様、生成条件、評価結果、人間の判断をつないだ来歴を、どこへ保存し、次の生成でどう利用するのか。
• 確率的なフロントエンドが、同じ意図を毎回同じ構造へ安定して解決できるのか。