それは本当に疑問だね。変更が役立つかもしれないけど、いくつかの例を見てみたいな。認知的複雑性のメトリクスは信じてないけど、変更が確実に認知的複雑性を増しているのはちょっと興味深い。

「作業しているエリアでは、リファクタリングして整頓し、「技術的負債」を片付けるべきだってこと。」これはひどい実践で、修正が必要な典型的なジュニアの行動だね。自分が書いたものでない限り、チェスタートンのフェンスが適用される。なぜそのコードが今のように存在しているのか、深く考える必要があるけど、それは今のタスクには含まれない。小さなUI修正のために1000行のPRに対処するほど最悪なことはないよ。

もう少しニュアンスがあると思う。多くの場合、抽象化がしっかりしてるから、そのコードエリアで作業できるんだよね。バグを追跡したり、機能を拡張したりするのに。でも時々、行き詰まることがあって、既存の実装をハックするか、再考するかの選択になる。LLMを使うと、どうやって再考するの？再考することに意味はあるの？そもそも、その決定は自分には見えないし。

「変更を加える」と「リファクタリング」にはかなり大きな違いがある。もしLLMが必要なリファクタリングを適切に行っているなら素晴らしいけど、実際にそうだとは全く自信がないな。

モデルが既存のロジックと同じことをする新しいコードを書くのはリファクタリングじゃない。必要なことを正確にやっている関数が目の前にあっても、時々そうなる。さらに悪いのは、既存の関数を修正して、動作を維持するつもりが、他の使用ケースでは壊れてしまうこと。頑張ったとは思うけど、最悪だね。クラス間で状態を変更して、副作用に気づかない。デッドロックや単純なバグが発生する。

何かに手を加えるとき、彼らはしばしば改善しない。私が「リファクタリング」と呼ぶものではなく、むしろスロットマシンのアームを引っ張るような感じ。

ほんとに？リファクタリングと新機能（バグ修正も）を同じコミットに入れるのが賢いって聞いたことないな。俺が知ってる人たちみんな、どこでもそれは良くないって考えてるよ。コードレビューでは有害だし、直球で拒否されることもある。「進めながらリファクタリング」ってのは、機能を追加したりバグを修正した直後にリファクタリングすることを指してるんであって、この記事のエージェントがやってることとは違うよね。

実際には、ほとんど行われていなかったけど、今はLLMが実際にやっていて、その欠点に気づいているところだ。今日はこれに関して少し時間を使ったけど、私にとっての本当の問題は、エージェントが行ったリファクタリングがひどかったことだ。私はただ、その変更をやめさせたかっただけで、何を修正すべきか、どう修正すべきかをもっと明確に指示したかったんだ。

トレードオフは状況によるから、エージェントがプロジェクトを自分で見て判断できるものじゃないんだよね。同じプロジェクト内でも、特定のPRに対しては自由に修正したい部分と、diffやテストの範囲を減らすために固定したい部分がある。エージェントにどれくらい積極的に既存のコードを修正していいか、どの部分かを事前に説明するようにしてるけど、成功することもあればそうでないこともある。たいていは、重複や抽象化を乱用することになっても、最小限のdiffを優先しちゃうんだよね。もし誰かがもっと良い方法を持ってたら、ぜひ教えてほしいな。