従業員が少ないからね…。

蒸気力や電気についても同じことが言えたよね。これはただの比喩じゃなくて、これらのものの魔法は普遍的な情報エンジンであることにあるんだ。資本を使って、よく理解されたスケーラブルな技術でそれを作り、電気に接続すれば、価値が生まれる。要するに、「持つ者」と「持たざる者」が出てくる可能性はゼロだよ。電気が現代社会でそうなったわけじゃないからね。

これがアンスロピックから標準料金で支払った場合、いくらかかったのか気になってしょうがない。誰か大体の価格を教えてくれない？

良いテストスイートを含むプロジェクトを別の言語に翻訳するのは、LLMがうまく機能する素晴らしいケースとして知られてる。完全なコードベースを例として使い、すべてをチェックするためのテストスイートがあれば、目指すゴールに向かって反復するのがずっと楽になる。LLMはすでに目標が何で、どう実装されているかを見ているから、仕様から始めるよりもずっと簡単な問題なんだ。

いや、これらのエージェントはローカルで動かすのがどんどん簡単になってきてるよ。Qwen 3.6 27b試してみた？サイズに対してできることがすごすぎる。コンテキストをうまく管理すれば、小規模プロジェクトには100%合ってる感じ。

中国語がLLMベースのプログラミングにどれくらい効果的か気になるな。一方では、中国語の文字は意味が濃いからトークン効率がいいけど、逆に曖昧さが増すかもしれないね。

私は50%英語（個人プロジェクト）/50%ポーランド語（職場）で使ってるけど、正直、出力や曖昧さにあまり違いを感じてないよ。ポーランド語のプロンプトは動詞の形が多いから短くなる傾向があるし、「壊れた」と言う時に使う言葉がちょっと不気味でストレートすぎて、時々笑っちゃうことがある。

同意するよ。特定の言語のコード生成にあまりにも焦点を当てているものは、もう過去の戦争を戦ってる感じがする。UMLモデリングの復讐だね。最終的には、エージェントの作業から出てくるものが正式な仕様の問題になるくらい、十分に良くなると思う。コードが実際に必要で、純粋なエージェントオーケストレーションのワークフローでは達成できない場合を前提にして。

英語とアルバニア語で使ってるけど、実際あんまり違いはないよ。すごいね。

自然言語はシステムを構築するために必要な精度がないよ。システムを正確に指定するための言語はもうあるんだから。それは「コード」と呼ばれてる…

最終的には独自の英語の方言になると思う。LLMに指示を出すのは、普通の英語とはちょっと違う英語を使った方がいいし、これが続けば自然な英語とは認識できない新しいあいまいなプログラミング言語になると思う（おそらく>1）。

子供たちにトークン語を流暢に話せるように教えてるよ。

フランス語をほとんどずっと使ってるけど、うまくいってるよ。英語のプロンプトを書けないわけじゃないけど、母国語を使う方が楽だなって感じる。

確かに、企業や政府は一般の人よりも優れたモデルにアクセスできるだろうね（実際、すでにそうなってるのがMythosだし）。一般の人も、最前線からは少し遅れたモデルを使って自分たちのことはできるけどね。

世界には必要なソフトウェアの量が限られている。ドットコムバブル崩壊の頃、学生や求職者にソフトウェア業界に入るなっていう意見が結構あったんだ。業界が「飽和状態」になりつつあるからね。仕事があまりないって考え方で、特にその分野に集まってくる人の数に対してはね。崩壊はその考えをさらに強めた。でも当時の学生としても、ソフトウェアには無限の可能性があるって感じてた。手動でやってる認知的なことは、ほぼすべてソフトウェアでできると思ったし、一度それを数えようとしたら、やることがめちゃくちゃ多いことに気づいた。さらに、新しいやり方で物事をやるほど、想像もしていなかったことがたくさん出てくるってことも理解してた。可能性は数え切れないほどあった。「飽和状態」という考えは、人々の想像力やソフトウェアの本質を理解していないことから来ているのは明らかだった。この分野は、ソフトウェアを書く対象が尽きることは絶対にないから、飽和することはないって確信してた。でも最近は…新しいソフトウェアを作ることは常にあるって分かってるけど、AIのおかげでそれがこれまで以上に早く進化するだろうね。でも最近は、新しいことを考えるよりも早くソフトウェアを書くことができるようになったのかなって思うことがある。

6日間でこれができるんだよ！最初のアーキテクチャやテストスイートに何十万時間もかけたことは無視してね。

これはすごい成果だよね。たとえ優秀なエンジニアでも、達成するのに何倍も時間がかかると思う。最終的にこれが市場に出るとき、どれだけの人間の努力がテストスイートの設計やキュレーションにかかったかがちゃんと評価されることを願ってる。テストスイートは、現行のLLMにとって理想的なシナリオみたいなもんだ。十分に包括的なテストスイートは、エージェントが好きなように実装するための仕様を形成するんだよね。この場合はRustで。場合によっては、実際のソースコードを全部捨てて、テストにアクセスできるエージェントにプロジェクトを一から再実装させることもできるかもしれない。bunみたいなプロジェクトなら特にね。

しかも、unsafeとして明確にマークされてるから、見つけやすいし、対処すべき問題のリストができるのはいいね。

Bunは非常に多くのクラッシュやメモリバグが発生している 何か統計やソースある？それが嘘だとは思わないけど > そして、醜い部分はさらに醜く見える（unsafe）から、リファクタリングを促すよね。Bunはある程度、自分自身にそれを負ってると思う、言語だけのせいじゃないよ。

