DHHが「手書きコーディングの時代は終わった」と宣言、Railsの今後をめぐりHNで議論沸騰
Rails World 2026 Opening Keynote [video]
Rails World 2026の基調講演で、37SignalsのDHHはAIコーディングの時代を語り、手作業でのコーディングは終わったと主張した。Railsそのものの話は少なく、フレームワークがエージェント開発にどう適応するかには触れていない点を疑問視する声も。Rubyの存在意義やRailsの将来を悲観するコメントが相次いでいる。
Rubyは人間がコーディングするために設計された。そしてDHHは手書きコーディングの終わりを告げている。
HNでの議論
474- robbyrussell
昨日の朝、Davidのトークを最前列で聞いた。前日に彼と話していたこともあり、正直…特に驚きはなかった（心の準備もできていた）。
#RailsWorldからの簡単な現場レポートだが、ここでの雰囲気は決して暗澹たるものではない。むしろ逆だ。業界がどこへ向かおうと、我々の多くは依然として「修繕者」として雇用されている…顧客が依存し、企業が喜んで金を払い続けるシステムの面倒を見ている。
ほとんどの人は、まっさらなキャンバスに向かって未来のアーキテクチャを設計しているわけではない。何年も前になされた決定を引き継ぎ、古いパターンを更新し、制約を回避しながら、このクソを確実に動かし続けている。
これらの新しいツールは、我々が引き継いだシステムについてもう少し考えを巡らせる機会を与えてくれると思う。なぜ物事がそう動くのかを解き明かす。これまで時間や自信、あるいは許可がなくて見直せなかった前提をいじってみる…そして学んだことを共有して、次の人やエージェントがもっと楽にできるようにする。
8年前に選んだあのデプロイモデル？もう一度見直す価値はある。我々のWebアプリのいくつかは、ネイティブアプリだったらよかったのにと思っているかもしれない。そして、多くのアーキテクチャ上の決定は、ただ…まあ、それと共に生きるのに忙しかったから、そのままになっているだけだ。
これらのツールが我々の仕事にとって何を意味するかについて、理解できる不安はたくさんある。私はむしろ、それらが何を見直す許可を与えてくれるのかに興味が湧いている。
私の基調講演が公開されたら、私がここ[…]のために取り組んでいる、プログラミング言語に近い小さなフレームワークについてもっと共有するつもりだ。
- robgough
彼の政治的信条への懸念はさておき、彼がここで話していることには真実があると思うし、開発者が直面している、あるいはまもなく直面する現実をただ明言しているに過ぎない。多くの人にとって、これを聞くのは非常に不快だろう。
注目すべきは、この講演での彼の視点が、フレームワーク自体に責任を持つ者というよりも、開発者＝ユーザー側の視点であることだ。それは意外であり、Railsにとって良い兆候ではないのではないかと疑っている。
エージェント開発の採用をこれだけ謳いながら、この新しいエージェント開発の現実に合わせてフレームワークをどう適応させているかについては何も触れていない。エージェントは現在Railsでうまく機能するが、私が見る限り、これを前進させるものは何もない。
自分のプロジェクトでは、彼がRustを使うのと同様の理由で、主にElixir/Phoenixに移行した…学びたくはなかったが、今では学ぶ必要がなく、その強みを享受できている。
- hitekker
「こんなに混乱した葬式は初めてだ」がそこでのトップコメントだ。まさに適切！
- sashank_1509
ネイティブ対Webアプリの問題について言えば、これは完全に人間が作り出した問題だ。私はゲームエンジンのような決定論的な解決策の方が好みだが、Web仕様に基づいてエージェントがネイティブアプリをコーディングするというのは悪くないアイデアだ。
もっと大きな疑問は、最初の実装をエージェントがやるのか、人間が手書きするのかということだ。私の意見では、最近エージェントを多用していて、1日に何千行ものコードをレビューしているが、頭の中に作りたい仕様が明確にない限り、これはうまくいかないと思う。
実際に手を動かしてコードを人間の速度で打つことで、アーキテクチャがどうあるべきか、どう構築すべきかをよりよく理解できる。私は良いアーキテクチャに推論でたどり着くのではなく、過去にもそんなことはほとんどなかったし、エージェントに計画を確認して100回目に説明させることでも絶対に得られない。そして、一度アーキテクチャがわかれば、エージェントはそれほどスピードアップさせてくれないと思う。7日間のコーディングが1日になるが、その7日間は大した価値がなく、その7日間でさらに多くのアイデアやメンタルモデルを生み出し、それが何年にもわたって配当を生む。
仕立て屋に、工業用ミシンを使えば繊細で美しい服を作る技術が向上すると言うだろうか？もちろんそんなことはない。実際、2026年になっても、高品質で繊細な服の多くは手縫いされている。コーディングにも同等のものがあるだろう。DHH自身も認めている、彼が「m[…]」と曖昧に言うときには。
- zerr
基調講演では、ある観点から、あなたはコーダーではなく「モノを作る人」になると言及している。しかし、誰も問いかけていないのは、その観点からすれば、なぜ誰かがあなたの「作ったモノ」を使うのか、AIを直接使うのではなく？その観点では、アプリという概念はすべて消え去る。
- tnolet
開発者向けカンファレンスが、今や完全に公然と、マスクを外した人種差別主義者／ファシストに1分間のスクリーンタイムを与えるとは、私には理解できない。Rails界は知らないのか、それとも気にしていないのか？
編集：実際のRailsカンファレンスが彼を追放したから、これは彼のカンファレンスなのだ。悲しい勝利だな。
- why-el
これまでのところ、Rustへの書き換えの成功率は、良い設計のテストスイートの存在と直接、おそらく超線形的に相関している。これがBunの書き換えやその他が成功した理由だ。37Signalsの書き換えでも同じことが言えるだろうと予想している。
彼らが完了したら、いくつか学びたいことがある：
1. テストスイートの支援が終わった後、彼らのバックエンドで機能はどう構築され、同じ品質を維持し続けるのか。LLMのテスト作成は少し厄介で、昔Randy Coulmanが呼んだ「トートロジー的テスト」を好む傾向がある。そうならないようにするには多くの労力がかかるので、37Signalsの人々は少なくともこの部分は読むだろう。Rustを全く読まないとは想像できない。
2. 長年にわたり、彼らはドメイン設計でいくつかの革新を行ってきた。例えば委譲型パターンなど、Railsが容易にしたものだ。Rustはこれを再現するのか、そして読まずにどうやって知るのか、あるいはそれは重要でないのか？さらに、新しいパターンはどう生まれるのか？そして、より良い抽象化の我々の武器庫はどう成長し続けるのか？
答えは持っていないが、その答えを学べる可能性があることを嬉しく思う。
- jcmontx
まあ、メールサーバーは低レベル言語の最適なユースケースのすぐ次に来る。私はCRUDアプリにはいつでもRails（またはLaravelやDjango）を選ぶ。特にRailsは非常に慣習的で、AIが標準化された方法で書いてくれるので素晴らしい。
- melodyogonna
Railsカンファレンスに来て。Railsについて何も話さない基調講演をして。去る。
- devy
DHHの基調講演はとても楽しめた。彼自身の家族の系譜の物語を、美術史と技術進化を絡めて、肖像画→写真というアナロジーで、今テクノロジーランドスケープで起きていることを描いていた。