Agent時代のrefactoring、価値はinput tokenにも表れる

Martin Fowlerの新しい記事は、refactoringを美意識ではなくagentic codingの運用コストとして捉え直している。対象は、ほぼcoding agentによって作られた約15万行のアプリケーションだ。その中でRustのdata access layerが17,155行の単一ファイルに膨らみ、HTTP request setupやJSON encode/decodeが何度も繰り返されていた。

実験の作り方が重要だ。まず同じ代表的な変更をfresh sub-agentに実行させ、baselineを取る。その後、正しさを保つrefactoringを一段階ずつ適用し、変更は毎回捨てて、まったく同じpromptを別のagentに再実行させる。人間の学習効果を避け、codebaseの構造変化がtoken使用量にどう効くかを見る設計である。

結果ははっきりしている。同じ変更に必要なinput tokenは159,564から27,360へ落ち、約83%減った。data access layer全体の行数は大きく減っていないが、最大ファイルは17,155行から3,695行まで小さくなった。つまり、単純にコードを削ったからではなく、agentが必要な範囲を見つけやすくなったことが効いている。

HNの議論では、LLMは整ったコードから大きな恩恵を受けるが、自力でその構造を作るのは得意ではないという経験談が目立った。別の読者は、refactoringの前提は堅いtestsだというFowlerの基本原則を指摘していた。agentを使う開発では、testsはregression防止だけでなく、人間とモデルが共有する短いspecにもなる。

Fowler自身も限界を明確にしている。Claudeは適切なrefactoringを自分で見つけるのが苦手で、人間が手順をかなり具体的に与える必要があった。refactoring計画と実行に使ったtokenコストもまだ正確には測れていない。それでも、この実験はagent-heavyな開発でコード構造を語る新しい物差しを示す。良い構造は読みやすさだけでなく、将来の変更ごとのinput costを下げる可能性がある。出典はMartin FowlerとHN議論。