いいね！あなたの仕様を最大限に活用する姿勢、すごく共感できる。私は明確な要件を扱ってきたけど、会話から引き出したり、別のソフトウェアを内省したりしている。ワンショットでそれを得て、"おじいちゃんがクロードに怒鳴る" みたいな反復作業をしながら、常に最新の状態に保ってる。あなたとは違って、LLMにできるだけ多くの作業をしてほしいと思ってるけど、「可能な限り」というのはその文の中でかなりの作業を意味してる。自分がどこで必要とされているのか、Opusや反復作業が最終的にどうなるのかを明確にするのに苦労してる。要件と制約の違いを明確にすることが本当に挑戦的だった（例えば、「データベーススキーマを再発明することはできない、大きなシステムの一部を構築しているから」）。UIの挙動をいつ、どのように指定するかについてもまだ悩んでる。UIの多くは暗黙的で、動作させるためにたくさん指定しなきゃいけないのはかなり大変に感じる。Flutterや他のUIツールキットのために間違いなく膨大なテストを書いた人には新たな敬意を表します。

これとJiraの違いは何？あなたの仕様はすでにどこかに存在してるよ、それを定義した場所だから。だから、何かが壊れたときに仕様を参照できるように、コードやコミットにJiraチケット番号を入れるのがいいんだよね。

最近、エージェント生成のコードには人間が書いたコードのような「組織的記憶」が欠けているって似たようなことを書いたんだ。決定がなぜなされたのかを聞ける人がいないからね。「スペックマキシング」ってのがこの問題に対する正しいアプローチだと思う。著者の記憶に頼れないなら、意図をどこかにしっかり残さないといけない。AI生成コードの道を進むなら、スペックがデフォルトで真実の源になるよ。

いつもスペックが何を言っているか気にする、それは決して変わらない 何か見逃した？それともみんな1970年代に戻って、ウォーターフォールプロセスで働いてるの？

この仕様の伝統的な名前は「ソースコード」だよ。システムの動作に関する真実の基準で、人間が読めるようにできる限りのものなんだけど、自動化ツールによってコンピュータが実行するためのあまり読めない派生物に処理されるんだ。コンパイルされたアーティファクトをソースコードをチェックせずにコードベースにチェックインするのは、常にリスキーな行動だよね！

自分も似たようなことに行き着いたよ。C++の作業には、2〜3つの仕様書を使ってるんだ。ファームウェアマニュアル（機能やインターフェースを説明）、実装計画（実装の順序、指定されたメカニズム - 新機能はここに入る）、プロダクトマニュアル（ユーザーストーリー、外部効果）。ユーザーストーリーから始めて、実装計画を作り、コードを書いて、ファームウェアマニュアルを書いて、3つのドキュメントとコードの整合性をチェックする。整合した統一された真実を反映するために、コードかドキュメントのどちらかを変更する（実装計画は徐々に実際のものになっていく）。コードには詳しいコメントを付けて、誤解されにくくしてる。「正確で、一貫性があり、整合性があり、コメントがある」このプロセスを機能ごとに繰り返して、時々元のプロダクトマニュアルに戻ってズレを特定する。元のドキュメントがドラフトされたら、エージェントにプレースホルダーファイルを書かせて、必要になるインターフェースを定義させる（後でたくさん追加することになるけど、それは大丈夫）。すべてのファイルは明確な関心の分離を反映し、定義されたインターフェースを通じてのみアクセスできるようにして、他はプライベートにする。手作業よりも多くの個別ファイルができるけど、ファイルの粒度で範囲を制限し、ファイルごとに不変のインターフェースを定義することで、メンテナンスしにくいコードを生むショートカットを避けてる。新しいコンテキストを開くときは、プロジェクトのロゴや理念を簡単に説明するオンボーディングプロセスを設けて、エージェントがプロジェクトの成功に深く投資すべき理由を説明するし、エージェントが特に気をつけているポイントや好みを書いたlearnings.mdも作成する。言うまでもなく、1ミリオンコンテキストを使ってて、トークンが火の海だけど、結果はしっかりしてて、生産性は5〜10倍だよ。

結局、ソースコードが何かに集約されるんだよね。「仕様」と呼ばれる最も一般的な形は、作業チケットの受け入れ基準で、これは加算的な仕様、つまり望ましい変更の説明なんだよね。「既存のものを考慮して、次のように変更してください」って感じ。つまり、製品が始まって以来作成されたすべてのチケットを重ねて要約したら、それが「仕様」になるんだ。でも、それを要約しているのは開発者たちで、各仕様の追加と既存のコードベースの現実を理解しながらやってるんだよね。だから、今の人たちが「仕様」と呼んでいるものと、コードがすでにやっていることとの間のギャップは大きくないし、これからも大きくはならないと思う。ただ、実質的に別の（準）コンパイルステップを追加しているから、今回は非決定的なものになってるんだ。

あなたはソフトウェアアナリストの仕事を再発見したね。90年代初頭までは存在してたんだけど、その後はプロダクトオーナー、プロジェクトマネージャー、開発者/DevOpsのミックスになっちゃった。でも、アナリストは別のスキルセットだってことを無視してると思う。

仕様を書くだけじゃなくて、他の人の仕様を共有したり使ったりもできるよ。それがspeX.buildが作られた理由で、バージョン管理された仕様のハブになって、みんなが自分の実装を好きな言語やスタイル、詳細で作れるようにするためなんだ。

会話を記録するだけでいいんじゃない？必要なことが全部含まれてるし。初期の大まかなスコーピング、xをやろうとしてyをやらなかった失敗、特定のコード行が特定のエッジケースをどう解決するか、などなど。レビューの時間が来たら、コードと会話の両方を見直せばいい。200件の「ユーザーが書いたメッセージで、なぜ、何を？」って？それは良いPRだね。15件の「はい、うん、オッケー、なんでもいいよ」？それはPRにもう少し愛情を注ぎたくなるかも。コミットするとき、記録しないことでやった作業の半分、いや大部分を捨ててる気がする。