逆に、私もLLMを使ってるんだけど（最近の驚きだよね、わかってる）、すでに慣れている分野ではスピードアップを感じているし、新しい分野にもすぐに入れるようになってる。明らかな利点は否定できないし、それを無視するのは無知に見える。私の一番の懸念は、これに関連することから来てる：何を学ぶべきかを決めるのが上手くないんじゃないかってこと。ちょっとした例：regex。私の知る限り、LLMはregexを書くのが平均的な開発者よりもずっと上手い。regexは多くの人にとって数ヶ月使われないことがあるけど、たまに完璧なregexの問題に出くわすと、LLMに頼って書いてもらうのが楽なんだよね。時間をかけて試行錯誤するよりも。regexはフラストレーションがたまるし、気まぐれだから、みんな経験してると思う。でも、そうするとregexを学ばなくなる。じゃあ、regexが何をできるかの直感はどこから来るの？LLMがなければregexを書くことができなくなるの？人々はregexのリソースを書くのをやめるのかな？私の懸念は、LLMに任せられることがあるけど、自分の判断が完璧じゃないってこと。全体的には価値があると思うけど、何を失っているのかもわからないし、それが不安なんだ。

「エージェント」の常用がソフトウェアエンジニアリング（またはどんな分野でも）スキルの衰退につながるかどうか Well、ほとんどの神経心理学者は「はい、衰退するでしょう」と同意すると思うよ。使わなければ、失うからね。 > じゃあ、この状況での理想的な「中間地点」って何だろう？ 私もこれについてよく考えてる。今のところの計画は、「ここにアウトソースしたい潜在的な努力がある」という感覚を認識することを自分にトレーニングして、時々はアウトソースせずに手でやることを選ぶこと。特に個人プロジェクトでは、仕事のプロジェクトよりもスピードを求められないからね。でも、まだこれに関しては決まってない。どんなアイデアでも歓迎だよ！

ここで理想的な中間地点が一つあるとは思わないな。私には、何が最適かは誰がいつかによって変わるように感じる。個人的には、これは個人の勾配降下のようなものだと思ってる。問題に取り組んでいて、どこかに解決策があって、周りのツールやテクニックの勾配を感じることができる。どの道を歩いても、何かのスキルを改善するために時間を投資していることになる。だから、自分が進みたい方向に最も良いと思う道を選ぶべきだよ。ある人には、LLMが優秀なコーダーで、どんどん良くなっているのが明らかで、そういう人はその勾配に乗るべきだと思う。逆に、全く違うことが明らかだと感じる人もいるし、そういう人には自分の伝統的なコーディングスキルを磨く道を進むことを勧めるよ。何も明らかでない比較的平坦な場所にいる人もいて、そういう人は探求し続けて、両方のアプローチでベストを尽くす必要があるかもしれない。

「“エージェント”のハーネスを常に使うことで、ソフトウェアエンジニアリング（いや、どんな分野でも）における筋力が萎縮するんじゃないかって気になる。実際そうなるだろうけど、その影響がどれほど大きいかは分からない。計算機があるからそろばんの使い方を知らないっていうのと同じで、低レベルのスキルを維持したいと思う人は、結局やるだろうし。」

コーデックスに自分の欲しいものを作らせることもできるけど、基礎を学ぶためにわざとゆっくり進めてるんだ。参考になるフレームを持ちたいからね（これが唯一のプロジェクトになるとは思ってないし）。一方で、今までの一回限りのPythonスクリプトは、もうほとんど目を通さなくなった。正直、それが一番怖い部分なんだよね。

利点は思っているほど明白じゃないってことを指摘しておくよ。開発者たちはずっとLLMの生産性向上を過大評価してきたし、エージェントAIでもそれは変わらないみたい。特に、エージェントの前のLLMと結果が似ているのが印象的だよ。長期的なデータがまったくないこともあって、利点は（弱く）否定できると思う。雇用市場ではそうじゃないかもしれないけど、少なくとも自分にとってはね。

「この状況での理想的な“中間地点”は何だろう？私はエージェントを使ってコーディングしてる。でも、IDEでAIのスマートコンプリートがあった初期の頃を思い出す。プログラマーとして、解決策の設計や実装にもっと関わらなきゃいけなかったから、実装が進むにつれて自分が関与している感覚があった。今はエージェントがいるから、エージェントがやったことを追いかけるのに時間を使って、コードレビューに多くの時間を取られてる。結局、同じ場所にたどり着くのかもしれないけど、実装を作るのとコードレビューをするのでは、前者の方がやりがいがあるし、メンタルツールを鋭く保つのに役立つと思う。」

「『エージェント』を常に使うことで、ソフトウェアエンジニアリング（あるいは他の分野）の筋肉が衰えるんじゃないかって気になる。」コンパイラの進化が、ソフトウェアエンジニアがどれだけ理解してるか、アセンブリ言語に落ちる頻度に影響を与えたのは確かだよね。それが99%の開発者にとって問題になるのか？多分ならないと思う。LLMは次の進化だと思ってる。下のレイヤー、書かれているコードの形に気を使う人もまだいるだろうけど、時間が経つにつれて、手作りのASMから高級言語への移行と同じように、コンパイラはより良く、効率的で信頼できるものになると思う。多分、生成されたコードをあまりチェックしなくても良くなるんじゃないかな、少なくとも大半のコードについては。これが問題になるのか？うん、人間とインターフェースすることを目的としたコードには（ほとんどがそうだけど）問題になるかも。質は多分良くなるし、大した問題にはならないと思う。

車がなかったら、もっと健康的で、常にカーディオ運動をしているから、もっと遠くまで歩いたり走ったりできたと思う。でも、移動距離は今よりずっと少なかっただろうね。車と同じように、LLMも世界を変えていくから、俺たちの脳じゃスーパーマーケットにすら行けなくなるかも。だって、すぐに5マイル離れたところにあって、車（もしくはローカルのLLM自転車）が必要になるから。

「エージェントの常用がソフトウェアエンジニアリング（あるいは他のどんな分野でも）スキルの萎縮を引き起こすのではないかと考えずにはいられない。前はそう思ってたけど、実際にはスキルをトレーニングしたり強化したり、新しいことを学ぶのにも使えるんだ。コーディングの面接があって、事前に準備のための簡単な資料を送ってくれて、面接で役立ちそうなトピックやコンセプト、技術スタック、期待されること、注意すべきことが書いてあった。もちろん、正確なリストではないし、他にも評価の基準があるだろうけど、いくつかのトピックが久しぶりだったから、Claudeにサンプルプロジェクトを12個生成させて、各プロジェクトにタスクのリストを1つのドキュメントに、解決策を別のドキュメントにまとめてもらって、取り組んだ。途中で、codexを使って面接官の役割を演じさせて、自分の考えやアイデアを話しながらフィードバックをもらったり、選択肢を問い直したりした。確かに、2つ半、もしくは3つのプロジェクトしか進められなかったけど、面接の準備を楽しんだのは初めてだった。そして、その過程でいくつかのことを学んだ。最も難しかったのは、LLMにタスクをやらせないようにすることだったけど、もう少し時間と明確な指示、分離があれば解決できる問題だったよ。