鉛筆を置き、目を開く：Rails World の後の Rails 開発者

← ホーム

DHH の Rails World での基調講演を聞いて、ある種の居心地の悪さを覚えた。この感覚は役に立つと思っている。Rails アプリを10年以上書いてきたが、自分が好きな仕事の部分を時代遅れの趣味として扱う覚悟はまだできていない。

ただ、この居心地の悪さをビジネスプランに変えるつもりはない。何が変わり、何が変わっていないのか。agent がコードを書く仕事をより多く担うようになったとき、自分のような開発者に何が提供できるのか。それをはっきりさせたい。

キーボードは仕事の一部にすぎない。責任は最初から最後までついてまわる。

基調講演から読み取ったこと

講演の20:45の箇所で、DHH は 37signals の新しい「pencils down」ポリシーを説明している。手書きのコードは今や通常のワークフローの例外であり、禁止されているわけではない。agent がタスクを処理できない場合、チームは手作業で片づけ、その後ワークフローを改善すればいい。これは一企業としての大胆な選択であって、すべての開発者が明日から従うべき指令ではない。

ずっと引っかかっているのは、彼が語った Basecamp 5 の話だ。デザイナーが何十もの agent 生成の pull request を提出し、一つひとつは単体で見れば筋が通っていたのに、合わせるとアーキテクチャが「スイスチーズ」のようになった。当時チームはプログラマ主導の働き方に戻ったが、DHH は今、より良い agent とより良いワークフローこそが答えだと考えている。あの具体的な問題を agent 主導で修正する過程は示されなかった。僕が受け取った教訓はこうだ。もっともらしい diff をいくら積み上げても、一貫したシステムにはならない。

念のため言っておくと、これは Rails への弔辞ではない。DHH は HEY が進めているネイティブクライアントと Rust バックエンドという方向性を説明し、そのうえでWeb は依然として重要であり、Rails の規約は agent の助けになると論じている。Ruby がすべての場面で勝たなくても、得意な領域で役に立ち続けると思えるなら、それで十分だ。

まずは pencils-down の部分から見るといい。あるいは YouTube で基調講演の全体を視聴することもできる。

僕が抵抗を感じた部分

5月、あるモデルが12分でバックグラウンドジョブの競合状態を直してくれたあと、僕はコーディングが失いつつあるものについて書いた。テストは通った。それでも、バグがなぜ起きたのかをじっくり突き止める過程が恋しかった。次に起きる障害も自分が理解しなければならないのなら、これは単なる懐古趣味ではない。

agent に退屈な部分の下書きをさせたり、アプローチの案を出させたり、自分では試す時間がなかった代替案を探らせたりするのは歓迎だ。メンタルモデルを築く必要があるとき、厄介なコードを少しだけ自分の手で書いても、失敗だとは思わない。ボイラープレートを手で打つのも美徳ではない。本当に役立つ問いはこれだ。目の前のこの具体的なシステムを理解し、安全に保守するには、何が助けになるのか。

大きな数字も真剣に受け止めるべきだ。DHH の100倍から1000倍という比較は、最も支援されたプログラマーと最も支援されていないプログラマーの間の推測であって、普通のチームが実測した速度向上ではない。彼は手書きのコードはほとんどのプログラマーと企業にとって割に合わなくなっており、2026年末までにはほぼすべての領域でそうなると考えている。これは彼の経済的な賭けであって、僕のキャリアに対する実測の締め切りではない。

彼が引用しているのは初期のより単純な Rails agent テストで95%近い成功率だ。基調講演のより難しい機能チケットのスライドでは、示された投入量で最高35%にとどまった。最大投入の評価では、最良のモデルがその20件のチケットで53%の実行を通過したが、追加の時間とコストがかかった。これは本物の進歩だが、本番環境での信頼性を示す指標でも、レビューを省く理由でもない。

僕のキャリアはどうなると思うか

開発者の工数がより少なくて済む仕事はある。企業の採用の仕方も変わるかもしれないし、プロトタイピングが容易になれば、同じことをやろうとする人が増えて競争が激しくなる。DHH は銀行の窓口係のアナロジーで、自動化が新たな需要を生みうると示唆している。言いたいことはわかるが、彼が挙げた歴史的な日付と数字は既存の報道と一致しないし、アナロジーで Rails の採用を予測することはできない。既存の職がすべて安全だと約束するのは不誠実だ。基調講演一つからソフトウェアエンジニアがもう不要になると結論づけるのも、同じくらい不誠実だ。

Ruby を15年以上、Rails アプリを10年以上書いてきた。この経験は「Ruby を打つ」ことをめぐる堀ではない。ある単純な変更がどこから単純でなくなるかを見極めるのに役立つ。僕の Sidekiq から Solid Queue への移行ガイドでは、adapter の切り替えは説明するだけなら簡単だ。本当の仕事は、古いジョブとスケジュールされたタスクを安全に片づけることにある。agent は変更を手伝えるが、全部グリーンの diff だけでは、古いキューに何がまだ積まれているかはわからない。

これは、コードを自分が書いたかどうかに関係なく、私が責任を持ちたい仕事だ。

曖昧な要望を明確な制約に変え、agent に境界のあるタスクを割り当て、浮いた時間をテスト、データの境界、セキュリティ、デプロイ、ロールバックに使う。自分でコードを書くこともある。だが常に意味するのは、何を要求し、何が得られ、ユーザーが何を体験するかをはっきりさせることだ。

DHH はさらに、CLI を備え、ユーザー自身の agent が操作できるアプリも構想している。この方向性は面白く、実際的な問いも引き出す。誰が何をする権限を持つのか、ということだ。

小さな演習

あなたならリリースするか？

各問はまず自分で判断し、それから答えを見てほしい。これがグリーンな diff の裏側にある仕事だ。

ある agent が Sidekiq を Solid Queue に置き換えた。テストは通っている。同じデプロイで古い worker を止めるか？ まだだ。 まず Sidekiq 内のキュー待ち、スケジュール済み、リトライ中のジョブを洗い出す。両方のシステムを並行して動かし、新しいジョブを段階的に移行し、古いキューの排出を見守り、二重実行とロールバックに備える。テストが全部グリーンでも、Redis が空だという保証にはならない。

新しいアプリ CLI を使えば、agent が顧客の問題を調査できる。速く動かすために本番 API key を渡すか？ 無制限のものは渡さない。 スコープが限定され監査可能なコマンドから始める。広範な資格情報を agent の prompt、環境、ツールに晒してはいけない。ネットワークアクセスを制限し、必要な権限だけを与える。信頼できない顧客データを渡せば何をしでかすか試し、不可逆な操作は必ず人が決める。ツールが使えることは、安全であることを意味しない。

鉛筆を置くことには、多少の抵抗がある。だが機会も見えている。Rails の規約、長年のデバッグで培った直感、新しいツールを使う意欲。この組み合わせは役に立つ。目標は、自分が書いたはずのコードを一行残らず守ることではない。チームが信頼できるソフトウェアを届ける手助けをすることだ。