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

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

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

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

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

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

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

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

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

スキルの停滞や萎縮に気づく直感を持っていることは、ラッキーだと思う。これを聞くことができれば助けになるし、楽しいよね。だって、鋭さを保つことは本質的に報われることだから。

なんでLLMに運転させてるの？ 自動承認は切って、エージェントが実行するコマンドはすべて承認しなよ。設計やアーキテクチャの決定をさせないで、自分でどう作るかを選んで、その「クランカー」に何が何だか教えてあげて！ 冗談じゃなくて、AIを道具として扱えば、もっと活用できるよ。10倍の成果は期待できないけど、コードは理解できるようになる。

2. 何も学んでない。自分でやる認知的負荷、たとえシンプルなDockerコマンドを組み立てるだけでも、あまりにも高すぎる。だから、AIを使う「杖」に頼り続けちゃうんだ。失礼なつもりはないけど、これって「あなた」の問題に聞こえるよ。（私もそうだったから）LLMに聞いてみればいいじゃん。「これをどうやって実行するの？」「これが動いているかどうかどうやって確認するの？」とかさ。確かに、何も知らなかったり、彼らが提供するものについて批判的に考える努力をほとんどしなかったら、彼らの答えに騙されて、完全に無関係なことやデタラメを「何かが動いている証拠」と勘違いしちゃうこともある。2、3の他のLLMに聞いてみて、彼らの仕事をチェックして、結論が出るか、バグが見つかるかどうか確認してみて。だけど、あなたは何も知らないようには聞こえない。急いで物事を終わらせようとしていて、手を抜いている感じがする。急いで結果を得ているのに、何を期待してるの？ 彼らの仕事は安いよ。月200ドルのサブスクリプションで、最小限の手間で5万ドル以上の機能を生み出せる。彼らの仕事を拒否することに積極的になって。何度も何度も送り返して、正しくやらせるために、アーキテクチャレビューや正確性、パフォーマンスをチェックさせて。彼らは感情を考慮する必要がある高価な人たちじゃないし、辞められたら代わりが効かないわけでもない。手を抜かせないで。理由はどうあれ、彼らは手を抜くことに積極的だから、何度も言っても無駄だよ。

彼らが自分が書いてないPythonコードを実行するのを見ると、いつも怖くなる。

「python ${エージェントがその場で書いたコード} > EOF」 理論的には、ランダムなシェルコマンドを実行するのと同じくらい危険なんだけど、エージェントはそれをやってるし、やっぱり気持ち悪いなぁ。

認証情報の件について。私が見つけたことはこんな感じ。 Day 1: 認証情報を慎重に扱って、.envを.gitignoreに入れるべき理由や、.envを編集すべき理由を（聞かずに）講義してくる。 Day 2: 繰り返しを頼むと、そのスキルや設定を忘れてしまって、必死にディスク全体を検索して、.envや他の多くのファイルを読み込んで、トークンを持っていることを理解して、手動でcurlコマンドを作成してトークンをテストして、結果を持って戻ってくる。Day 1ではセキュリティの専門家だったのに、Day 2では普通のインターンみたい。

「実際に何が起こっているのか理解できていない」という気持ちには共感する部分もあるけど、この感情はプログラマーがコンパイラが発明されたときに持っていた反応と全く同じだと思う。

「コンパイラが登場したときのこと」 今ではコンパイラに任せることに全く抵抗がなくて、「実際に何が起こっているのか知らない」ことを心配することもない。これらの状況が完全に類似しているとは言わないけど、これが私たちが心配しなくなるものになるのか、それともしばらくの間深刻な懸念になるのか、まだわからないと思う。

普段は、クロードが書いたコードを全部レビューするようにしてるし、自分が書いたコードもクロードにレビューさせてる。だから、だいたい何が起こってるかは理解してるつもり。クロードは時々「型破り」な決定をするけど、大きなコードベースで他のチームメンバーと一緒に作業してると（中にはもう会社を辞めた人もいるかも）、理解できない大きな部分もあって、抽象化されてることもあるんだよね。

これは本当に簡単な問題に思える。LLMに本番環境のクレデンシャルを与えなければいいだけだよ。ローカルやステージング/開発環境で問題を再現できないなら、本番に近い形でデプロイメントインフラを更新する必要がある。環境を区別するために権限を厳密に設定できないなら、そのための権限システムを更新しなきゃ。俺はこのアプローチを守ってるから、あなたが説明しているような問題に似たものは一度も経験したことがないよ。 [1] 問題を診断するために読み取り専用のクレデンシャルを発行することはあるけど、その場合も漏れたときのために非常に短命のトークンしか発行しない。

基本的に3つのモードがあるんだ。1. すべて自分で指定、記述、テストして、AIにクリーンアップさせる。これはアプリケーションのコア部分用。2. AIが関数を書いて、俺が書くためのスタブテストを設定する。ここでは、関数が俺の望むことをしなかったり、やりすぎたりすることが多いから、よく書き直す。こうすることで、ボイラープレートを減らせると思う。3. AIがすべてをやる。これは実験や、削除してもいい部分のため。大体70%の確率で、これらの部分は削除しちゃう。1や2には触れさせないけど、もちろんこれはアーキテクチャがそういう風に設定されている必要がある。だけど、結構いい感じだよ。

エージェント・セーフハウスを使うことを本当におすすめするよ（https://news.ycombinator.com/item?id=47301085）。エージェントに編集すべきでないコンテンツへのアクセスを与えないで、使うべきでないキーも渡さないこと。

100%同意だわ。同時に、この記事やそれに対するコメントは、業界の進展の速さのせいで一瞬のスナップショットみたいに感じる。これらのコーディングモデルは、9ヶ月前よりもかなり良くなってるからね。AIの能力についての不満を読むと、毎回「まだまだだな」って思っちゃう。

でも、自分が知らないことはわからないよね、特にそれが権威を持って話しかけてくるときは。だから、いろんな角度からその仕事をチェックして、正確であることを確認するのは大変だ。最近はAIを使って何かを作るよりも、1つのAIのコンテキストを別のAIと対抗させる（お互いの仕事をレビューする）方にずっと多くの時間を使ってる。利点は、ほとんどが非同期で行われるから、他のことをする自由があることだね。

同様に、これは初期のエージェントの問題のように感じた。