AI-Native Software Engineering

感想メモ

AI-Native全体というよりは、SDD workflowの話が中心だったかなーと思う。やり方にちょっと寄った感じ。ハイライトも第5〜7章に偏っていて、この章あたりは関連する話が多かったかも。

Two-Tier Model（building blockみたいな全体に共通の部分はliveなdoc、機能の仕様的なものはsnapshotで更新しないに近い話）とか、Brownfield Projectsではスペックアイランド戦略になるとか、まあそうだよねーって感じではあった。

意図と制約

意図と制約の切り分けは良かった。

曖昧な意図は曖昧なコードを生み出す。

弱い意図（「ユーザープロフィールページを追加する」）だと、モデルが学習データの仮定で勝手に埋めてしまう。強い意図はコードを書く前に自由度を削っておく、という話。制約のほうも技術・ビジネス・品質で分けていて、エージェントが知らない制約に違反するのが一番よくある失敗だと言っている。

コンテキストエンジニアリング

prompt engineering から context engineering への話は、個人からチームというか組織の課題を扱うように変化していったという感じでそうだなーと思った。

迅速なエンジニアリングは局所的な最適化です。 相互作用。コンテキストエンジニアリングはシステム分野です。 モデルがセッション全体にわたって、そしてすべてのセッションにわたって認識する完全な状態 チームがプロジェクトのライフサイクル全体にわたって実行するセッション。 モデルを悪用したり、その制限を回避する方法を見つけたりしています。 モデルが適切に推論するために必要なものを与える。

問いが「指示を書き直すか」から「モデルに必要なものは揃っていたか」に変わる。ルールファイルやMCP設定が残る資産で、その上のアシスタントは交換可能（ハーネス）という話とセットで読むと、扱う単位が個人の手癖からチームの共有物に移ってる感じがする。

Human-in-the-Loop（HITL）

レビューを成果物境界に置く、という話。

レビューポイントはどこに挿入すればいいのでしょうか？実際的な答えは アーティファクト境界 でのレビュー 。本書では、 アーティファクト とは、 エージェントが途中で生成する、具体的で人間が理解できる出力：計画 ドキュメント、コード差分、テストレポート、および生成された設定ファイル。 エージェントが何か成果物を生み出すたびに、それはレビューの機会となる。

これは PRD -> Design Doc -> Implement -> Test -> Deploy みたいなそれぞれの境界でチェックするという判断になるかなーと思った。

エージェント側が人間を必要とする瞬間に呼ぶ、というパターンについては、未知の部分を勝手には埋めずに、Designに必要な項目ごとに「埋まっている／空いている／矛盾している」と「誰に何を聞くか」を扱うという話なのかなーと思った。

SDDの成熟度レベル

spec-first / spec-anchored / spec-as-source のレベル分けは面白かった。

spec-as-source は今はまだ無理、と著者が自分で認めているのは良かった。

核心的な批判は、正しいものを生成するのに十分な精度を持つ非公式な仕様であるということだ。 反復処理のない実装は形式的なものに似てくる 仕様書には、それ自体に周知の導入上の問題点が存在する。 そのレベルの精度で仕様書を書くと、 コード自体を書くことは、生産性の議論を損なう。 アプローチ。今のところ、spec-as-source は、 方向性を示すものですが、今日から採用すべき実践方法ではありません。

ブラウンフィールド

Brownfield Projectsではスペックアイランド戦略という話は、それはそうだなーと思った。全部を遡及的に仕様化せず、これから変えるところだけ変更前に仕様化する。

知識負債（technical debt ではなく knowledge debt）という言い方は良かった。

技術チームが時々直面する組織的な側面もあります 過小評価している。未指定のブラウンフィールドコードの問題点は、 技術的負債、つまり 知識負債 。 アーキテクチャ上の決定、エッジケースの処理、および動作上の制約 それらは、それらを建造した技術者の記憶の中にのみ存在する。 それらのエンジニアは退職するか、組織の別の部署に異動する。 その論理は彼らと共にある。コードは残るが、意図は 消える。

優先順位の付け方も納得感がある。バグの多さじゃなくて、その論理を知ってる人が何人残ってるかで測る、というところ。

ブラウンフィールドSDDを知識回復プロジェクトとして扱うことは プロセス導入プロジェクトが優先順位の付け方を変えるのと同様に、 最もリスクの高いモジュールは、バグが最も多いモジュールではなく、 その論理的思考は、ごく少数の残存者に集中している。

全体のサマリー

本の内容としては、AIに実装を任せる書き方が本番で何に突き当たるのか、そこからエンジニアの仕事の重心がどこへ移るのかを追っている。

• ざっくり指示して任せるやり方はプロトタイプにはよく効くが、本番だと、動いているように見えて実は違うコードや、その場しのぎが積み重なって崩れた構造が出てくる
• エージェントは人間と違って聞き返さないし、書くのが速い。だから曖昧なまま渡すと、間違った前提のまま一気に広がる
• なので作る前に「何を作るか」「守るべき制約」「完了の条件」を書いておく。それをどこまで維持するかで spec-first / spec-anchored / spec-as-source の3段階に分かれる
• 既存のコードだと、意図が人の頭にしか残っていないのが一番の壁になる。全部を後から仕様化するのではなく、これから触るところだけ先に仕様にする
• 人が見るポイントは、計画・コード・テスト結果みたいな成果物が出たタイミングに置く