AIコーディング時代においても、良いプログラミング習慣は依然として重要です

最近、あるエージェントのベンチマークを行っていて、AIにとってのプログラミングタスクの複雑さを開発者の視点だけで評価できないことに気づきました。
例えばリファクタリングのタスク：数千行の大きなファイルを機能ごとに十数の小さなモジュールに分割する作業です。
このタスクは開発者にとっては実はそれほど難しくなく、主な作業はコードの移動、インポートの整理、コンパイルの検証であり、初心者でもこなせます。
そこで、シンプルなタスクを使ってベンチマークを試みたところ、予想外の結果になりました。
Claude Codeはこのタスクが比較的大きいと判断し、一部を分割してPRを出し、Future workとして段階的に進める提案をしました。
私のエージェントは「強行突破」し、より完全な分割の方向に進めましたが、その代償も明らかでした：Tokenの消費はClaudeの数十倍に達し、その後も大量の時間をファイルの読み込み、コンパイルエラーの修正、再読、再修正に費やしました。
これにより、人にとって簡単に見えるタスクが、エージェントにとっては必ずしも簡単ではないことに気づきました。
人にとっては、多くの場合、「この部分を移動させる」だけのリファクタリングですが、エージェントにとっては、大きなファイルを段階的に読み込み、どの関数やテストが関係しているかを記憶し、複数のファイルにまたがる修正を生成し、最後にコンパイルエラーを一つずつ埋めていく作業です。
見た目は機械的な作業のようですが、実際には高いTokenコストと状態管理コストがかかるタスクに変わってしまいます。
少し前に、AIコーディング時代においては、モジュールの分割などのプログラミング原則はそれほど重要ではなくなる、という意見を耳にしました。
しかし今振り返ると、私はそれにはあまり同意できません。
モジュールの境界が明確で、ファイルの粒度が適切で、依存関係がシンプルであることは、人が読むのに便利なだけでなく、エージェントのタスクの複雑さを低減する助けにもなるからです。
別の観点から見ると、今のエージェントのファイル読み込みや修正ツールは、この種のリファクタリングにはあまり向いていません。
コーディングエージェントがファイルを修正する場合、主にテキストの置換です。
例えばClaude Codeではよくあるのはold_string / new_stringのパターン：古いテキストを提示し、それを新しいテキストに置き換えるというものです。
Codexではapply_patchが一般的で、git diffのようなパッチを生成し、古い内容を新しい内容に置き換えることを表現します。
これらは小規模な修正には適していますが、大きなコードの削除や複数の関数を別のファイルに移動させる場合、モデルはまず元の内容をコンテキストに読み込み、その後に大きな置換やdiffを生成しなければなりません。
そこで私は後からエージェントに、スクリプトやsed、perlのようなツールを使って大きなファイルを粗く分割し、古い内容を直接削除して新しいファイルに書き込み、その後少しずつ修正させるように促しました。
その結果、エージェントの完成度は確かに向上しました。
ただし、エージェントは通常これを行いません。主な理由は、システムのプロンプト内でエージェントに内蔵ツールを使ってファイルを修正させることを強く求めるためです。
さらに一歩進めて考えると、コーディングエージェントにはより高度な編集ツールが必要かもしれません。
単に「テキストを置換する」インターフェースを与えるのではなく、パーサーやLSP、コンパイラを通じてコード構造を構築し、IDEのようにリファクタリング（関数の移動、implブロックの削除、インポートの整理）を行えるようにすることです。
この方面での試みをしている方がいるかどうかはわかりません。
総じて言えば、AIコーディング時代においても、良いプログラミング習慣は価値があります。
早期にハーネスエンジニアリングを通じて、良い習慣をエージェントのデフォルトの作業方式に変えることは、その後のリファクタリングコストを大きく削減します。