明るい部屋にいるの？今、夜だから、あなたのコメントはこんな感じで見えるよ：https://i.imgur.com/c7fmBns.png。でも、昼間の明るい部屋では、明るいテーマや背景色で全部見えるから、そうじゃないと本当に見づらいよね。

同じだよ、私もずっとそうだった。いつも文句言ってる。黒地に白文字の方が、白地に黒文字よりもずっと読みやすくて目にも優しいってよく言われてるのに、開発者たちの中にはみんなにそれを強要する世代がいるみたい。NetflixやPrimeみたいなメディアサイトもそうだし。少なくともTubiはちょっと読みやすいかな。時々、サイトにライトテーマを選ぶボタンやUI要素があるけど、技術的に優れた人たちがデザインしたと思われる多くのサイトが、アクセシビリティの問題を完全に無視してるのが不思議だよ。

その気持ちわかるよ。私の場合は逆で、明るい背景だと頭痛がするんだ。光に敏感だからね。

うん、私も同じだよ。ダークモードが最近すごく人気だから、少数派だね。目が物理的に痛いっていうのを説明するのが本当に難しい。変な感じだよね。

私のプロセスは、似たようなものに自然に進化してきたけど、あまり厳密には定義されてないかな。 - AGENTS.mdを自分の基本的な作業方法で立ち上げて、時々プロジェクト特有のものを一つ二つ追加する。 - それからDESIGN.mdを書く。どれだけ詳細かはプロジェクトによって異なるけど、先日、フリーランスのビジネス用に時間追跡、請求管理、会計システムのための非常に詳細なDESIGN.mdを書いたんだ。かなり完成度が高かったから、エージェントがほぼ一発で全部やってくれた。 - さらに、何らかのTECHNICAL-SPEC.mdも書くことが多い。これも詳細はプロジェクトによる。 - 最後に、AGENTSからその二つにリンクを貼る。エージェントには、ドキュメントを維持して、新しい決定と同期させるように指示することが多い。このシステムは私にはうまく機能してるけど、まだまだアドホックで、正式に定義された仕様基準には従ってないと思う。実際、そうあるべきじゃないと思う。私の意見では、技術的に厳密な仕様は設計ドキュメントではなく、自動化されたテストに入れるべきだよ。

あなたの反論はポイントを外してると思う。私のプログラムに対する非公式な仕様はユーザー中心なんだ。プログラムが使用者にどんな利益をもたらすかを示したいし、輸送層の要件やユーザーインタラクションの哲学、その他いろいろなことが含まれるかもしれない。プログラムから何を得たいかが分かっているときは、それをデータベーススキーマやメニューオプション、特定の暗号化スキームなどに翻訳する苦痛を経て、最終的にはアンダースコアやダッシュをどこで使うかが文書全体で一貫性を持たなければならない正式な仕様に変換する。あなたは、LLMがルーチン部分（プログラムの説明を正式な説明に変換する）をやるために、私が苦痛を伴う部分をやるべきだと言っている。あなたが「意味がない」と言っていることは、まさに私がLLMにやってほしいことなんだ。私は同じ仕様を再実行して、LLMが私が全く予想していなかった機能を追加したり（前回の同じ仕様から実行したときにはなかった機能）、技術の変化や新しい標準/ベンダーの利用可能性に基づいてユーザーの目標を達成するための戦略を変更するのを見たい。私は、プログラムの特定の機能を説明することから離れて、存在しないプログラムの有用性や便利さを説明する仕様を見たい。私は、LLMにプログラムが達成すべき要件を与えて、どうやって実現するかを調査させたい。制約だけを説明したい、つまり、A、B、Cができるようにしなければならないし、X、Y、Zを防がなければならない。私は、それらの制約を自分の好きなように解決してほしいし、出力に満足できなかったら、さらに制約を与えて再生成をお願いしたい。

モデルは決定論的じゃないんだよね。再適用しようとすると、毎回違う出力が出る可能性が高いし（今のコードを再適用に入れずに、ただ変更を提案させるだけだと）。結果が常に証明可能に正しいなら、コードレベルで違ってても関係ないんだ。こういうシステムに興味がある人たちは、コード自体よりも、コードが何をするかの結果の方が無限に重要だと思ってる。

モデルは決定論的じゃないって、本当にそうなの？ 数年前に最初のLlamaモデルが出た時から自分で推論を試してないけど、確か決定論的だったと思う。シードを固定して、入力が同じなら、推論の出力はいつも全く同じだったから。

モデルは決定論的じゃない - 再適用しようとすると、毎回違う出力が出る可能性が高いってことは、2人の異なるプログラマーに同じ仕様を渡すようなもんだね。

あなたの2ステッププロセスは、上で挙げたのと全く同じ落とし穴にハマらないってどういうこと？

もし求めているのが決定論なら、その解決策はそれを提供していないよ。形式的な仕様も、そこから生成されるコードも、毎回違うからね。形式的な仕様は簡潔な時に役立つけど、それはコードよりも高い抽象レベルで指定されている時だけ。そうじゃないと、いろんな実装が可能になっちゃう。

もしかしたら、非決定論的なアプリケーションにも入っていくかもね。もう機械的で予測可能なものじゃなくて、90%は普通で、あとは変わった感じ。ちょっと皮肉だけど、これが流行る可能性もあるかもね。

