AIエージェントが「リファクタリングの反射」を消し去る
AI Agents and the Refactoring That Never Happens
AIエージェントを日常的に使う開発者の間で、複雑化したコードのリファクタリングを先延ばしにする傾向が広がっている。人間はコードに迷うことで「これは手に負えない」と気づき、リファクタリングのきっかけを得ていた。しかし、エージェントは迷わないため、そのシグナルが発火せず、コードは複雑化の一途をたどる。その結果、人間がコードを理解できなくなり、レビューが形骸化し、エージェントへの盲信が生まれる危険性がある。モジュール化は人間の認知限界への譲歩であると同時に、エージェントの精度向上とトークンコスト削減にもつながる。著者は、エージェントに任せきりにせず、人間が意識的にリファクタリングの判断を下すことの重要性を説く。
「エージェントが迷わないことは便利だが、『エージェントが理解できる』ことと『システムが健全である』ことは同じではない。前者はエージェントの能力の問題であり、後者は私たちの能力の問題だ。」
HNでの議論
64- bunderbunder
「AIエージェントは迷わない」という主張には同意できません。私が観察したのは、むしろ彼らは「迷っている感覚」を経験しない、ということです。これはかなり異なります。
この夏、私はコーディングエージェントを使って、深く複雑なデータ処理パイプラインを解きほぐす作業にかなりの時間を費やしました。そのパイプライン自体もエージェントによって構築されたもので、驚くほど短時間で作られました。しかし、エラーだらけで大量の不良データを生成していることも明らかになっていました。
私がすぐに気づいたのは、私の質問の半分以上に対して、非常に自信満々に間違った回答が返ってくるということでした。そして、現在取り組んでいる問題を最終的に診断できたとしても、バグ修正をエージェントに任せるのは難しいと感じました。エージェントは私よりもデータフローを追跡するのがさらに苦手だったからです（この機会に、速いことが必ずしも良いとは限らないという点を考慮に入れてください）。それはまさに「猿の手」のようなものでした。確かに、私が依頼した特定のバグは修正してくれますが、その過程で新しい欠陥を導入するのが一般的でした。そして、はい、私は最新かつ最高のモデルすべてでこの問題に直面していました。
最終的に私は、このコードベースにおいて、エージェントは確かに深く、どうしようもなく迷っていたと結論付けました。（編集：おそらく、このコードがそもそもこれほど悪くなったのは、構築に使われたエージェントがしばらく迷っていたが、その問題を認識してオペレーターの注意を引くことができなかったからでしょう。）
- joshstrange
一方、私は何年も（あるいは何十年も）人間が書いてきたコードを、可能な限りリファクタリングしているところです。私が引き継いだり、作成に加わったり、その上に構築したりした混乱を、きれいで整然としたものに変えることは、私のお気に入りのLLMの使い方かもしれません。個人的なプロジェクトや、時間があったときに何年もかけて進化してきたコードベースも同様で、私が望むほど「クリーン」に保たれていなかったものが、ようやく整理されました。
私は常に自分のコードがクリーンで追いかけやすいものであることを望んでいましたが、人生、締め切り、優先順位の変化などがそれを妨げていました。今、ようやく私個人の理想郷を実現できます。
とはいえ、過度に抽象化しすぎたりするとコードが追いかけにくくなるため、モデルをその方向に導かないようにしなければなりませんでした。
- simonw
コーディングエージェントを利用できるようになったことで、リファクタリングできる悪いコードパターンに対して、以前よりもはるかに寛容でなくなったことに気づきました。
リファクタリングにはかつて非常に現実的なコストがかかりました。それは、新機能の開発から割かなければならないかなりの時間でした。
今では、リファクタリングの可能性に気づいたら、非同期のコーディングエージェント（またはワークツリーなど）でプロンプトを実行し、20分後に戻ってきて、それを受け入れるか、少し調整するか、放棄するかを選べます。私のコストはほとんどゼロです。
- joshka
この多くは、さまざまなベンチマークを満たすコードを生成するようにエージェントを訓練することと、以前は不適応だったものへの反応の組み合わせによるものだと思います。つまり、ポストトレーニングでモデルから明示的に訓練されたものです。モデルがデフォルトでコードを書く傾向に組み込まれていない、長期的なソフトウェアエンジニアリングの原則が多く欠けていると思います。
モデルのポストトレーニングを行う人々は、大規模で複雑なソフトウェアシステムで働いた経験の少ない若い研究者である傾向があり、そのためここで何が重要かについての彼らのセンスはあまり発達していないのではないかと推測しています。
しかし、これは適切な初期指示（「実装のトレードオフを選択するときは、問題を解決するために必要な正確なコードだけを実装するのではなく、長期的な保守性とコードの理解しやすさを優先してください。など。思考の連鎖には、将来のエージェントセッションで繰り返される必要がある情報が含まれることが多いので、それをコードや外部ドキュメントに永続化して、将来のセッションとユーザーの理解が尊重されるようにしてください」）で導くことができる領域です。
また、変更後のステップとして同様の効果を得ることもできます。そして、エージェントを使って、生成されたコードの問題に対処するための一般的な行動様式にこの層を組み込むことができます。しかし、すべてのAIラボが行うべきことの1つは、実際のプロジェクトのAGENTS.mdを、実際のプロジェクトの失敗モードのハードな表現として見ることです[…]
- moezd
AIエージェントは、特にコードベースがすでに手に負えなくなっている場合、常に迷います。
あなたの規律は、機能開発マニアに飛び込む前に、自分のコードをすでに理解しているか、標準の明確なベースラインを確立している場合にのみ報われます。そして、それは毎ターン強制される必要があります。さもなければ、コード生成の奔流が玄関のドアを簡単にノックダウンしてしまいます。