Rails World 2026、DHH氏が「手書きコードは時代遅れ」と発言

Ruby on Railsを生み出したDavid Heinemeier Hansson(DHH)氏は、今年のRails Worldカンファレンスで、手書きでコードを書くことはもう経済的に意味がないと語った。Dealroomによるキーノートの報道によれば、同氏は「プロのプログラマーを引退した」と述べ、自分を今は「メーカー」と呼んでいるという。

DHH氏として知られるHansson氏は、AIコーディングエージェントがほとんどのプロジェクトで手打ちのコードを不要にしたと主張した。同氏は手書きコードを「私たちの時代のコダック・ブローニー」と呼び、もう多くの人が必要としない古い簡易カメラにたとえた。Dealroomによると、同氏は「エージェントが生成したコードは、今や普通の業務のやり方だ」と語った。

同氏が示した数字がその主張を裏付けている。Dealroomの報道では、DHH氏は2026年8月だけで約15万行のコードを書いた。以前の手打ちの作業スタイルでは年間約3万行だったという。自身の使用言語の比率も逆転した。Jared Norman氏の分析によれば、Rubyが占める割合は過去20年間のおよそ半分から、今では約3%に落ちたという。

Heyの作り直し

最も分かりやすい例が、Hansson氏の会社37signalsが手がけるメールサービスHeyだ。Heyはプラットフォームごとに1つずつ、6つの独立したネイティブアプリとして作り直されており、メールサーバーの中核はRubyではなくRustで書かれている。Dealroomの報道によると、このRustへの書き直しにより、従来のサーバーと比べてCPU使用率が99%、メモリ使用量が95%減ったという。

DHH氏はこれまでも、Rustは人間には読みにくいと述べてきた。Norman氏の分析は、同氏がこの言語を「LLMには最高」だが人間には「醜い」と呼んだと引用している。理由は、そのコードの大部分をいまや人間ではなくAIエージェントが書き、保守しているからだ。

前後の数字を比較すると次のようになる。

指標	以前	現在
DHH氏自身のコード生産量	年間約3万行	2026年8月に15万行
Heyメールサーバーのcpu使用率	基準値	Dealroomによると99%減
Heyメールサーバーのメモリ使用量	基準値	Dealroomによると95%減
Omarchy Linuxのインストール時間	3分33秒(Rails World 2025時点)	9秒

Railsだけでなくエージェントに賭ける

Norman氏の分析によると、DHH氏は年末までに「ほぼすべての分野、ほぼすべてのプログラマー、ほぼすべての企業」がAIによるコード生成を使うようになると予測した。また、人間がコードを読むことは「標準ではなく例外」になるべきだとも述べたという。

Dealroomの報道によれば、DHH氏がRailsとは別に手がける副業プロジェクト、Linuxディストリビューションの Omarchyには、約2,000万ドルの資金拠出が表明されているという。そのインストール時間は1年前の3分33秒から、現在は9秒まで短縮された。DHH氏は、この高速化をエージェントが書いたツールが実現できることのもう一つの例として挙げた。これとは別に、Rails Foundation自身によるコーディングエージェントのベンチマークでは、初回のテスト実行でタスクの95%を正しくこなしたと、Dealroomは報じている。

Norman氏の記事は、このキーノートがRails自身のロードマップについてはほとんど語らなかったこと、そしてRubyコミュニティの反応はおおむね否定的だったことを指摘している。一部の開発者は、DHH氏がオープニングの持ち時間をAIや自身の副業プロジェクトの話に使ったと感じたという。

開発者にとっての意味

Railsアプリを保守しているなら、今日何かが壊れるわけではない。DHH氏の主張は、コードがどう書かれるかについてのものであり、Rails自体のサポートが終わるという話ではない。ただし、Heyの作り直しは実際のテストケースとして注目に値する。ある著名なチームが、AIを多用する複数言語のスタックの方が、単一の共有Railsコードベースより自社製品には向いていると賭けているからだ。

DHH氏の「月15万行」という数字を自分の生産量と比べる際は注意してほしい。この数字は、1つの完成したアプリケーションではなく、多数の小さなプロジェクトにまたがっていると報じられている。単純な行数は、完成して出荷されたソフトウェアを測る指標としては弱い。

新しいバックエンドサービス向けの言語を選ぶ際、コードの大部分をAIエージェントに書かせるつもりなら、Rustの厳格なコンパイラチェックと、人間には手で読みにくいという評判とを天秤にかけてみてほしい。こうしたチェックは、プログラムが実際に動く前にメモリやスレッド関連のバグを捕まえてくれる。書く作業の大半を人間ではなくエージェントが担うなら、この点はより重要になる。全面的な書き直しに踏み切る前に、まずは小さなサービス1つでこのトレードオフを試してみるとよい。