- 人工知能が開発者を「管理者」や「編集者」にするといった通説に反して、著者は 「外科医のようにコーディングする」 というアプローチを提案し、中核となる作業に集中する方法を強調
- 外科医が補助スタッフの支援を受けて手術の核心部分にだけ集中するように、AIツールを通じて付随業務を委任し、開発者は本質的な問題解決に専念
- 主要な作業（例: UIプロトタイピング）は依然として人が直接行う一方、ドキュメント作成・バグ修正・コード探索などの反復作業はAIエージェントが処理
- AIに単純な反復作業を任せることで、地位の階層問題なしに grunt work を委任でき、24時間利用可能であるため深夜や昼休みにも作業を指示可能
- この方法は Andrej Karpathyの「autonomy slider」概念 と結びついており、作業の自律性レベルに応じてAI活用戦略を変えるべきことを示唆
外科医のようにコーディングする: 核心概念
- AIが開発者をマネージャーやエディターにする という一般的な予測に反対し、外科医(Surgeon) のように働く方法を提案
- 外科医は自ら手術を行うが、支援チームの助けによって準備作業や副次的な業務を処理してもらい、固有の専門性が必要な 中核作業 にのみ集中
- 開発者もAIを補助スタッフのように活用して 中核的で創造的な作業に集中 できる
- 著者はUIプロトタイパーとしてAIツールを活用し、意味のある作業に100%の時間を投じる ことを目標にしている
- AIが処理できる付随業務を委任することで生産性を最大化
AIに委任できる付随業務
- AIが十分に遂行可能な 補助的作業の一覧
- 大規模な変更前にコードベースに関するガイドを作成
- 大きな変更の試行に向けた 「スパイク(spike)」コードの草案生成
- 明確な仕様がある TypeScriptエラーやバグの修正
- 現在開発中の機能に関する ドキュメント作成
- これらの作業は 非同期でバックグラウンド実行 が可能
- 昼休みや夜間にもAIが作業を進め、翌日にすぐレビューできる
- これにより「準備の整った手術室に入る外科医」のように、すべての準備が終わった状態で中核コーディングに集中 できる
自律性スライダー(Mind the autonomy slider)
- AIの活用方法には 中核作業と補助作業の間に大きな違い がある
- 中核となるデザイン・プロトタイピングは依然として人が直接行い、速いフィードバックループと高い可視性 が重要
- 一方、付随作業は AIに長時間自律的に任せる方法 が効率的
- 長時間の無監督セッションには Claude Code を、最近では Codex CLI を好んでいる
- この違いは Andrej Karpathyの「autonomy slider」概念 に似ている
- 自律性のレベルに応じて必要なツールや考え方が異なり、これを混同するのは危険
AIと「ソフトウェア外科医チーム」という概念
- 「ソフトウェア外科医」概念は1975年のFred Brooks『The Mythical Man-Month』で Harlan Mills が提案した古いアイデア
- 1人の 「chief programmer」 を中心に、「copilot」と管理スタッフ が支援する構造
- 過去にはこの補助役割を 人間 が担っていたが、AIがそれを経済的に実現可能な形で置き換えている
- 著者はこの変化が単なるコスト削減以上の意味を持つと指摘
- 地位のヒエラルキー(status hierarchy) の問題を緩和
- 反復的で退屈な grunt work をAIに委任することで、チーム内の偏った業務分担の問題を解消
- AIは24時間利用可能なため、人間のインターンには不可能な 夜間の調査やコード分析作業 も実行可能
Notionと「外科医のように働くこと」の拡張
- 著者は、自身が勤務する Notion でこのアプローチが実際に実装されていると説明
- 会社として AIコーディングツールの使用を積極的に支援 しており、コードベースもそれに合わせて設計
- とりわけ大規模なコードベースに新たに参加した開発者にとって 生産性向上の効果 が大きい
- プロダクトの側面でもNotionは、プログラマーを超えてあらゆる知識労働者に「外科医のように働く方法」を広げようとしている
- 核心目標は 中核業務を委任することではなく、重要ではない付随的で反復的な業務を識別・委任 し、最も重要な仕事に集中 できるよう支援すること
7件のコメント
中核業務に集中し、周辺業務はAIに任せろという意味に見えます。これにはかなり同意しますし、一部のSaaSで代替されるような中核ドメインではない業務や管理業務は、AIで置き換えることが可能そうです。 さらに議論になりそうなのは、中核業務をAIで代替できるかどうかでしょう。結局は、より結果の良いほうへ流れが続いていくはずです。IOIやLeetCodeの問題を解くのを見ると、AIが人間よりはるかに優れたコーディング能力を見せることもあります。軽々しく予測するのは私の能力を超えているようなので、見守るしかないと思います。
この比喩は本質を捉えられていない、完全に間違った比較だと思う。
手術は取り返しのつかない作業で、プログラミングは取り返しのつく（いわゆるセーブ＆ロード可能な）作業だ。
手術も取り返しがつくようになれば、外科医も手術のできる部下にやらせて、自分は後ろで設計やレビュー、マネジメントをするほうがより効率的だ。間違っても元に戻せば済むのだから。
同意します。似たように、ソフトウェアエンジニアリングを建設業のエンジニアリングと取り違えているケースも多いと思います。
本物の外科医のようにコーディングしたいなら、コーディングはコンピュータ工学科を卒業した人だけができるようにすべきなんじゃないか。コンピュータ工学科の定員を増やしたら、プログラマーたちも団結してストライキでもすべきだし……
なんでコーディング助手はいないの!?
wwwwwwwwwwwwwwwwwwwwwwwww
Hacker Newsのコメント
駆け出しの外科医が、看護師や麻酔科医がミスを防いでくれると信じて手術を始めたら、患者をすぐに死なせてしまいかねない
手術チームが必要だからといって、主任外科医としての訓練が不要になるわけではない
経験のない外科医が「看護師がメスを渡してくれるのだから、わざわざ学ぶ必要はない」と考えるのが問題だ
結局、患者を犠牲にして学ばなければならないのならそうするのだろうが、そうでないならまず医学部に行くべきだ
そのため、文章全体から ダニング＝クルーガー効果 が感じられる（能力の低い人ほど、自分の能力を実際よりはるかに高く評価してしまう認知バイアス）
私はずっと前から、ソフトウェアエンジニアなら The Mythical Man-Month を読むべきだと主張してきた
この25年ほどで、ウォーターフォールからアジャイルへの移行のように、開発手法は急激に変わった
だが、LLMベースの開発（Codex、Claude Codeなど）をしていると、むしろ70〜80年代式の開発パターンに戻っているように感じる
今はまるで 大聖堂を設計する ように構造を考え、細部の実装は委任できるようになった
手術は一度に一人しか作業できないが、ソフトウェアは複数人が同時に手を入れられる
むしろ スポーツチーム に近く、私たちは練習やコーチングが足りないため完成度に時間がかかる
コーディングより設計に集中できるようになった
実際に高層ビルを建てるなら、鋼材の品質やボルトの出どころ まで気にしなければならない
そうしたことを無視するのは危険だ
この比喩は文字通りにも比喩としても間違っている
外科医は単なる作業者ではなく、手術全体を管理 するマネージャーであり、実際には麻酔科医が最も重要だ
また、「単純労働（grunt work）」という概念自体が誤った見方だ
自分を外科医に、他人を補助人員に見立てる態度は 自己中心的な観点 だ
Brooksの「Chief Programmer」概念のように、主席プログラマーはチームの支援によって仕事ができる
筆者はジュニアを単なる下級労働力ではなく メンティー と見ている
完璧な比喩ではないが、AIコーディングツールに関するメッセージは尊重に値する
歴史的にも、麻酔なしで手術が行われていたことを例に挙げている
たとえばプログラマーを 大工 にたとえるフレームワークの説明のように、実際の職人はすべての部分を完璧に磨き上げるわけではない
この比喩が気に入ったので、今後使ってみようと思う
別の比喩として 古典画家のアトリエ を挙げることもできる
レンブラントやルーベンスは弟子たちにキャンバスの準備や一部の彩色をさせ、大家は核心部分だけを自ら描いた
一方、ロマン主義以降は、芸術家が一人であらゆるものを完成させるという理想が生まれた
ターナーのように 一人で創作 したいプログラマーもいるが、私はレンブラントのように大きな絵を描き、細部はAIやジュニアに任せたい
コード品質が高くなければ、ユーザーフィードバックに素早く対応できない
単に「素早くコーディングして終わり」ではなく、変更コストを下げる構造 が重要だ
レンブラント式のアプローチが良いコードにつながるなら構わないが、その証拠はまだ不足している
私もClaudeを数か月使ってみたが、自分で直接コーディングするほうが効率的だと感じた
ただ今回、MySQL 8→9への大規模DBアップグレードの際に、Claudeに 問題になりそうなクエリ を探してもらったところ、驚くほど大半が当たっていた
完璧ではなかったが、デバッグ時間 を大幅に減らしてくれた
LLMがコードを直接書くことよりも、リスクポイントを見つける役割 のほうがはるかに価値があると感じる
古いコードベースにスタックトレースを貼ると、LLMが 初期デバッグの方向性 を示してくれる
パフォーマンス問題を直すときも、コードパスが同じ結果を返すか検証させられる
まだコード生成は自動補完レベルだが、効率は確実に上がる
Dan Northの Software Faster という発表を思い出した
「ソフトウェアは手術のように、問題を解決するのに必要な最小限だけをやれ」という言葉が印象的だった
だが今回の文章は、その哲学とは距離がある
そのせいで今の私は、切断手術 を頻繁に行う外科医になった気分だ
Chief Programmer Team の構造が再び流行しつつあるようだ
今回は人間の代わりに AIエージェント がチームに含まれる形だ
Fred Brooksのアイデアが再び注目を集めている
10倍生産性の開発者（10x-er） に有能なチームを付ければ、会議やJira管理に浪費される時間を減らせる
高額な報酬を払うのだから、その時間はできるだけ価値ある形で使うべきだ
自律性のスペクトラム、あるいは 委任のスペクトラム を理解することが、AIコーディングツールをうまく使う鍵だ
エンジニアは委任に慣れていないが、創業者はこれをより早く身につける傾向がある
「外科医は重要な仕事に集中する」という表現に対して、実際にはあらゆる支援業務が 同じくらい重要 だと指摘している
謙虚に周囲の支援を尊重し、彼らを同じように サポート すべきだ