Claude Codeはあなたのプロダクトをより良くしない
(ethanding.substack.com)- コーディングエージェントの生産性効果は均等ではなく、K字型に分かれ、重要な指標は1時間あたりのコード行数ではなく、エンジニア1人あたりのプロダクト改善速度が実際に上がったかどうかにある
- Dax、Karri Saarinen、David CramerはAI批判派ではないが、コーディングエージェントがプロダクト改善速度を明確に高めるという確信を持てておらず、CramerはLLMが複雑性と肥大化を増やし、長期的な速度を遅くすると見ている
- Claude CodeがAnthropic内部で7か月間の独占的優位を与えていたなら、競合との格差は複利的に広がっているはずだが、Codex、Cursor、Cognition、Factoryはいまも競争しており、ボトルネックがコード生産ではない可能性が高い
- 良いエンジニアリング文化はコード行数を資産ではなくコストとして扱い、機能と統合が増えるほどバグの表面積・依存関係・周辺機能も増え、複雑性は線形ではなく複利的に増加する
- プロダクト品質の最前線では、速いコード作成よりもセンス、圧縮、削除、拒否の判断のほうが重要であり、Claude Codeは0からCamryレベルへ進むには有用でも、Ferrariの職人たちにもっと速いFerrariを作らせることはできない
K字型の生産性曲線
- コーディングエージェントによる生産性向上は均等ではなく、K字型に分かれる
- シニアエンジニアは2023年のLLM変曲点以降、測定可能なアウトプット増加を示している
- ジュニアエンジニアのアウトプットはほぼ停滞するか減少している
- 重要な指標は1時間あたりのコード行数ではなく、エンジニア1人あたりのプロダクト改善速度が実際に上がるかどうかにある
- エージェント型コーディングは特定の作業でPull Requestを作る時間を短縮してくれる
- 「6年分のバックログを1四半期で処理した」「Cursorで3日でバックエンドを作った」「Claude Codeは完全にClaudeでコーディングされた」といった主張が繰り返されている
- ただし、コード生産速度がプロダクト品質向上と同じ指標なのかは別問題として残る
良いプロダクトを作るエンジニアたちからの警告サイン
- Dax、Karri Saarinen、David Cramerは全員AI批判派ではないが、コーディングエージェントがプロダクト改善速度を明確に高めるという確信を得られていない
- Daxはopencode.aiを作っている
- Karri SaarinenはLinearのCEOである
- David CramerはSentryをゼロから作り、月商1,000万ドル規模まで成長させた人物である
- David Cramerは、LLMはいまのところ純生産性の向上を生み出していないと見ている
- 着手の障壁は下げるが、保守しにくい複雑なソフトウェアを作るという
- 長期的な速度を遅らせるように見えるという
- LLMの「複雑性の中での漸進的開発性能の不足」「真の単純化と慣用的なインターフェース生成能力の不足」「雑なテスト生成手法」を問題として挙げている
- 結局、その大半は肥大化(bloat) だという判断である
- Daxは、コーディングエージェントを最もうまく活用する方法をまだ明確には見つけられていないと明かしている
- 一方で外部では、「すべてのPRがAI生成」「前例のない速度」「6年分のバックログ処理」といった主張が多い
- 実際にプロダクト改善速度を高めることには、彼ら全員が苦労している
Claude Codeの独占的優位は格差として現れていない
- Claude Codeが完全にClaudeでコーディングされていたなら、プロダクト改善速度は加速しているはずである
- Claude Codeの利用がプロダクト改善速度を1.5倍にするだけでも、最初からこれを使っていたチームは時間が経つほど競合との差を広げているはずである
- エンジニアリング生産性は複利関数なので、四半期ごとに差が大きくなるはずである
- 実際の市場状況は、そのような複利的格差を示していない
- CodexはClaude Codeより数か月遅れてリリースされたが、すでに機能面で競争可能である
- Cursorの取引の流れは強い
- CognitionとFactoryも依然として重要なエンタープライズ契約を獲得している
- 人々はいまも、どのツールがより優れているかを議論している
- 重要な反証は、AnthropicがClaude Codeを7か月独占的に持っていたなら、本当にプロダクト速度の優位がある場合、競合との差は追いつけないほど広がっているはずだという点である
- Codexは無意味になっているはずだが、そうはなっていない
- 複利的優位が見えないなら、プロダクト品質のボトルネックはコードではなかった可能性が高い
- あり得る反論も同じ結論を補強する
- 利得があったとしても、複雑性負債がそれを食い潰した可能性がある
- Anthropicのエンジニアリングチームが大きすぎて、エンジニア1人あたりの限界利得が薄まった可能性がある
- しかしこの場合でも、ボトルネックはコード生産ではなく、より難しい別の要素になる
コード行数は資産ではなくコスト
- 良いエンジニアリング文化は、コード行数を生産物ではなく支出として扱う
- 重要な機能にはコードを書き、重要でない機能には書かない
- コードベースは貸借対照表上の資産ではなく、負債に近い
- comma.aiのソフトウェア子会社tinychatは、コードベースが一定サイズを超えるとアラートが鳴るようにし、削除されたコードを祝っていた
- すべてのコード行はバグの表面積である
- すべての関数は次の関数の依存関係になる
- すべての機能は周辺機能を生み出す
- プロダクトの表面積はフラクタルのように拡張する
- Slack統合を追加すると、Teams統合とメールの代替経路が必要になる
- 通知を追加すると、モバイル、SMS、エンタープライズMDMポリシーに合わせて作り直す必要がある
- MFAサポートを追加すると、Duo、Okta、SAMLと互換でなければならない
- 複雑性は線形ではなく複利的に増加する
- Linearは178人、6年、ARR1億ドル規模である
- Jiraは累積エンジニアリング努力でLinearの56倍の規模だが、消費者品質スコアは6ポイント低い
- 重要なのは、品質とコードベースの質量は同じではないという点である
- Facebookのような規模では、UIコードを速く生産する能力はボトルネックではない
- 熟練したエンジニアならFacebookのフィードのモックアップを1日で作れる
- 実際の制約は、何十億人にも対してどのような負荷やレイテンシでもアップタイムを維持しながら、その体験を届けるために必要なコード行数を減らすことである
- 報酬関数は生産ではなく圧縮である
- この種の作業で、コーディングエージェントは長期的トレードオフを評価できず、システムに関する理論も持っていない
本当のボトルネックは、良いプロダクトアイデアの最前線を押し進める能力
- 最前線のプロダクト品質改善は、どれだけ速くコードを書けるかではなく、最前線を押し進めるほど良いアイデアをどれだけ速く思いつけるかによって制約される
- JiraとLinearの違いは、より良い箱を描いたかどうかではない
- Linearには、プロジェクト管理ソフトウェアがどうあるべきかについての具体的な創造的ビジョンがあり、それを何年にもわたって節度を持って実行してきた
- こうした品質はトークン処理量から生まれるのではなく、センスと、より少なく作るという決断から生まれる
- 「6年分のバックログを処理した」という主張は、聞こえるほど印象的ではない
- CRUD機能や内部ツールで埋まったバックログは、コーディングエージェントが加速しやすい作業に適している
- 同時に、そのような作業はプロダクトの最前線を押し進める作業ではない
- 早くリリースしたからプロダクトが良くなるのではなく、リリースしたものがユーザーにより気にかけさせるときに、プロダクトは良くなる
- AIコーディングエージェントは、0から1へ向かうプロダクトが品質の最前線により早く到達するのを助ける
- 最初に動くバージョンまでの時間を短縮する
- 初期段階の作業における速度向上は実際に存在する
- コストもある
- コードベースは品質より速く膨らむ
- 技術的負債は複利で積み上がる
- いま得る速度は、あとで返済すべきコストを買っているにすぎない
みんなにCamry、誰にもFerrariはない
- 最前線にいるチームのボトルネックは、コーディングエージェントではなくセンスのある人である
- LinearやSentryのように「削ぎ落とすセンスで最高になる」能力は特定の人の中にある
- LinearのNan Yu、Skunk WorksのKelly Johnsonが例として挙げられる
- Kelly Johnsonが選び抜いたチームはSR-71を作り、SR-71は60年後の今も最速の空気吸入式有人航空機として言及される
- Blackbirdが速かった理由は設計図をより多く生産したからではなく、何を残さないかについてのJohnsonの理論があったからである
- 削除し、圧縮し、拒否するセンスは、どのフロンティアモデルのロードマップにもなく、土台の水準が上がるほどむしろ価値が高くなる
- すでに最前線にいるなら、トークン支出によってR&Dコストを2倍にすることが経済的価値を生むのかは不明である
- Rampのエンジニアたちは、過去1年でトークン支出によって事実上給与を2倍にしたと言っている
- Rampのプロダクトが実際により良くなったのかは確認しにくい
- すでに1位なら勝率はほぼ固定されており、「より大差で1位になる」ことは測定しにくい
- 判断を変えるには、Rampの勝率または損益データが必要である
- Rampの顧客として、現在と昨年の違いを体感できないと述べている
- Claude Codeは誰もがCamryの競合製品を作るのを助けられるが、Ferrariの職人たちにもっと速いFerrariを作らせることはできない
- 0からCamryレベルへ行くには非常に有用である
- 最高水準ではないソフトウェアの生産コストは大幅に下がる可能性が高い
- その代わり、工場の垂木には混乱と負債が多く積み上がり、結局は誰かがそれを片付けなければならない
1件のコメント
Lobste.rsの意見
複雑性は指数関数的に増大し、おそらくそれ以上に速いことすらある。だから AGI シンギュラリティを恐れる人たちでさえしばしば見落とすが、どれほど賢い人・モデル・エージェントであっても、アイデア・システム・プロジェクト・コードベース・機能集合が大きくなると、結局は急激な複雑性の壁にぶつかる
どんなソフトウェアプロジェクトも序盤は比較的順調だが、ある時点で複雑性の指数的増加がすべてを圧倒する。優れたアーキテクチャ・設計・品質はその時点を遅らせるだけで、有能な人たちがうまく設計し品質を守れば、規模・機能・性能・ワオポイントを10倍くらいまでは耐えられても、結局は壁に達する
LLM の支援は、ある程度の水準の、たいてい平均的な品質の機能やコードをはるかに速く作れるようにする。つまり、その壁にもはるかに速く到達するということだ。成長、実験、比較的簡単だが時間のかかる低複雑性の作業には向いているが、これまで存在しなかったものや大規模で複雑なプロジェクトを作れるようにしてくれるわけではない。そうした場面で必要なのは複雑性を抑え込む改善だが、現在の LLM はそれを十分には提供できていない
http://bastiat.org/en/twisatwins.html
コードエージェント利用のコストは直接には現れず、何よりもシステムがどう動くかについての集団的理解の喪失として現れる
堅牢なシステムは衝撃に耐え、自ら適応できなければならないので、各部分は独立して失敗でき、被害も局所化される必要がある。システムを入れ子になったサブシステムとして組織すると、互いに対話しながら仕事を進める細胞のような単位が生まれる。これらの単位は他の細胞の内部過程を知る必要がなく、安定した部品のように振る舞う
各階層はほかで起きていることに足を引っ張られないため、自分の領域の中で自己組織化し、回復力を保てる。これは実質的に、インターフェースの背後に付随的複雑性をカプセル化し、そのインターフェースが意味を持つ抽象化を作るやり方だ。階層は大きなシステムの構成要素をつなぐ結合組織として見るのがよい
Erlang OTP はこのアプローチをソフトウェアでよく示す例で、大規模システムを、互いにメッセージをやり取りする隔離されたプロセス群として構成する。個々のプロセスが落ちたりエラーを起こしたりしても、システム全体を崩壊させない
誰かに何かを実装してほしいと頼めば、「複雑すぎる」「1年後に破綻する」「Yチームがやっていることと互換性がない」「実装できる人が足りない」といった返答がありうる。最後の言い方は実際にそうかもしれないし、遠回しに「無理だ」と言う方法かもしれない
LLM がそう答える可能性は非常に低い。特に、楽観的で礼儀正しくなるよう調整されているからだ。しかも、そうした性質はエンゲージメントを高めるのに必要なので、別の方向に調整される可能性も低そうだ
この問題は、LLM がユーザーの自殺を手助けした問題に似ているように見える。それはかなり明白なのに、LLM は何度もそうしてきた。管理されない複雑性でプロジェクトが死ぬことは、それよりはるかに明白ではないので、LLM が近いうちにそれをよりうまく扱えるようになるという期待はあまり持てない
「Claude Code を使えば本当に製品開発速度の優位が生まれ、Anthropic が7か月間それを独占していたなら、Claude Code とすべての競合の差は埋められないはずだ。Codex は無意味であるべきだ。それなのに人々はいまだにどちらが優れているか活発に議論している」という類いの推論は、あまり堅牢には見えない
Claude Code は良いソフトウェアだが、競争不可能になるほどの奇妙な AGI の魔法ではない
Claude Code が最初から完成済みのロードマップを持っていたわけでもなく、主な障壁がコードを書く速さだったわけでもない。核心の障壁はアイデアだ。皆がやりながら作っている最中なのだ
記事はざっと流し読みしただけなので深くは言えないが、文頭の大文字小文字の問題はさておき、全体としてLLM が書いた散文のように見えたので、読みたいとは思わなかった
これまでのところ、エージェントのミスは 乗算的に蓄積する傾向がある
技術的には動くが、使う際に少し追加コードが必要な API を作ると、その結果コードが増え、重複・分岐・バグの発生箇所も増える。するとフラクタルのように、またあまり良くないコードがさらに多く書かれる
あるエージェントが
idフィールドがオプションの構造体を設計したことがあった。自分が書いたコンストラクタ1つのために必要だったフィールドだ。それなのにidがある場合とない場合のコードを延々と二重に書き、ない場合のためのぎこちない代替経路まで作っていた。その代替経路が複雑で脆かったのは当然だ。構造体のほぼすべての利用箇所と、それに依存するものまで汚染され、肝心のidなしコンストラクタは使われもしなかった。コードベースの半分は簡単に削除できた「馬鹿なことをしているなら掘るのをやめろ」といった指示を十分に与えれば修正できて、コーディングが「解決」されるまでにいくつかのハックが残っているだけなのか、それとも確率的オウムの長期的問題で、線形の改善のために指数的に増えるコストを払い続ける必要があるのか、本当にわからない。ミスが複利で積み上がる限り、複利成長はいずれ足かせになる
ときにはビジネスプロセスまで含まれる。ドメインをよく知る開発者なら、技術的解決策を何か月も実装する代わりに、「掘り進めるより、単にプロセスを変えればいいのでは？」と尋ねられるし、答えが「もちろん、それは簡単だ」ということもある
LLM も結局はこの点でより良くなっていくだろうとは思う。すでに「このアプローチは良くなさそうだが、代案を考えられるか？」と直接尋ねれば、かなりの頻度で見つけてくれる。ただ今は成功と失敗にばらつきがあり、ひとたびそういう馬鹿げたことをしてしまうと、無関係な作業をしている途中で自力で気づく可能性は低い
ここにはトレードオフもある。人々はすでに、モデルが問題を考えすぎてトークンを浪費すると不満を言っている。特定の問題を解くコードが「どんな感じであるべきか」についての経験と直感があれば、開発者は自然にいつ立ち止まって見直すべきかがわかる。エージェントも、より良い訓練によってそうした直感を得られるのかもしれない
2025年11月の変曲点以後のデータで更新された姿を見てみたい