DHH、Rails WorldでまさかのRails離れを宣言

「すべてのプロダクトがCLIを操作するエージェントに使われるなら、BasecampやFizzyを最も安い代替品とどう差別化するのか？」

その時点で、なぜわざわざ「CLIを操作する」必要があるのか？これがすぐに消え去らないとは思えない。現在の軌道では、BasecampやFizzy、あるいは最も安い代替品が「Claude、チーム用にBasecamp風のプロジェクト管理ツールを作って」と競合できる未来は見えない。

思慮深く作られた、意見の強いソフトウェアに内在的価値がないと言っているわけではない。ある側面では常に「より良い」だろうと信じている…ただ、ごく短期間でその市場が存在するとは到底思えないだけだ。

この視点から説得してほしいと心から思っている。

> 37signalsは独創的な機能ではなく、意見の強いUI/UXでプロダクトを差別化している。Webの忠実度が十分でないため、Heyを6つのネイティブアプリとして書き直している。つまりUIは完全な書き直しを正当化するほど重要だが、同時にみんなはCLIだけを求めているのか？

最近これを何度か見た。UIを作るのはやめるべきだ、誰もUIと対話したくない。すべてのアプリはチャットボットで使えるAPIであるべきだ。ただし自分のアプリを除いて——自分のアプリは職人的UXの手作り奇跡であり、そのUIは世界の見方を変えるだろう。

これはまさに昔の議論で、シェルパイプラインの代わりにLLMが入っただけだ。機能性とユーザーへの価値の観点から、ソフトウェアは柔軟で構成可能であるべきだ。80年代からわかっている。しかし、ソフトウェアを靴のペアのように製品として売るモデルはそれと相容れない。ユーザーが大金を払う正当性を得るには大きなモノリシックアプリケーションが必要で、印象を与える派手なインターフェースが必要だ。そしてソフトウェア業界全体がそのモデルの上に成り立っている。モノリシックソフトウェアが目的に全く適さない場合、例えばより大きなシステムのコンポーネントになる必要がある場合、私たちは（主に無給の）OSSに頼る。

ただし今はLLMのおかげで、ほとんど技術的知識がなくても、人間向けの非構造化データ/インターフェースの上に「プログラマブル」なインターフェースを貼り付けられる。そしてそれが実際に私たちが求めているものだから、当然みんなそうする。だから最終結果は […]

少し関連性の薄い2つの考え：

1. これがオープンソースにおけるBDFL文化が悪い理由だ。BDFLが完全に奇妙な混乱に全力を注ぐと決めたら、突然大規模なフォーク政治が起きる。

2. Heyが今や看板プロダクトなのか？？実際にHeyを使っている人いる？1年間試したけど、基本的に遅くてバグが多く機能も少ないGmailを使う特権にお金を払っているだけだとわかった。しかも、搾取しない有料メール市場にさえ食い込めていない（FastmailとProtonがあるんだぜ）。

SREとして、経験豊富な開発者のこの立場についての見解に非常に興味がある。「LLMが生成するコードを必ずしも読む必要はない」と。私には、それが一人の開発者が1つ以上のエージェントを管理できる唯一の方法に思える。なぜなら、コードを実行するのは常に、単一のエージェントがそれを生成するより遅いと感じるからだ。一方で、それは内部で何が起きているかについて人間の理解が欠如していることを意味する。LLMが優れたコードとそのコードの優れたテストを書くと信頼するなら問題ないが、根本的に100%の信頼が必要で、真剣な業界では99.9%では足りないのではないか？

また、最終的にはデプロイコードを書くこと、あるいはデプロイ自体を実行することも信頼しなければならなくなる。そうでなければSREがボトルネックになる。そしてその時になって初めて、自分のキャリアの残りについて不安を感じるべきだ（あるいは、雇用主がLLMは十分だと判断して、不完全でも私を解雇するかもしれない）。

すべてのソフトウェアには賞味期限がある。寿命を延ばすことはできるが、技術は進み続ける。5年前にバックエンドで標準とされていたものが、今日では全く違って見えるかもしれない。それは良いことだと思う。Railsはその時代、特に2007年から2015年頃には非常にうまく機能したが、より新しく能力の高い言語やランタイムが成熟するにつれて、古さを見せ始めた。

今ではほとんど何でもはるかに少ない労力で移植できること、あるいは既存のスタックを今日のパフォーマンス期待、要件、エンジニアリング標準に合わせて近代化できることを祝うべきだ。

Railsスタックをコーディングして保守している。エンドポイントが応答するまでの時間の約20%はRubyで費やされている。New RelicによるとApdexは99で、エンドポイントが100ms以上かかることは非常に稀だ。ほとんどは80ms未満で応答する。LLMで移植することもできる（おそらくいつかするだろう）が、エンドユーザーの応答パフォーマンスは動機にはならない。

切り替えを考える理由は、Shopifyのネイティブアプリが、信じられないほど迅速にテストできる超高速なプロダクトコアへと移行し、遅いUXレイヤーを別に保っているという話を読んだことだ。そのモデルが未来だと思うし、その世界ではRailsはかなり死んだように見え始める。

Ruby+Railsから、選択の余地がなかった他のフレームワーク（プロジェクトを引き継いだ）を経て、新しい避難所へ移った：Kotlin+http4kだ。

Kotlinは型付きの非常に受け入れ可能なRubyだ。新しいオプショナル型付きRubyよりもさらに良い。同じように読め、非常に似たように書け、非常に似た「スタイル」のコードを生み出す。私はFP側にいたい。Kotlinは（Rubyのように）それを許容する。そこに多少のOOがあっても気にしない。Kotlinは（Rubyのように）それも許容する。利点ははるかに大きなコミュニティ、うまく機能するJetBrains製品（Kotlin用の無料版もある）、そしてJVM（Javaエコシステムとの相互運用により使えるライブラリがたくさんある）。

http4kはRubyのRackのようなライブラリだ。もう少し多くのことをするが、本質的には似ている。

SPAよりSSRが好きだ。RubyではHAMLを使っていた。今はkotlinx.htmlを使う。これは「ただのKotlin」で（Kotlinとしてコンパイルされ、ブレークポイントを置け、必要な場所にロジックの断片を——もちろんKotlinで——混ぜられる）。HAML（やERBなど）よりずっと良い。

RubyのORMは好きになれなかった。そもそもORMが好きではない。だからSQL文の文字列に関数をラップする。SQLの補間はJdbiで行う。非常によく機能し、ORMはない。

テストスイートは非常に速く実行され、ライブDBでテストする。すべてのSQL文がまだ機能することをテストする（SQL文ごとに1テスト、行デコードが機能することを確認するために空でない結果で）。

すべてのライブラリ（JAR）を合わせて11MB。それだけ！小さなライブラリが本当に好きだ。参考までにSpringBoot（JavaのRails）や […]