私も、LLMのトレーニングセットにはRustよりもPythonのトレーニングデータが圧倒的に多いってことには同意する。でも、C++はPythonより前から存在してたと思うから、PythonのコードがC++よりも2桁も多いとは思えないな。

あなたはPythonの型付けの能力を過大評価してると思うよ。

tyはまだmypyがキャッチするものを見逃してるね。それに、Pydanticへのサポートもまだ同じレベルじゃない。速さが魅力で使ってるけど、mypyと一緒に使う感じで、まだ置き換えにはならないかな。確かにmypyは遅いけど、完了を待ってるエージェントには関係ないよね。

それとも、単に悪いトレーニングデータかもね。「any」がどこでもカジュアルに使われているのを見たことがあるよ。

私の経験では、リンターのルールでそれを禁止して、ローカルのClaudeファイルを使って、何かをするたびにリンティングの問題を修正するよう指示すれば、回避できるよ。

だから、私はLLMに対して非常に具体的なルールセットとリンティングを設けていて、anyを一切許可していないし、他の品質チェックも行ってるよ。

質問は2つの方法で聞けるね：(1) 現在のLLMは、ユーザーのワークフローに関するいくつかの仮定のもとで、型付き言語の「雰囲気コーディング」が得意なのか？ (2) LLMは技術として原則的に型付き言語に向いているのか？ それともRLパイプラインはその方向に進むべきなのか？

そうだね、エージェントは「any」に対してすごく反応が早いのに気づいたよ。Rustでの作業は楽しかった。Rustでは型システムを無視するのがそんなに簡単じゃないし、「unwrap」や適切なエラーマネジメントに関しても文化がより厳格だと思う。だから「unwrapを使うのをやめて」って言うことは、ほとんど「anyを使うのをやめて」って言うことより少ない気がする。

LLMには、コンパイルされた型付き言語のように、どんな型も禁止すべきだと思う。

これはちょっとした経験則だけど、ネットで見つかる公開されてるRailsのソースコードって、大体が大きくて安定してて、ちゃんとドキュメントも整ってるコードが多い気がする。

基本的にはこういうことだよね。制約が多いほど、コードを「雰囲気」で書く自由が増えるし、もし誰かがテストを書いたり、バグを見つけたり、24時間365日改善するためのAIを作ったら、もっとすごいものができると思う。

私の経験では、GeminiはGoアプリを一発で作れるよ。これを判断するには、経験則じゃなくてしっかりした評価が必要だね。

比較すると、fastapiみたいな全く意見のないフレームワークは、初期のAIブームで人気が出たけど、バイブコーディングするには扱いにくいよ。人気のあるフレームワークは、物事をどうやるかの明確な方法がなくて、開発者に任せる原則に従っている。意見のあるフレームワークはRailsの後に流行らなくなったけど、実際にはAI支援開発にはかなり適していることがわかったんだ。

flaskを使ってるけど、結果がすごいよ。毎日使ってるかなり良いものを一発で作れちゃった。

変だな、GoはHNでLLMがうまく働く言語の代表例だと思ってた。意見がはっきりしてて、標準ライブラリも多いからね。試したことはないけど、vibe codingの試みは残念だったな。これって時代の流れに逆行してる気がする？

それについて考えたことある？つまり、LLMが一番得意なのは、最も多くの例があるものなんだよね。もしかしたら、トレーニングにはGoよりもよく構造化されたRailsコードが多いのかも？

私のRailsの経験は逆で、Hotwireのオープンエンドなパターンが影響してるんだ。Rails自体は意見が強いけど、Hotwireは同じことをするのにいくつかの方法を提供するから、LLMが混乱しちゃうんだよね。例えば、最近モーダルを使って関連オブジェクトをインラインで作成できるフォームを作ろうとしたんだけど、Claude 4 Sonnetはそのリクエストにかなり混乱してた。どれだけ助けても、結局は解決したけど、結果には満足できなかったよ。基本的な指示だけでReactを使って同じ機能を作ることはできるのに。他のライブラリ、例えばHTMXでも同じこと。TypeScriptとReact、そしてTanstack Queryのような意見が強いツールを使うと、LLMはエラーをすぐに修正できるから、ユーザーインタラクションを構築するのがずっと効率的になるよ。

