Jacob Young氏の記事「Use boring languages with LLMs」は、かなり挑発的ですが、筋の通った主張です。要するに、
LLMやcoding agentを使うなら、派手で自由度の高い言語より、地味でルールが揃った言語を使ったほうがいい
という話です。
ここでいう「boring languages」は、「退屈な言語」ではなく、**“仕様や流儀が安定していて、毎回ちがうやり方を要求しない言語”** くらいの意味だと思うとわかりやすいです。
記事では特に Go が強く推されています。正直、これはかなり納得感があります。人間のエンジニアでも「毎回やり方が違う」環境はつらいわけで、LLMならなおさら迷いやすい、というのは自然な発想です。
著者の主張の中心は、consistent architecture（整った一貫性）ほど、LLMの出力が安定するという点です。
LLMは、学習した膨大なコードのパターンから次のトークンを予測します。
つまり、ある技術が
みたいな状態だと、モデルは「何を選べばいいか」を毎回広い候補から当てにいくことになります。
これは人間でもしんどいですが、LLMにとってはもっと厄介です。
記事の言い方を借りるなら、**“tokensを賭けるギャンブル”みたいなものです。
ちょっと強い表現ですが、言いたいことはわかります。モデルが安定して良いコードを書くには、学習データ側にも“揺れの少なさ”が必要**ということです。
記事では、JavaScriptとPythonがかなり辛口に扱われています。
ただし、これは「悪い言語」という意味ではありません。著者が批判しているのは、言語そのものより、周辺エコシステムの断片化です。
JavaScriptは、たしかにフロントエンドからサーバーサイドまで何でもできる便利な世界です。
でもそのぶん、
という状態になりやすいです。
著者は、2024年のState of JSのような状況を引き合いに出し、人間にとっての「選択肢の多さ」は、モデルにとっては「学習すべき揺れの多さ」だと見ています。
これはかなり本質的だと思います。
Pythonも似ています。
一見シンプルですが、実際には
みたいな分岐がたくさんあります。
このへん、Pythonを触ったことがある人なら「うん、あるある」とうなずくはずです。
個人的には、Pythonは“簡単な顔をして突然めんどくさい顔をする”ところがあると思っています。LLMも同じ穴に落ちるのは当然かもしれません。
この記事の本丸はここです。著者はGoを、この時代のcoding agentに最も向いた言語の一つだと見ています。
しかも面白いのは、「Goが理論上いちばん美しいから」ではなく、**“制約が多く、選択肢が少ないから扱いやすい”**という理由で評価している点です。
これは人間にとっても、AIにとっても、かなり重要な視点です。
Goの goroutine は、簡単にいうと 軽量な並行処理の仕組みです。
複数の処理を同時にさばくための道具ですね。
記事では、これが thread や callback や async/await より、LLMにとって扱いやすいとされています。
理由はシンプルで、Goの並行処理は一貫していて、書き方が迷いにくいからです。
人間も「この非同期処理、何色の関数だっけ？」みたいな話に疲れますが、LLMにその混乱を押しつけないのは大事です。
ここはかなり面白い視点でした。
標準ライブラリとは、言語に最初から付いてくる公式の道具箱のことです。
Goはこの道具箱がかなり充実しています。
記事では、net/http が多くのマイクロサービスで使われていることや、Googleが支援・保守してきた暗号系のパッケージの強さが挙げられています。
要するに、外部ライブラリにあまり頼らなくても、かなりのことができるわけです。
これはLLMにとって大きいです。
外部パッケージが増えるほど、「どれを入れるべきか」「どの流儀に合わせるか」が増えるので、迷いも増えます。
Goはその迷いをかなり減らしてくれる、という話です。
ツールチェーンとは、開発を助ける道具一式のことです。
Goには
gofmt：コードの見た目を統一するgo vet：怪しい書き方を検出するgo fix：直せるものを自動修正するgopls：エディタ上での賢い補助golangci-lint：コードのルール違反をチェックするといった、かなり筋のいい道具があります。
ここが僕はかなり重要だと思いました。
LLMは“それっぽいコード”を書けても、最後の品質担保が弱いことがあります。そこで、ルールを強制してくれるツールがある言語は、AIと相性がいいんですね。
つまり、Goは「AIに自由に書かせる」より、**“決まった型に沿って書かせる”**方向で強い。
これはいかにもAI時代っぽい発想です。
メモリ管理は、ざっくりいうと プログラムが使う記憶領域をどう扱うか です。
Rustは安全性が高い一方で、LLMにとっては借用チェック（borrow checker）がかなり厄介。
C/C++はもっと危険で、学習データにバグの例が山ほどある、というのが著者の見立てです。
Goは、低レベルすぎず高レベルすぎず、ちょうどいい。
そのため、LLMがメモリの細部に過剰に振り回されず、実用的なコードを出しやすいというのが主張です。
これはかなり納得です。
AIに「自由に全部やっていいよ」と言うと事故る。
でも「この範囲でやって」と決めると急にうまくなる。
Goは、その“決めすぎず、でも決めている”感じがうまいのだと思います。
記事では、Goには known set of footguns、つまり「よくある事故ポイント」が比較的少ないとされています。
footgunは直訳すると“自分の足を撃つ銃”ですが、要するに自分で自分を困らせる罠です。
Goにも nil ポインタのような落とし穴はあります。
でも、Pythonのように“何でもできるがゆえに何でも壊せる”世界よりは、危険の種類が限定的だと著者は見ています。
これはLLMにとって非常に大きいです。
モデルは、選択肢が少ないほうが安定します。
つまり、失敗パターンが少ない言語は、エージェントの成功率を上げやすいという理屈です。
ここは大事です。
著者は「Goだけが正義」と言っているわけではありません。むしろ、
非ビジュアルなソフトウェアの大半は、Goとこのツール群で十分こなせる
という現実的な話をしています。
つまり、Webアプリ、CLI、バックエンド、agent orchestratorのようなものを作るなら、**“一番自由な道具”より“最も壊れにくい道具”を選ぶべきではないか**、という提案です。
個人的には、この考え方はかなりAI時代っぽいと思います。
これまでの言語選びは「人間が書きやすいか」が中心でした。
でも今は「AIが事故らずに書けるか」という軸が、普通に重要になってきています。
率直に言うと、かなり刺さる記事でした。
特に印象的だったのは、**“柔軟性は人間には嬉しいが、LLMにはノイズになりうる”**という視点です。
これは単なるGoの宣伝ではなく、
「AIがコードを書く世界では、技術選定の基準が少し変わる」という話なんですよね。
もちろん、これでJavaScriptやPythonが不要になるわけではありません。
でも、agentic codingを本気でやるなら、構造が単純で、流儀が揃っていて、ツールが強い言語の価値は上がる。
これはかなりありそうな未来ではないかと思います。
この文章のメッセージを一言でまとめるなら、
LLMには“自由な言語”より“退屈で一貫した言語”が向いている
です。
Goがその代表例として挙げられていて、理由も
と、かなり筋が通っています。
AI時代の技術選定って、派手さより予測可能性が効いてくるのかもしれません。
この視点は、今後さらに重要になると思います。