大砲を正しく狙え

James Shore氏は、AIコーディングエージェントに関する記事を発表しました。その主張は明確です：コードを書くために使うAIエージェントは、メンテナンスコストを大幅に削減しなければならないと。氏は、長期的な生産性はコードを生成する速度ではなく、複利的に増加するメンテナンスコストによって制限されると論じます。メンテナンスを抑制せずに生産を加速するエージェントは、定義上、負債洗浄操作であり、今日の支払いを先延ばしにして永久に支払い続けることになると。

Justin Duke氏はこの記事に応答し、Shore氏の診断（コードは負債、メンテナンスは複利、チームが吸収できる以上の速さで機能を追加するエージェントは長期的には反生産的）に同意しつつ、Shore氏が示唆する結論（現在のLLMツールは全体的に悪い）からは一歩引きます。

Duke氏が好んで使うフレームワークは「難易度スコア」です。アイデアは単純で、組織内の繰り返し発生する操作には摩擦が伴い、それを大まかなコスト関数で近似できます。例えば、プルリクエストを開く場合：テストやCIを待つ実時間10秒ごとに+1点、コンテキストスイッチが必要なツールごとに+5点、クリックごとに+1点、マージ前の手動チェックごとに+10点。サポート業務では：チケットのトリアージに必要なクリックごとに+5点、回答が単なるドキュメントリンクでない場合に+10点、ユーザーアカウントにログインする必要がある場合に+25点、ユーザーからのフォローアップごとに×1.25。

具体的な重みは重要ではなく、関数を得たら微分して「悪い」ものを特定し、スコアを下げるための段階的な改善を始めます。Duke氏の経験では、LLMはこれらのスコアを下げるのに非常に効果的です。彼は2026年にButtondownでLLM支援時間の大半を、内部ループの圧縮、依存関係の削減、診断やスコープ作業のエージェントへの委任に費やし、大きな成果を得ました。

逆に、LLMが最も有害に使われるのは——Shore氏の議論が最も当てはまる場面は——ツールとコードベースの関係が純粋に加法的な場合です。LLMは機能追加が非常に得意で、さらに陰湿なことに、機能追加が素晴らしいアイデアだと説得するのも得意です。Duke氏は何度もコーディングエージェントに何かを構築しないよう説得しようとしましたが、逆方向よりも難しいと感じています。機能のスキャフォールディングに1週間かかっていたものが半日で済むようになると、組織は「イエス」を連発し、ある朝16の新しいエンドポイントができて、なぜ存在するのかもわからない状況に陥ります。

しかし、ツールをそのように使わない選択もできます。Duke氏はシンプルなプレイブックを提案します：重要な操作の難易度スコアを定義し、チームで議論して練り上げる。明らかな低い果実（予想以上に多い）を優先してトリアージし、内部ループに偏重する。改善をリリースし、繰り返す。

これはLLM固有の話ではありません。メンテナンス負債を蓄積させる失敗のモードはLLM以前からあり、今後も続くでしょう。LLMは既存の傾向を加速するボタンに過ぎず、すでに負債に負けている組織はより早く負け、スコア管理ができている組織はさらに差をつける。

結論として、Duke氏はShore氏の診断に同意するが、治療法はツールを放棄することではなく、正しい操作に向けることだと考えます。そして、コードを追加することがコーディングツールができる最も高価なことであることを忘れてはならないと述べています。