ずっと設定を書いてればよかったんじゃない？

これはまだ完全な考えじゃないけど、LLMに自分の意見を与えることで緩和できるかも？私はコパイロットをペアプログラミングのように使っていて、作りたいものについてはプロンプトでたくさんの意見を出してる。ただ、私の変更は大きすぎることはなくて、せいぜい100行の差分くらい。

Gell-Mann Amnesia [0] [0] https://en.m.wikipedia.org/wiki/Gell-Mann_amnesia_effect

ちゃんと判断できるものにしか使わないよ。

うん、これはClaudeと一緒にRustを使った経験とは合わないな。プロとして2.5年間Rustを書いてきたけど、結構得意だよ。ClaudeはRustのコードについて幻覚を見ちゃうから、統計モデルであって静的解析ツールじゃないんだ。コンパイルできるコードを生成できるときは、必ず効率が悪くて見た目も良くない。でも、もし使えるエレガントなPythonのコードをゼロから生成してほしいなら、結構いい感じだよ。ちなみに、Pythonは流暢じゃないけどね。

数十年ソフトウェアを書いてきたから、新しい言語で「これは絶対にイディオマティックじゃない」って感覚は結構あると思う。何かおかしいと思ったら、リファレンスコードやその言語の大きなプロジェクトをググり始めるよ。LLMに聞いてみてもいいかもね。「これってイディオマティックなの？」って。もちろん、嘘をつくかもしれないけど…。

「可読性」の概念は良いと思う。これはGoogleのプログラムで、あなたのコードがその言語の専門家にレビューされるんだ（でも、必ずしもあなたのアプリケーションやドメインではない）。イディオマティックなコードを書けるレベルに達し、言語を完全に理解できるようになると、自分自身も可読性を得られる。LLMのコードをレビューする時は、その言語での可読性を自分が持っているべきだし、そうでなければコードは重要じゃないよね。

Goに対して悪口を言うつもりはないけど、君は言ってしまったよね。この言語はずっとAI生成のコードみたいに見えていて、今は実際に書かなくても済むからそれが有利に働いてるって。面白いけど、それがGoの利点だとは思わないな。

同僚が君のコードベースにこんなことをしたら想像してみて…。

そうだね。経験から言うと、比較的複雑なシステムの場合、ミドルレベルの開発者からの1k行以上のPRにはバグがほぼ確実に含まれてる。しかも厄介なやつが多くて、特定して修正するのに何時間もかかることがある。コーディングを始めた頃（数十年前）、特定の問題をデバッグするのに数日かかってたのを覚えてる。オンラインで情報を探すのが難しかったのも一因だけど、自分のコードが過剰設計だったのも問題だった。大量のコードをすぐに書けたけど、実際に動くコードを作るんじゃなくて、見た目だけ動くコードを目指してたんだ。たまに自分のコードが壊れるとショックだったけど、今はそれが過剰に複雑にした結果だって分かる。良いコードは簡潔で、最小限の形で発見されたように見える。悪いコードは作り出されたもので、作者が余計に派手にしようとした感じ。20年コーディングしてきたけど、悪いコードは数秒で見抜ける。良いコードは読みやすいし、まずは関数の名前を見ただけで何をするか分かる。読んでも予想外のことはなくて、余計なこともしてない。

もしかしたら、LLMがファイルを再作成して更新してるのかも。過去にLLMはそうする傾向があるのに気づいたことがある。考えてみれば、まだgitを学んでない大学のCS学生がやることとあまり変わらないね。それでも、著者が少なくとも変更を整理する時間を取らないのはかなり悪いことだね。でも、ファイル名の変更だけかもしれない？

Scalaのトレーニングデータが少ないのが問題かもね。Pythonがどれだけあるか想像してみて。