#ソフトウェア設計

いちばん面白かったのは、Warp が改善を「モデルの頭の中」や「雑なメモ」に寄せず、ちゃんと PR と review の流れに乗る形へ落としている点だった。AI の出力が少しずつ良くなる、という話自体はよく聞くけれど、実際にそれを“人間が普段やっている開発の回路”の中に埋め込むと、こんなに筋が通るのかと思った。 特に引っかかったのは、フィードバックが session の終わりと一緒に消えてしまう、という指摘だ。これは地味だけれどかなり本質的だと思う。普通のチャットだと、良い指摘があっても次回に自然には引き継がれない。そこで skills という file-based な単位に知識を残し、改善担当の agent が後からそれを読んで小さく直す。つまり「覚えておく」のではなく、「直すべき文書を直す」。この考え方は、AI を魔法っぽく扱わず、むしろソフトウェアの変更管理に寄せている感じがして好感があった。 もう一つ、地味に効いていると思ったのは「rules ではなく principles を書け」という話。AI に細かい禁止事項を並べるより、なぜそうするのかまで含めて書くほうが、たしかに汎用

まず思ったのは、PRD（Product Requirements Document）を捨てたこと自体より、その代わりに「eval suite」を置いたという発想のほうがずっと象徴的だ、ということだった。PRDは人間向けの説明書だけれど、eval suite はモデルや機能を実際に測るためのものだ。AI の会社では、きれいに要件を書き下ろすより、まずどう動くかを定義して測れる形にするほうが、たしかに筋がいいのかもしれない。 ここで面白いのは、これは単なるドキュメント文化の話ではない点だと思う。Anthropic が coding を戦略的優先事項にした、という話も同じ文脈にある。AI のプロダクトは、見た目の機能一覧よりも、どの場面でどれだけ役に立つかが本体になる。そうなると、PRDで「こういう機能を作ります」と書くより、評価用の問題を並べて、期待値を継続的に確かめるほうが、現実に近い。人間の会議で合意したつもりでも、モデルは平気で外してくるからだ。 ただ、少し引っかかるのは、これがすべてのチームにそのまま当てはまる話ではないことだ。eval は強いが、何を測るかを決めるのがそもそも難し