Zigを使うと「極めて多くのクラッシュやメモリバグが発生する」という主張なの？ それなら、そんなツールで高品質なソフトウェアを作るのは不可能ってことになるんじゃない？ C/C++で作られた質の高いものがたくさんあるから、Zigは何を間違ってるの？

そのケースからは別の教訓があると思う。LLMはフィードバックループを与えたものに基づいて構築されるから。論理的なテストだけを与えると、スピードは全く考慮しない。スピードを測るテストを含めて、LLMにパフォーマンスを合わせるように頼めば、それもできる。これはLLMに関する他のすべてのエラーと同じ種類のものだよ。重要だと人々が考えることに対して、常識的な文脈がない。境界を強制しないと、無視されるよ。

興味がある人はここで話してるよ：ユーザーが受け入れ基準を最初に定義すると、LLMはうまく機能する - https://news.ycombinator.com/item?id=47283337 - 2026年3月（422件のコメント）

彼はメンテナビリティ、パフォーマンス、テストスイートのチェックをして、決断したみたいだね :)

「誰も壁を作るつもりはない」 - ウォルター・ウルブリヒト、中央委員会の議長、ベルリンの壁が建設される数ヶ月前の発言。AI企業とその関連者たちは、その否定や嘘のレベルを超え始めているね。

cargo checkを実行したら、1万6000以上のコンパイラーエラーが出たんだ。バージョン番号も表示できなかったし、JavaScriptも動かなかった。こんなに早く動くとは思わなかったし、パフォーマンスがこれほど競争力があるとは予想外だった。もっと詳しい内容はブログに書く予定だよ。

何が言いたいの？

うん、それは今のところ非常に成功した実験ってことだね。

それに、数日前に言ってたことだけど: > OSSは逆の方向に進むと思ってる。人間の貢献は許されない。スロップは2025年と2026年の懐かしい遺物になるだろう。Anthropicに買収された後、こうなるのは予想できたはずなのに、やっぱり残念だよ。大規模言語モデルという技術には反対じゃないけど、これらの「AI」企業が力を持つようになった経緯には本当に嫌悪感を覚える。ソフトウェア業界や他の世界を食い尽くしてるからね。数歩先を見越して、スロップのないソフトウェアスタックとコミュニティを準備し始めるべきだ。それにはZigやそのエコシステムも含まれる。私たち（や未来の世代）がスロップなしで完全に生きることができなくても、持続可能なコンピューティング文化を確保することが今まで以上に重要だよ、自由という意味でね。

マイクロソフトがGoで書き直したとき、リーダーの一人がRustよりもパラダイムの類似性（ガーベジコレクションなど）からGoを選んだってコメントしてたけど、Rustを使うのはもっと難しくて「いろいろな手続きを踏む」必要があったらしい。今やってみてどう思う？

わぁ、すごい仕事だね。もうGo版より速いなんて、かなり印象的だ。

ZigはTypeScriptよりもbunにタイプが合ってると思うよ。Cのffiの共通インターフェースがあるから、モジュールごとに移植してテストスイートをZigで維持するのも想像できるね。

それが本当だとどうやってわかるの？問題の人物はAnthropicで働いてるし、Zigはその不安定さからしばらくの間ブラックリストに載ってたんだ。これがMythosみたいなマーケティングのスタントかもしれないし、Anthropicが政府に救済されなきゃいけないほど危険なものだよ。タイムラインが本当かどうか、Rustの専門家が関わっているか、報告されたテストスイートの準拠が本当かどうかもわからない。私たちは常習的な嘘つきとプロモーターの会社と関わっているんだから。

RustはLLMを使ってすべてのコードを書くのに完璧だ。厳格な型システムのおかげで、他の言語が許すような愚かなミスを犯す可能性が低くなる。これには疑問がある。確かに、コンパイル時に不変条件を強制することで、LLMが機能するコードを生成するのに役立つ。迅速なフィードバックを受けて、バグのあるコードを生成する代わりに、再トレースできるからね。一方で、Rustはリファクタリングの雪崩が起こりやすい複雑な言語だ。コンポーネントの小さな変更が遠くのコードのリファクタリングを強いることがある。初期のアーキテクチャが悪かったり不足していたりすると、LLMが通常やるようにコードベースを徐々に成長させると、スパゲッティ化しがちなんだ。だから、コンパイルも通って動くけど、人間には読めなくてメンテナンスもできないプログラムができるのが怖い。

Rustは素晴らしいけど、LLMを使った大規模プロジェクトでは、私が望むようにRustソフトウェアを構築するのが難しい。クリーンな境界を維持したり、そもそもそれを確立することが、フロー状態から痛いレビューに変わって、先延ばしモードに入っちゃうんだよね。

機能型スタイルを使ったコードって、LLMにとって完璧なエンドゲームになりそうじゃない？生成をどんな粒度でも並列化できるし、変更を簡単に囲い込めるし、すべてを再現できる。型がLLMにヒントを与えてくれるしね。

同じことだけど、マルチスレッドのPostgresについて[0]。96%のpg回帰テストが1ヶ月で合格、823K LOCだよ。8つのCodexアカウントを月200ドルで使い切ることができたし、MythosなしでもRustの利点も見てきた。自分のpgの経験が、長い間みんなが苦労している多くのことに関して良いデザイン選択をするのに役立つと賭けてるんだ[1]。AIが複雑なソフトウェアを改善するのをもっと可能にしてくれるのが楽しみだよ。[0] https://github.com/malisper/pgrust [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...

Opusが変なRustを書かないようにするのに苦労してるんだけど、何かアドバイスある？