黒背景に白文字は読みにくいんだよね。なんか、年取ってきたせいか、目が痛くなるし、ちょっと見ただけでも目が慣れるのに数秒かかる。若い子たちがダークモード好きなのは分かるけど、暗いウェブページを読むときはリーダーモードを使わないと、内容が全然読めない。残念ながら、このサイトは白背景に切り替える方法が分かりにくくて、HTMLソース（CTRL+U）を見るしかない時もあるんだよね。

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

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

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

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

これ、あんまり意味が分からないな。* これは言語じゃなくて、仕様をコードにマッピングして再生成するためのツールだよ。* モデルは決定論的じゃないから、再適用するたびに違う出力が出る可能性が高いし（現在のコードを再適用に入れない限り、変更を提案するだけになる）。* モデルは急速に進化してるから、今月のCodex/Sonnetなどは先月とは違うコードを生成する可能性が高い。* テキストの仕様は常に不十分で、重要な詳細が省略されがちだから、小さな例では問題ないけど、大きなコードベースでは厳しい。* どんな非自明なコードベースも、相互作用する何百もの仕様から成り立ってるから、機能に影響を与えるすべての仕様を読み解くのはとても難しい。 この分野にはチャンスがあると思うけど、私が見たいのは、* テキスト仕様を書くこと、* モデルがテキストを*正式な*仕様に変換すること、* その後、正式な仕様がコードに翻訳されて、仕様と照らし合わせて検証できること。2と3は、ADA/Sparkのように検証をサポートする実用的で人気のある言語があれば一つにまとめられるかも。でも、正式な仕様から生成されたテストで実装を検証することでも実現できるよ。

私のプロセスは、似たようなものに自然に進化してきたけど、あまり厳密には定義されてないかな。 - 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の神経解剖について大きな仮定をしている。最近のこれ[1]は、LLMが内部でどのように構成されているかについて驚くべきことを示唆している。具体的には、エンコーディングとデコーディングは異なるフェーズであり、その間に他のことがあるということ。訓練された言語はそれほど重要ではないかもしれないね。[1] https://news.ycombinator.com/item?id=47322887

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

私が見る限り、これは新しい言語というより、LLMベースの開発のための代替ワークフローとそれを実装するツールだと思う。私の理解が正しければ、直接LLMエージェントにコードを変更する方法を伝えるのではなく、コードが何をするかを説明するマークダウンの「仕様」ファイルを保持して、「codespeak」ツールがその仕様ファイルの差分を取り、エージェントに変更を指示するというアイデアのようだ。その後、コードをチェックして、更新された仕様とコードの両方をコミットする。これには、プロンプトがソースと一緒に保存され、失われることがないという利点があるし、現在の仕様全体を見られる形式になっている。ただし、仕様がそれを反映するようにコードを自分で変更することはできないし（実際のコードを参照するLLM駆動の変更もできない）、一般的に仕様がプログラムに関するすべての重要なことを反映している保証もないから、コードには「ソース」情報が含まれる可能性もある。例えば、GUIの背景を白にしたいけど、LLMがたまたまそれを選んだからそうなっているだけで、仕様には書かれていないかもしれない。後者は、複数の生成を行ってすべてをチェックすることで軽減できるかもしれないけど、それはLLMと検証コストを増やすことになる。また、このツールはエージェント生成プロセスの設定可能性を大幅に制限しているようだけど、それは特定のツールの制限に過ぎない。

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

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

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

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

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

面白いプロジェクトだけど、間違ったボトルネックを解決しようとしてると思う。私が欲しいものとモデルが出すもののギャップは、主に言語の問題じゃなくて、知識の問題なんだ。どんなに正確な仕様を書いても、モデルがあなたの製品のエッジケースや未文書の挙動、チームが蓄積したトライバルナレッジについてのドメイン特有の知識を持っていなければ、出力は自信満々に間違ってるよ。私は逆の方向からこれに取り組んでるんだ。モデルに話す方法を形式化するのではなく、モデルがアクセスできる知識を構造化することだよ。実際に、ドメイン知識のフロンティアモデルが自力でどれくらい生産できるかを測ると（これを「エソテリック知識比率」と呼んでる）、よくドキュメント化されたオープンソースプロジェクトでも40-55%しかないことが多い。プロプライエタリ製品だとさらに低いよ。仕様の形式主義ではそのギャップは埋まらない。失われた知識を文脈に入れる必要があるんだ。

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

これは後退してるように見えるね。LLM用のプログラミング言語には、たくさんの組み込みの保証や制約が必要だよ。コードは密度が高くあるべきだし。このプロジェクトがどうなるのか、ちょっとよくわからない。すべてを悪化させるように見える。私はHaskellで複雑なものを書くのに成功してるけど、結局のところ、数行のLLMコードが型チェックやテストスイートを通過してダメージを与えることをあまり心配してないんだ。ほとんどのバイブコーディングがPythonやJavaScriptに集中してるのは驚くべきことだけど、私の経験では、モデルがすごく監視や手助けを必要とするから、単なるリスクになっちゃう。理想的なプログラミング言語は、プログラムが簡潔で、非常に正確で、かつ合成可能な仕様のセットだけで、それをコンパイラが効率的な機械コードに変換するものだと思う。英語がそのプログラミング言語だとは思わないな。

メインページの最初の例であるcode.pyは、インデントエラーになるよね :)

シニアがAI（無知なジュニア）に自分の仕事をやらせるための正式な方法？結局、誰が出力コードをチェックして修正するの？もちろん、専門家はそれを捨てて、ちゃんと設計・記述して、動くことを確認するだろうね。

タイトルを書いた人は、「正式」という言葉を使うことでプロジェクトに対して損失を与えているかもしれないね。プロジェクトは「仕様」についてたくさん話してるから。正式仕様について何かを暗示していると勘違いしちゃった。私の理解では、実際には正式仕様を利用しようとしているわけじゃなくて、アプリケーションに対する個々の人間の言語要件と、それを実装するコードとの関係をもっと明確にマッピングしようとしているみたい。

プログラミング言語が「良い」とされるための要件の一つは、これを行う際に、求める全ての動作を得るために十分な具体性を持たせると、コード自体よりも冗長になることだよ。