/note/tech

エージェント時代のソフトウェア開発:手書きコードの終了と全面的な楽観主義

要約:

■ 1. 肖像画から写真へ: 技術革新と職人技の変容

  • かつての肖像画制作:
    • 人の姿を残す最先端技術は高度な訓練を受けた画家による肖像画だった
    • 巨匠の前に何時間も座り、完成まで数か月を要した
    • 王族や上流ブルジョワ階級に限られた特権的な営みだった
    • 依頼主の意向で描き直しもあり、多大な時間と費用がかかった
    • 1781年のレイノルズ、1801年のゴヤ、1886年のトゥクセンと技法の進歩は緩やかだった
    • トゥクセンは王家の肖像画の完成に3年を費やした
  • 写真の登場と大衆化:
    • 1840年頃に写真技術が登場した
    • 1900年にコダックが約1ドルの「ブローニー」を大量生産し、写真を一般大衆へ開放した
    • 現実を忠実に模写する職人技は経済的に成立しなくなった
  • 画家の職能の再定義:
    • 画家たちは現実の再現を超えた新たな芸術表現へ舵を切った
    • 例としてピカソのキュビズムやスケーエン派の印象派がある
  • 写真のさらなる民主化:
    • トゥクセンはDHHの高祖父であり、晩年の1920年代には自らの写真撮影を受け入れた
    • 1980年代にはフィルム購入や現像の手間があり、撮影枚数は控えめだった
    • デジタル化とスマートフォンの普及で、2026年には年間約2兆枚が撮影されている
  • 技術の民主化の構造:
    • 停滞と急激な跳躍を繰り返し、特権的で高コストな行為を摩擦のない日常へ変える
    • 同じ構造変化が現在のソフトウェア業界で起きている

■ 2. 2025年11月24日の転換点と「幻滅の谷」

  • ソフトウェア開発の「ブローニー」:
    • 2025年11月24日のOpus 4.5リリースが転換点
    • 手頃なハーネスを通じて新しい知性とペアを組む開発体験が広く開かれた
    • 歴史はこの日を境に「エージェント以前」と「エージェント以後」に分かれる
  • オープンウェイトモデルの追い上げ:
    • オープンウェイトモデルも急速に追い上げた
    • Kimi K2.5の高速モードで毎秒200トークンの知性が提供されることに衝撃を受けた
  • 2026年2月から5月の「幻滅の谷」:
    • Opus 4.6などの新モデルが期待ほどの向上を示さなかった
    • ベンチマークで頭打ちに見えるリリースが続いた
    • 指数関数的な進化は終わったという悲観論が漂った
  • 停滞の打破:
    • 6月のFable 5やMythosで、エージェントはそのままマージできる品質のコードを出力する水準に達した
    • 実装の詳細を指示せずとも、問題定義やアイデアを渡すだけで解決策を発展させられる
  • フロンティアモデルの多極化:
    • 9月のGPT-6 Astraの登場でフロンティアモデルの独占懸念が払拭された
    • 1週間後のDeepSeek-4-1 Flashにより、最高峰の知性が米巨大テックに留まらないことが示された

■ 3. 10倍プログラマー論争の終焉と「1,000倍」の現実味

  • 10倍プログラマー論争:
    • 1968年のACM論文に端を発し、40年以上争われてきた
    • かつての測定では5倍から30倍、平均10倍の生産性格差が示された
    • この論争はすでに過去のものになった
  • 生産性格差の拡大:
    • 道具なしのプログラマーとエージェントを使いこなすプログラマーの差は100倍に達する
    • 最低水準と最高水準の間には1,000倍の差が生じているという見解も現実味を帯びる
    • DHHが直近20か月で書いたコード量は、それ以前の21年間の半分に達した
  • 行数指標の限界を差し引いても圧倒的な加速:
    • コード行数の曖昧さやRubyの高い抽象度を考慮しても開発の加速は圧倒的
  • Railsの原点との重なり:
    • 2005年の講演でRailsは「Convention over Configuration」を掲げた
    • その喜びは設定ファイルやマッピングなど「書かずに済んだコードの多さ」にあった
    • エージェントで膨大な実装作業を書かずに済む今日の興奮と完全に重なる

■ 4. 37signalsにおける「手書きコードの終了」

  • 「Pencils Down」の決定:
    • 講演の数週間前、日常業務として人間が手でコードを書くことをやめた
    • 手書きは例外であり、Sentryで検知されるバグと同様にプロセス不具合のサインとして扱う
    • エージェントが失敗した際に一時的に修正を書くことはある
    • 本質的な対処はエージェントという「機械・工場」を修繕し自律的に動かすこと
  • 会場の実態:
    • 毎週かなりの量の手書きコードを書く開発者は数名にとどまった
    • この転換は極論ではなく開発現場の既成事実になりつつある
  • Basecamp 5での失敗:
    • 春先にデザイナーに新機能をバイブコーディングで実装させる実験を行った
    • 個々のプルリクエストは成立しているように見えた
    • 20個、30個と積み重なるとアーキテクチャが「スイスチーズのように穴だらけ」になった
    • 技術が未成熟と判断し、手動レビューとプログラマー主導の体制へ戻した
  • 撤退の再評価:
    • その撤退は時期尚早だった
    • 数か月後のFable 5などを使えば破綻は回避できた可能性が高い
    • 最も重要な問いは、この知性の爆発からいかに最大の成果を引き出すか