前に言ったことを再度言うけど、私はKiro IDE（≠ Kiro CLI）を主に仕様生成器として使ってる。私の経験では、仕様を作成・反復するのに高品質なんだ。Cursorのようなツールは人間主導の雰囲気に最適化されていて、オートコンプリートが素晴らしい。対照的にKiroは仕様に最適化されていて、皮肉なことに、エージェントを駆動するのに最も効果的なアプローチだと思う。CursorやAntigravityのようなツールは人間の操縦に最適化されていて、その人気の理由だろうけど、Kiroはエージェントのハーネスに最適化されてる。だからこそあまり使われてないんだよね。意見が強いけど、すごく効果的なんだ。バイブコーディング文化は仕様駆動開発に賛同してない（彼らはそれをウォーターフォールだと思って軽視してるし、Yeggeもこの偏見がある）、だから人々はそれを過小評価しがち。KiroはEARSやINCOSEのような構造化フォーマットを使って仕様を書く（これはボーイングなどでエンジニアリング要件に使われるspcフォーマット）。一貫性をチェックするために自動推論を行い、仕様から設計文書とタスクリストを生成するんだ。Beadsと似たような感じ。実装する前に仕様を圧力テストするのにかなりの時間をかけることが多い（時には数時間から数日）、でもそれが効果をもたらす。良い一貫した仕様を書くことは、実際には「思考の道具としての執筆」のコンピュータ版みたいなもの。仕様がしっかりしてれば、実装もそれに沿って進むことが多い。KiroはPythonでHypothesisを使ってプロパティベースのテスト（PBT）も生成するんだけど、これはHaskellのQuickCheckに触発されたもの。これらのテストは入力ドメインをスイープして、従来のシナリオベースのユニットテストと組み合わせることで、仕様に密接に従ったコードを生み出すことが多い。私は「赤/緑TDDをやれ」っていう小さな指示も追加するんだけど（これはSimon Willisonから学んだ）、その一行だけで全てのテストの質が向上した。Kiroは技術的にはタスクリスト自体を実装できるけど、ここでエージェントが登場する。仕様を持って、tmuxで複数のヘッドレスCLIエージェント（例：Kiro CLI、Claude Code）を使って実装するんだ。結果はすごく良かった。しっかりしたKiroの仕様とタスクリストがあれば、エージェントは通常、すべてをエンドツーエンドで実装してくれる。Ralphループの必要性は感じたことがない。 （エージェントは時々Claudeの計画で途中で止まることがあるけど、Kiroではそんなことは一度もなかった。なぜかはわからないけど、チェックリストがあるからかも。それにはPBTテストもゲートとして含まれているし）。最初はあまり強くなかったけど、Kiro IDEは私が使った中で最高の仕様生成器の一つで、エージェント駆動のワークフローと非常にうまく統合されている。

LLMのために物事を簡単にしようとしてるわけじゃないよ。LLMは大丈夫だと思う。CodeSpeakは人間のために作られてるから、私たちはある程度の構造があった方がいいし、何を求めているかを表現する方法を知ってるからね。

私が見る限り、Cは新しい言語というより、アセンブリ開発のための代替ワークフローとそれを実装するツールだと思う。

制限は、自分でコードを修正できないことのようだね、仕様に反映させたいなら。最終的には、人間がコードに触れなくても済む世界になるだろうけど、まだそこには至ってない。コードで起こる変更に合わせて仕様を「追いつかせる」方法を探ってるんだけど、CodeSpeak（エージェントや手動変更など）を通さずにね。面白い試みだよ。エージェントの場合、ユーザーが与えたプロンプトを見るのがすごく役立つ（今、~/.claudeのセッションを調べる実験をしてる）。もっと一般的に言うと、codespeak takeover [1] はコードを仕様に変換するツールで、エージェントのセッションからのプロンプトを考慮するように教えてるんだ。実際、すごく役立ちそうだよ。最初はバイブコーディングモードで何かを始めて、長期的なメンテナンスを考えるならCodeSpeakに切り替えるのは有効な使い方だと思う。「スプリントモード」から「マラソンモード」って感じかな。[1] https://codespeak.dev/blog/codespeak-takeover-20260223

それに、このツールはエージェント生成プロセスの設定可能性をかなり制限しているようだけど、それは特定のツールの制限に過ぎない。そこも改善中だよ。もっと柔軟で設定可能である必要があるね。

それに、彼らはこれをビジネスとして運営したいみたいだけど、どうやってお金を取るのか全く理解できないし、そもそもアイデアがシンプルすぎて、基本的なバージョンなら1日もかからず再実装できると思う。代替実装の方が良くなる可能性もあるしね。それに、クローズドソースのようだから、もしすぐにソースを公開しなかったら、オープンソース版に人気を奪われる可能性が高いよ。

ちょっと堅いかも。こんな感じの出力がプロンプトから出てくるのかな、AIがバイナリで何を生成するか教えてくれるけど、5年後にはこんなコードを書くことはないと思う。英語で十分だろうし。

それがポイントじゃないの？開発ループの中で、期待通りにビルドされない理由を診断するから、以前の暗黙のエッジケースや未文書の挙動、トライバルナレッジを洗い出して、それを仕様にまとめることになるんだ。実際、未文書のスパゲッティよりもずっとメンテナンスが楽になるはずだよ。