この投稿の内容は、あなたがすでに何をしているのか知っているという前提から来ていると思うけど、過去に作ったものに関してはそれが当てはまるかもね。でも、全く分からないものを仕様化するのは無理だし、問題の範囲を探る前にテストを書くなんてありえないよね。それは完全に不合理だと思う。次に言いたいのは、このアプローチはAIファーストの開発には根本的に間違っているってこと。コードを書くコストがほぼゼロに近づいているなら、一発で完璧なシステムを作るためにリソースを投資する意味はないよ。もっと大事なのは、どれだけ早く境界を探れるかってこと。今なら、5つのエージェントを立ち上げて、作っているものの5つの異なるバージョンを実装して、ベストなものを選べるんだ。うちのチームでは、常に何百ものエージェントがいろんな問題に取り組んでる。大半のコードは捨てられるけど、合格した部分だけをマージするんだ。

ちょっとしたランダムな（役に立つことを願って）考えなんだけど、多くの企業には古いコードベースやデータベースがあって、ある程度は定義されているけど、そうでない部分もあるよね。35年かけて少しずつ進化してきたものには、ドキュメント化されていないエッジケースがたくさんあるかもしれない。だから、エッジケースカタログの前に、入力と出力の動作をカタログ化するための何らかのプロンプトを設けるステップがあった方がいいかも。そしたら、異なる入力と出力を見つけて、Input AとOutput Aで期待通りに動作するか確認できるし。（レガシーシステムには、誰も覚えていないような奇妙なオーケストレーションがあることが多い。）小さなメモとして、個人的にはここで述べられている以上にコードコメントを充実させるのがいいと思ってる。仕様自体はコードに織り込まれるべきで、各要素について少し過剰にコメントを入れるくらいがちょうどいい。コード自体がコンテキストとして機能するべきだし、特にTDDの段階ではね。暗黙のうちに言ってるけど、フェーズ3のコード品質チェックでは、ゼロトラストベースでチェックすることも明記しておくべきだと思うし、ハードコーディングされたキーみたいなものは含めないように。Chainlinkが何かはよくわからないけど（ごめん！）、分解に関するアイデアは好きなんだ。ただ、ここで述べられているように、すべてをエンドツーエンドで繋げるのを欠いている気がする。（各部分を作成するように求めているけど、実際には全体を織り合わせていない。）カバーされていないこととして、作業のシーケンスや分解があるよね。仕様は内部で複数の依存関係を生むことができて、特定の順序で作業を進める必要があるんだ。

LLMを使った開発は、トレンド駆動の開発に似ている気がする。技術や異なるプロンプト、目標に対処する際に、特定の技術に対してギャンブラーの誤謬に陥りやすいよね。仕様駆動の開発は、私にはちょっと疑わしい。予測可能な機能作業や以前に行ったことがある場合にはうまくいくと思うけど、じゃあなんでそれに時間を無駄にするの？LLMが登場する前は、動作するものに向けて急速に反復するのが全体の雰囲気だったし、何がうまくいくか、何がうまくいかないかを見られるようにしていた。コードを書くコストが明らかに安くなっているのに、なんでその戦略を業界全体で放棄するの？もし私がLLMを使うとしたら、過去のアートやアイデアの幅広い検索をするために使って、その後はプロトタイプのオニオンを作るような感じで、新しい問題に対してクリーンルームでの試行を重ねて、各試行で学んだことを次のプロンプトに蓄積していくよ。通常、そのプロトタイプを取って、最終バージョンを自分で書くから、アイデアをしっかりと内面化できるんだ。結局、このプロンプト作業は先延ばしのように感じることが多い。これらのツールがどこで役立つか、どこで役立たないかを理解することではなく、作業のすべての側面を消費させようとすることに焦点を当てている気がする。

