編集: 姜篇
DHH：「I have not written... any of the code.」/ DHH：Quattroにデプロイしたコードは、私が手書きしたものは一行もありません。
この発言をしたのは、Ruby on Railsの生みの親、David Heinemeier Hansson氏。開発者にはDHHとして知られています。
注記：David Heinemeier Hansson氏は、開発者には一般にDHHと呼ばれています。Ruby on Railsの創設者であり、37signalsの共同創設者兼CTO。Railsは当初Basecampの開発プロセスの中で誕生し、その後GitHub、Shopify、Airbnbなど多くのインターネット製品で採用されました。
一年前、DHHはAIによるコード補完を好まず、エディタにチャットボックスを組み込むことにも消極的でした。
しかし、最近公開されたLex Fridmanのインタビューでは、全く異なる答えを述べています。Omarchy Quattroの過去2か月の新規コードは、すべてAgentに任せたと。
続けて、彼はある経験を話しました。
デザイナーのチームがAIを活用して大量のPRを提出しました。個々に見れば、それぞれに理由があります。しかし、合わせると、システムアーキテクチャが壊れてしまいました。
コード生成が安価になるにつれ、開発者に降りかかる問題は減りません。それは「どう書くか」から「誰が判断し、誰が検収し、誰が全体に責任を持つか」に移っただけです。
以下は、Lex FridmanによるDHHへのインタビューを翻訳・整理したものです。
DHHがAgentによるコード作成の全責任について語る
13か月、AIを拒否していた彼が「Or 100」に
Lex氏は、AIが書いたコードの割合が5%、20%から80%に達したと述べました。DHHは即座に言いました。
DHH：「Or 100.」/ DHH：いや、100%だ。
これは軽口ではありません。
DHHは、13か月前のAIプログラミング体験に興味を持てなかったと振り返ります。自動補完は思考を中断させ、チャットボックスは文脈を何度も手動で転送する必要がありました。モデルは助けてくれるものの、常に監視が必要な助手のままでした。
Agentがこの対話を変えました。
現在、彼は問題と大まかな方向性をAgentに任せます。Agentは自身でリポジトリを読み、関連ファイルを探し、提案し、コードを修正し、テストを実行して結果を持ち帰ります。DHHはこのインタビューで、モデルがどれだけ文法を書けるかではなく、完全なタスクを引き受けるようになったことを強調しました。
以前は、彼は「どう実装するか」を先に考え、ツールに数行のコードを補完させる必要がありました。現在は、Agentが逆に「この件はこの方向に進めたい」と教えてくれます。
DHHがAgentの100%到達可能性について語る
2か月間コードを書かなかったが、まだ何を一行ずつ確認しているのか
Omarchy Quattroは、DHHが最近最も力を入れているプロジェクトです。彼は、過去2か月にデプロイしたコードは、自分が一行も手書きしていないと言います。
この言葉は「プログラマーはコードを書く必要がなくなった」という意味ではありません。
DHHは開発を辞めていません。彼はすべての変更の全体像を見ており、モデル層や重要なビジネスロジックに関わる部分は、依然として一行ずつ確認します。一般のコードはAgentに任せられますが、アーキテクチャの方向性、データ制約、重要な境界は一緒に任せるわけにはいきません。
彼の仕事場も変わりました。Neovimはもはやコードを手書きするためではなく、プロジェクトを閲覧し、diffを確認し、Agentが何をしたかを検証するために使われています。
DHHのやり方は一言で要約できます：実装権は委譲できるが、判断権は委譲できない。
一般のチームにとって、この境界は「AIがどれだけコードを書けるか」よりも実用的です。データベースモデル、権限、課金、並行処理、データ移行などで誤りがあれば、テストに合格しても変更をデプロイできるとは限りません。Agentは実装を提供できますが、人間はどの箇所を一行ずつ確認する価値があるかを知る必要があります。
各PRは理にかなっているが、システムは壊れた
インタビューの中で最も警戒すべき事例は、Basecamp 5からのものです。
デザインチームがVibe Codingを使い始めた後、PRの提出速度は明らかに速くなりました。それぞれのPRは、なぜそれが合理的かを説明できます。問題は、これらの変更の間に共通のアーキテクチャ制約がないことです。
DHH：これらの変更を合わせると、システムアーキテクチャを破壊しました。
DHHがVibe Codingによるアーキテクチャ破壊について語る
AIプログラミングは、このような錯覚を簡単に生み出します。局所的には速く完了するが、全体的な負債は背後で蓄積されるのです。
あるAgentがログインを変更し、別のAgentがキャッシュを変更し、さらにもう一つのAgentが共通コンポーネントを抽象化します。3つのタスクがテストを通過しても、それらが同じ境界を採用しているとは限りません。重複ロジック、暗黙の依存関係、スタイルの分裂は、後々のイテレーションで一緒に露呈することがよくあります。
DHHはそれでもVibe Codingを否定しませんでした。彼が示した対処法は非常に工学的です：より多くの人に実装能力を与えつつ、アーキテクチャレビューをより早い段階に引き上げる。
以前は、アーキテクチャの問題はコードレビューで発見されることがよくありました。Agentが並行して作業するようになると、すべてのPRが生成された後に見るのでは遅すぎます。タスクの分割時に、どのモジュールに触れてはいけないか、どの抽象化を再利用する必要があるか、データがどのように流れるか、変更間の統括責任者を明確に書く必要があります。
一人で16本のAgentスレッドを同時に実行、開発者は総合スケジューラに
DHH：当初はtmuxで並行Agentを管理していましたが、ウィンドウの切り替えや通知待ちが面倒になり、Herdrを作りました。これはtmuxセッションと通知を接続し、あるAgentが確認を必要としたり、タスクを完了したり、エラーが発生したりしたときに呼び出します。
彼の日常的な規模は、4〜5台のマシンで約16本のAgentスレッドを同時に実行するまでに達しています。
DHHが16本のAgentスレッドについて語る
この作業方法は一見うまくいっているように見えますが、新しいボトルネックがすぐに現れました。
16のAgentが同時に結果を生み出すとき、人間がリアルタイムで一つずつ並走することはできません。開発者は、どのタスクを並列実行できるか、どの変更が同じコードに触れるか、どの結果が前のタスクの完了を待つ必要があるかを先に判断する必要があります。
並行Agentは、境界が独立したタスクに最適です。依存関係のアップグレード、テストの追加、マイグレーションスクリプトの生成、重複コードの整理、異なるバグの調査などです。同じ状態やアーキテクチャに関わる作業では、スレッドを増やすほど衝突は収拾がつかなくなります。
Agentを管理するには、単に「完了」通知を見るだけでは不十分です。各タスクは少なくとも4つの情報を持ち帰る必要があります：変更概要、テスト結果、リスクポイント、ロールバック方法。どれか一つ欠けても、人間はリポジトリに戻って文脈を補完する必要があります。
書いた行数を競うのはやめよう。コード行数はもはや意味がない
Agentは1日で数千行のコードを生成できます。コード量でエンジニアを評価し続ければ、より多くの無効な変更を助長するだけです。
DHH：「lines of code is a stupid metric.」/ DHH：コード行数は愚かな指標だ。
DHHがコード行数の無意味さについて語る
DHHはその後、評価基準を製品に戻しました：何行書いたかではなく、何を作り出したかだ。
開発チームにとって、これは業績評価やプロジェクトのカンバンも変える必要があることを意味します。
あるAgentが5000行のコードを生成しても、ユーザー体験の改善や障害率の低下につながらなければ、その5000行は維持コストを増やすだけです。別のエンジニアが300行の旧ロジックを削除してリリース速度を倍にした方が、価値ははるかに高いのです。
より適切な指標には、問題が解決したか、変更が保守可能か、オンライン指標が改善したか、障害率が低下したか、納期が短縮されたかなどがあります。コードはこれらの結果を実現する材料であり、結果そのものではありません。
機械的なコーディングは脅威にさらされるが、製品を作れる人にはまだチャンスがある
DHHは雇用問題を避けませんでした。もし明日仕事を探さなければならないなら、手書きのコードで以前のような報酬を得るのは難しいだろうと彼は考えています。この仕事を25年間続けてきましたが、現在ではモデルがその中でますます多くの機械的な部分を担えるようになっています。
DHH：「the mechanical process is under threat.」/ DHH：機械的なコーディングの工程は脅威にさらされている。
DHHが機械的なコーディングの脅威について語る
しかし、彼は「プログラミングが好き」ということを二つに分解しました。
もし人が手で構文を打ち込み、APIを覚え、実装の詳細をすべて自分で行うことを最も楽しむなら、今後の変化には適応しにくいでしょう。もし実際に好きなのが、物を作り上げ、問題を解決し、製品が形になるのを見ることなら、Agentはそれをより早く実現してくれます。
DHH自身がその例です。彼は、コードがプログラムを出現させるからこそ、初期にコードを書くのが好きでした。その後、大規模プロジェクトや長期のサイクル、保守作業によって、その即時フィードバックは薄れていきました。AIは彼に再び素早く物を作る感覚をもたらしました。
開発者の価値が消えるわけではありませんが、タスクの上流と結果の下流に移動します。前段では問題の定義、解決策の選択、境界の制約。後段では結果の検収、失敗への対処、システムの保守です。
最後に
DHHの変化は非常に象徴的です。
一年前、彼はAI補完を好みませんでした。今では、Agentに新規コーディングをすべて任せ、10数本の並行スレッドを管理しながら、ソフトウェアをモデルに完全に自治させるのではなく、アーキテクチャ、レビュー、結果により多くの注意を注いでいます。
手書きコードがゼロになる時期はまだ来ていません。コードは依然として理解する必要があり、重要なロジックは依然として確認する必要があります。ただ、実装速度が急激に上がったとき、開発者の難題は変わっています：問題を明確に伝える方法、複数のAgentが同じアーキテクチャに沿って作業する方法、そして「それぞれは理にかなっているが、合わせると危険な」変更をリリース前に見つける方法です。
Agentはコードを書き終えることができます。システムが最終的にどのような形になるか、その責任を負うのは依然として人間です。