■ 5. HEY Next: Webアプリの解体とネイティブ回帰

  • HEY Nextの最大の変更点:
    • メールサービスHEYの新版(仮称)でWebアプリとしての構築をやめた
  • Webアプリという妥協:
    • HEYがWebアプリだったのはWebが理想だったからではない
    • 少人数チームが高い生産性を保つための現実的な妥協策だった
    • 小規模チームが複数プラットフォームのネイティブ実装を個別保守するのは不可能に近かった
    • React NativeやHotwire Nativeはその妥協を埋めるために存在した
  • エージェントによる制約の崩壊:
    • 講演の約1週間前に着手し、人間がコードを1行も書かずに複数のネイティブアプリを構築中
    • 作業はプロンプトの指示と反復修正のみで進む
    • Windowsアプリは最初の出力から20分後に修正版が届き、実用水準へ急速に引き上げられた
  • ネイティブ回帰の不可避性:
    • ShopifyはShopアプリをReact Nativeからフルネイティブへ6人程度で短期間に書き直した
    • 開発コストの激減で、本質的にネイティブであるべきアプリはWebからネイティブへ回帰する

■ 6. バックエンドの再構築: Rustの隠蔽と極限の効率化

  • Rustでの全面再構築:
    • ネイティブ化によりHTMLをレンダリングするWebサーバーの必要性が薄れた
    • バックエンドはメールサーバーとしての本質に特化しRustで再構築した
  • Rustへの評価の逆転:
    • DHHはRustを「過去40年間で発明された中で最も醜悪なプログラミング言語」と評してきた
    • 人間がコードを一切見なくて済む前提なら評価は正反対になる
    • エージェントはRustに長け、人間は中身をブラックボックスとして扱う分業が成立した
  • 劇的な性能向上:
    • CPU使用率は99%、メモリ使用量は95%削減された
    • 複数ホストが必要な理由は冗長性の確保のみ
    • HEYのピーク時トラフィック全体を理論上Raspberry Pi 1台で処理できる
    • 低レイヤーの実装効率を人間が苦痛なく享受できるようになった
  • エージェントとの協業スタイル:
    • 内部システム「Chef Marie」などで実験を重ねた
    • チャットで生成を待つ同期的作業より、非同期でタスクを任せ完了後にレビューする方が効果的

■ 7. RubyとRailsの存在意義

  • Webの価値は健在:
    • インストール不要のWebのアクセシビリティは依然として強力
    • 一時的な共同作業者を受け入れるBasecampのようなアプリにはWebが不可欠
  • エージェント時代のRailsの優位性:
    • 「Convention over Configuration」は指示のコンテキストを最小化し、高いトークン効率をもたらす
    • 一人で全体を統括できるフルスタックの枠組みは、個人の開発能力を拡張する思想と合致する
  • Railsのエージェント評価(Evals):
    • Rails Foundationの委託でEvil Martiansが実施している
    • 実際の参照アプリをベースに機能実装を行わせるテスト
    • 初期基準ではすぐに95%の完了率で飽和し、難易度の高い基準への更新が必要になった
  • エージェントへの指示の仕方:
    • 人間が低レベルの実装を細かく指定しすぎるとかえって逆効果になる
    • 実装を知らない「素人」の目線で高い抽象度から要求を出す方が良い結果を生む
  • DHHの業務実態の変化:
    • 過去21年間はコードの過半がRubyだったが、直近1年でRubyの割合は約3%に低下した
    • かつて年間約3万行の本番Rubyコードを書いていた
    • 2026年8月には単月で15万行を生成させ、長期平均の約60倍に達した
    • 大半は冗長なRustコードだが、扱えるコードの桁数自体が根本から変わった

■ 8. 「英語」という新しい言語と手書きプログラミングからの引退

  • 英語というプログラミング言語:
    • 生涯愛したRubyより優れた言語は「英語」
    • 決定性や厳密さに多少の曖昧さは残る
    • それでもいかなる人工言語よりも表現力に富み、深く満足のいく体験をもたらす
  • プロのプログラマーからの引退:
    • DHHは2026年3月頃に「プロのプログラマー」を引退した
    • 20年以上手でコードを彫ることを愛してきたからこそ、後悔ではなく感謝とともに見送る
  • 手書きコードの経済的合理性の喪失:
    • 手書きは大多数の企業や開発者にとって経済合理性のない活動になった
    • この現実は年内にも業界全体へ定着する
    • その先には知性を操縦して壮大なプロダクトを創出する新たなエンジニア像がある

