この記事の面白いところは、単に「Rustが速い」と言っているわけではない点です。
著者 Noah Mitchem はもっと大きな変化を見ています。
これまでのソフトウェア開発では、人間がコードを書くことが大前提でした。
だからPythonやTypeScriptのように、
という言語が強かったわけです。
一方でRustやC++、Goのような言語は、性能は高いけれど、人間にとってはやや面倒でした。
コンパイルエラーが多い、学習コストが高い、実装に時間がかかる。なので昔は「まずPythonで作って、後で速くする」がよくある勝ち筋だったんですね。
ただ、著者はその前提が崩れたと言います。理由は、AIが“難しい言語”をかなりうまく書けるようになったからです。
ここ、かなり重要だと思います。
なぜなら、言語選びの基準が「人間が気持ちよく書けるか」から、「AIが高品質に生成しやすいか」へ移っていく可能性があるからです。これはかなり発想の転換です。
元記事では、RustやGo、Swiftのような言語が注目されています。
理由は、型が強いことと、コンパイルしてすぐ間違いが見つかることです。
人間にとっては「うるさい」言語でも、AIにとってはエラーがそのまま学習材料になる。
つまり、間違い → エラーメッセージ → 修正 のループが回しやすいわけです。
これ、たしかに面白いです。
人間の感覚では「Rustは難しい」なのに、AIの視点では「エラーが親切で、修正ループが速いから扱いやすい」という逆転が起きる。
技術の世界では、こういう“評価軸の反転”が突然起きることがあるので、油断できないなと思います。
記事が説得力を持つのは、抽象論だけでなく、具体例を大量に挙げているからです。
Microsoft が TypeScript compiler を Go に移した、という話が出てきます。
著者はこれを、「性能を得るために、より扱いにくいはずの言語へ移る判断が実際に起きた」例として紹介しています。
ここで大事なのは、Go にした理由が「流行っているから」ではなく、AIがいるなら移植コストが昔ほど重くないと見ている点です。
昔なら、巨大なコードベースを別言語へ移すのは大工事でした。
でも今は、AIを使って移植を進められる。だから意思決定が変わる、という見方です。
Anthropic の研究者 Nicholas Carlini が、複数の Claude agent を使って Rust で production C compiler を作ったという話も出てきます。
規模は 10万行。しかも Linux を起動し、QEMU、FFmpeg、SQLite、PostgreSQL、Redis まで動かし、Doom も動く。
費用はおよそ 2万ドル弱。
これはかなりインパクトがあります。
昔なら、C compiler を作るなんて大学院レベルの超大仕事のイメージでした。
それが、AIを使うと現実的なプロジェクトのスケールに見えてくる。
個人的には、ここがこの記事の最も“時代の変化を感じる”ポイントでした。
Rustのベテランである Steve Klabnik が、Claudeを使って新しい systems language 「Rue」を2週間で作った、という話もあります。
以前の自分よりずっと早く進んだ、と本人が語っているそうです。
Ladybird browser の作者 Andreas Kling は、Claude Code と Codex を使って、C++のJavaScript engine を Rust へ2週間で移植したとのこと。
しかも大量のテストで回帰なし。
「手でやったら何か月もかかった」と述べています。
このあたりを読むと、もはや「AIは簡単な補助ツール」という段階ではない、と感じます。
設計の補助、移植、実装、検証まで、かなり深いところに入ってきている。
もちろん万能ではないですが、「昔は無理だった」がどんどん減っているのは確かでしょう。
PythonやJavaScriptが強かった最大の理由は、言語そのものというよりエコシステムでした。
要するに「便利な部品が揃っている」「困ったら誰かが作ったライブラリがある」ということです。
でも記事は、そこにも変化が起きていると言います。
たとえば Python の世界を見ても、以下のようなライブラリの中身は Rust が多いそうです。
つまり、Pythonの表面はPythonでも、中身はRustというケースが増えている。
これはかなり示唆的です。
言い換えると、「Pythonで開発しているつもりが、性能の肝は別言語が持っている」状態です。
さらに、ruff、uv、ty などのツールを作る Astral が Rustで成長したことも紹介されています。
OpenAI や Anthropic がこうした基盤ツール企業を買収したという記述もあり、著者はこれを「AI時代のソフトウェア基盤は、Rustのような高速な道具に寄っていく」と見ています。
個人的には、ここはかなり納得感があります。
PythonやJavaScriptがダメという話ではなく、**“表の書きやすさ”は残しつつ、“裏側の重たい部分”は高速言語に任せる流れ**が進んでいる、ということだからです。
この流れが続くなら、「Pythonを使う理由」は少しずつ薄くなる場面が増えていくのではないかと思います。
ここは誤解しやすいので、ちゃんと切り分けたいです。
著者は「Pythonが完全に終わる」とは言っていません。むしろ、例外もかなり認めています。
たとえば記事では、次のような反例が挙がっています。
つまり、
性能が大事な場面ではRustが有利でも、配布形態や実行環境、業界標準の都合で別の選択が正しいことはある、ということです。
ここはすごく健全な視点だと思います。
技術記事でありがちな「新しいものが全部勝つ」みたいな話ではなく、ちゃんと制約条件を見ています。
現実の開発は、ベンチマークだけでは決まりませんからね。
著者の核心は、コードを書くコストが下がったということです。
昔は「人間が書く」ことが中心だったので、書きやすさが最重要でした。
でも今は、AIがかなりの部分を書いてくれる。
すると、人間の役割は少し変わります。
つまり、実装の手を動かす時間より、設計と確認の比重が増えるわけです。
この世界では、Pythonの「書きやすさ」が以前ほど決定打にならない。
逆に、RustやGoの「速く動く」「信頼性が高い」という長所が、長期的には効いてくる。
著者はそこに、かなり大きな転換を見ているのだと思います。
元記事で印象的なのは、「コードよりテストやドキュメントのほうが価値が高くなるかもしれない」という視点です。
これは、AI時代の開発の本質をついている気がします。
AIはコードを量産できる。でも、そのコードが本当に正しいかは別問題です。
だからこそ、
プロジェクトほど、AIが活躍しやすい。
逆に言うと、曖昧なプロジェクトはAIでも苦戦する。
これは現場感としてもかなりありそうです。
雑なコードベースより、ちゃんとしたテストがあるコードベースのほうが、AIにとっても人間にとっても扱いやすい。
このあたり、今後ますます重要になるのではないでしょうか。
「これからは、人間が書きやすい言語ではなく、AIが書きやすい言語が勝つかもしれない」
これがこの記事の中心テーマです。
そして、その候補として Rust や Go が強くなる。
PythonやTypeScriptは、表面の使いやすさではまだ強いけれど、裏側の仕組みまで含めると、徐々に“ラッパー”に見えてくる。
だったら最初から、速くて堅い言語で作ったほうがいいのではないか——というのが著者の問いです。
個人的には、この主張はかなり刺激的だと思います。
ただし、すべての現場でそのまま当てはまるとも思いません。
たとえば小さなチームが素早く検証したいとき、やっぱりPythonの速さは魅力です。
でも、AIが本当に実装コストを下げ続けるなら、「とりあえずPython」から「最初から性能と将来性を考えてRust/Goも選ぶ」 へ、意思決定の重心はずれていくはずです。
この記事は、単なる「Rust推し」ではありません。
もっと大きな話として、AIによって“言語選びの前提”そのものが変わると主張しています。
昔は、人間が書くから Python が強かった。
でもこれからは、AIが書くなら話が変わる。
そのとき有利なのは、エラーが早く、型が強く、性能も良い言語かもしれない。
そしてその流れは、すでに現場の実例として見え始めている——というのがこの記事の熱量です。
正直、かなり挑発的な記事です。
でも、ただの煽りではなく、実例が多くて「うーん、ありそうだな」と思わせる力があります。
少なくとも、次に新規プロジェクトを始めるときに、**“なんとなくPythonで”を見直す価値はある**、というのは間違いなさそうです。