もし「プログラミングを解決する」戦略を思いついたら、それには必ず欠陥があることが確実で、どこで妥協しなければならないかを特定する必要がある。コンピュータサイエンスは内省的な学問で、問題を解決するためのプロセスに関係なく、問題の本質的な難しさを研究するから、プログラミング自体（正確な、または十分に正確なプログラムを生成する問題）は、研究されてきた問題なんだ。プログラムXがある正しさの特性Pを満たすかどうかを学ぶ問題はモデルチェック問題として知られていて、それを確実に答えることは難しい。例えば、あるプログラムに対して真である特性は、検証に10分以上かかることがあるし（検証がどのように行われるかに関係なく）、他の特性は10時間、10ヶ月、10年かかることもある。事前にその特性が真かどうか、そして真であればそのスペクトルのどこに位置するかは分からない。だから、ある特性を完全に証明しなければならないと決めた場合、検証を待つのをどれくらい待つべきか、そして待つのをやめたらどうするかが問題になる。もし100%の確信がないことを受け入れるなら、どのアプローチを取るべきで、実際にどれくらいの確信を持っているのか？その問題は、その質問の答えが実装の深い理解を必要とすることが多いから難しい。つまり、もしXとYという2つのプログラムが同じ関数を計算する場合、1つのプログラムに対して99%の確信を持つアプローチがあっても、もう1つには10%の確信しか持てないことがあるんだ。

私は、15年間憧れてきたソフトウェアエンジニアのように振る舞うLLMから、最高の結果を得ているよ。普通の開発のこと。チケットをしっかりスコープして、分解する。テストをきちんとする。正しいドキュメントを書く。LLM特有のことは来週には消えるだろうね。

私の勘違いでなければ、ここでの検証は問題があるね。遅すぎるタイミングで行われている。単一のテストを満たすコードは、仕様に従う可能性が低い。さらに悪いことに、全体の仕様は完全に実装されないと正しく実現できない。1つの制約を満たしていくことで反復的に作業することはできない。テストケースにも同じことが言える。つまり、最後のテストを満たしたり、最後の制約をクリアするのは、最初のものよりもずっと多くの作業が必要になるってこと。通過したテストの数は、実装の完了を測る良い指標じゃないよ。

私はもっとカジュアルなことをやっているよ。Riaan Zoetmulderの深層学習と医療画像分析の無料コースを見つけて、仕様駆動開発に関する彼の記事も見つけたんだ。彼は、要件、システム設計、アーキテクチャの3つを最初に指定することでVモデルを適応させている。残りは生成されるんだ。彼は、LLMの支援が大規模なコードベースで経験豊富なオープンソース開発者を遅くさせたという研究を紹介していた。モデルは暗黙のコンテキストを知らないからね。それが私にとってのポイントなんだ！LLMには何らかのインデックスが必要だと思う。だから、自分の関数呼び出しを追跡する静的解析プログラムを作ったんだ。それは、自分で定義した関数のコールグラフを出力して、呼び出しているものの名前（とPythonの型ヒント）を表示する（標準ライブラリの関数は除外して、自分で定義したものだけ）。そのプログラムを実行して、時々差分を送るのがかなり役立っているみたい。

短いまとめ：TDDをBDDに置き換えて、DDDをスパイスとして加えるといいかも。そうでなければ、これはかなり良い記事だね。なんでTDDじゃないかって？今、多くの開発者がLLMを使ってテストを作成しているし、トレーニングデータの多くにはその方法が含まれているから。LLMが自分でやり方を見つけるか、ズルをするかのどちらかになる。どちらも良くない。少し物議を醸す意見としては、LLMが自分で生成できるテストを書くのは避けるべきだということ。先週、agents.mdファイルを削除したのと似ているね。

これをrlm-workflowで実装したバージョンがあるよ: https://skills.sh/doubleuuser/rlm-workflow/rlm-workflow

ここでのアイデアのいくつかは、私のTDDフレームワークであるCodeLeashにもっとシンプルにまとめられてるよ（https://codeleash.dev）。大きな違いは、CodeLeashはモデルの外にガードレールを設けているところ。Claude Codeのフックとしてね。忘れたりステップを飛ばしたりすることができないから、プロセスを強制的に通過させるんだ。バイパスもあるけど、それを使うとモデルが再確認する必要があるアラームが鳴る。モデルの外にガードレールを設けることで、決定論的なプロセスの遵守が強制される。十分に能力のあるプロセス（TDDはソフトウェアを構築する強力な方法だよ）を使えば、コーディングエージェントの利用を本当にスケールアップできるんだ。