■ 9. ソフトウェアアーキテクチャの再評価とCLIの責務

  • 抽象化とDRY原則の見直し:
    • 抽象化や重複排除は人間の認知負荷を減らし変更箇所を一元化する工夫だった
    • 多数の自律プロセスが同時に修正する環境では、過度な抽象化が並行作業のボトルネックになる
    • 重複コードの同期コストがゼロに近づき、抽象化と重複のトレードオフは根本から見直すべき
    • 新しいアーキテクチャの設計図はまだなく、現場の開発者自身が定義していく途上にある
  • アプリ内AIチャットボットへの疑問:
    • ユーザーは各アプリが個別に用意する「コンシェルジュ」を求めていない
    • 自分の「執事(ローカルエージェント)」を連れて歩き、あらゆるツールを一括で操作したい
  • CLIこそ最重要のインターフェース:
    • アプリが提供すべきはチャットUIではなく、エージェントが外部から操作できるCLI
    • BasecampやHEYをCLI経由で連携させれば、人間が画面に触れずに業務を完結できる
  • HEY CLIによる検索実験:
    • 対象は「スニーカーとポッドキャストに関する、差出人も年代も定かでない5年前のメール」
    • Elasticsearchのキーワード検索では不可能だった
    • エージェントは文脈と概念を手がかりに数分で特定した
  • すべての開発者は自社アプリにエージェント向けCLIを用意すべき

■ 10. Omarchyと軽量ワンショットアプリ

  • 全能感のOS全体への拡張:
    • あらゆる不具合を直し、望むものを即座に作れる感覚は個別サービスを超えてOS全体に及ぶ
    • DHHはこの3か月、LinuxディストリビューションOmarchyに注力してきた
    • Omarchyには約2,000万ドルの資金が集まっている
  • インストール時間の短縮:
    • 前年のRails Worldでは3分33秒だった
    • 最新のハイスペックノートPCでは35秒になった
    • ラボ内ではOS全体のインストールが9秒を記録した
  • 卓越の追求の肯定:
    • Mitchell Hashimotoの「卓越の追求に正当化はいらない」という言葉のとおり、妥協のない改善を肯定する
  • デスクトップアプリのワンショット開発:
    • 電卓アプリ: ChatGPT生成の外観案を渡し、C++とQtの知識なしに7分で作成、15分後に公開
    • 執筆環境: iA Writerの代替エディタをコードを1行も見ずにC++で自作
    • 動画トリミングツール(mnicut): 必要に応じ即座に生成しディストリビューションへ統合
    • プレゼンツール(Hype): 基調講演の数日前に着手、Markdownベースで高速描画、バイナリは0.5MB
  • 肥大化したソフトウェアの是正:
    • 過去20年、業界は開発効率と引き換えにアプリの肥大化と低速化を放置してきた
    • 例として音楽プレーヤーが1.2GBを占有する状況がある
    • エージェントによる最適化を一晩実行すれば、極小で軽快なソフトウェアを取り戻せる

■ 11. P(bloom)の選択: 歴史に基づく全面的な楽観主義

  • 短期的なセキュリティ課題:
    • エージェントの暴走や敵対的挙動、CVEやライブラリ脆弱性などの課題は存在する
    • Mikeによる「HotCell」のように、隔離技術や防御策を工学的に開発すれば解決できる
  • 悲観的な経済予測は外れ続けてきた:
    • 1950年代の米国でATM導入時、3万人の窓口係が18か月で職を失うというパニックが起きた
    • 実際には支店運営コストが下がり、銀行は店舗数を増やした
    • 窓口係の業務は現金の受け渡しからローン提案などへ移った
    • 2010年時点で窓口係の雇用は4万人に増加していた
    • ジェボンズのパラドックスのとおり、効率化は需要の拡大を呼び起こす
  • P(doom)よりP(bloom):
    • オッペンハイマーは核兵器開発後に終末的恐怖に囚われ、トルーマンに面会して突き放された
    • 破滅の確率「P(doom)」を恐れて過度な規制や停滞に陥るべきではない
    • 技術がもたらす繁栄の確率「P(bloom)」に賭けるべき
    • 原子力の平和利用が恐怖で40年近く停滞した過ちをAIで繰り返してはならない
  • 「コンピューターの宗教改革」:
    • エージェントの普及はプログラミングを特権的な「聖職者階級」から解放する
    • 誰もが望むものを作れるようになる
  • 前進への呼びかけ:
    • 競争への恐れを捨て、Rails開発者として培った問題解決能力を信じて道具を使い倒すべき
    • 子供たちは先入観なく新しい技術環境に適応していく
    • 不確実な未来への唯一合理的な態度は「全面的な楽観主義(ホワイトピル)」を選び全力で前進すること