みんながすぐに理解できる名前だと思うけど、他に何か提案ある？LoopGPTとか？

OPのエージェントの定義には少し異議があるな。個人的には、エージェントは単なるループの中のLLMじゃないと思う。エージェントの定義的な特徴は、LLMの振る舞いが他の論理的なコンポーネントによって制約されたり導かれたりすることだと思う。これらの中には決定論的なものもあれば、MLを使ったもの（LLMを含む）もある。つまり、LLMは何らかの形でプログラムされているってこと。例えば、コード編集後にLLMにテストを構築して実行させるのは、より良いパフォーマンスを引き出すための素晴らしい方法だよ。でも、要するに、決定論的なレイヤー（テスト）がLLMにより有用なことをさせるように促すシステムを設計しているってこと。多くの「エージェント的推論」システムは、実行前にLLMに計画を立てさせるように意図的に強制している。時にはこれらの計画が決定論的に検証できることもあって、計画が良くない場合はLLMが再生成を強いられることもある。LLMが自分で自分をフィードしているという考えは間違ってはいないけど、これらのシステムが有用な理由を見逃していると思う。LLMの振る舞いを監視するさまざまな他のコンポーネントによって意図的に導かれているんだ。

その通り。自然言語がプログラミングに向いてない理由にも関係してるよね。[0] [0]: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667... まあ、確かにLLMはstackoverflowみたいなプログラミングの質問には役立つと思う。でも、SOが衰退してるから、こういう質問に関する最新のデータは減っていくと思う。

コードを書くのは好きだし、LLMが一発でパーサーを作っちゃうのを見るのはちょっと悔しいけど、同時に何時間もかけてパーサーを作るのは、プロジェクトのもっと大きな目標から気をそらすことでもあるんだよね。それに集中できるのはいいことだし。自分が欲しい型や関数のシグネチャをスタブで作っておいて、LLMがそれを埋めてくれたら次に進める。多分、実装にも挑戦するけど、楽しくなくなったらLLMに頼るって感じかな。逆に、LLMのおかげで何かを磨く楽しさに集中できるようになった。大きな変更をするのも「やりたいけど面倒」ってことがなくなったし、例からテストを生成するのも苦痛じゃなくなった。READMEにコードを同期させるのも面倒じゃなくなったし、リファクタリングや改善のアイデアを考えるのも簡単になった。聞いて、ケースを作ってもらえばいいだけだから。もっと野心的になれたり、週末プロジェクトを新しいレベルに引き上げられるのは楽しいよ。考え方を変えれば、ソフトウェア好きなビルダーの楽園みたいだ。もっとコードを磨けるし、プロジェクトをリリースできるし、もっと難しい課題にも挑戦できるし、目標も高く設定できる。だけど、最初はちょっとした resentment を乗り越えるのに時間がかかったな。

逆に聞きたいな、みんなが何を好きなのか？私はすでに何度も解決された問題に対してコードを書くのは楽しめない。辞書を使うように、毎回ハッシュテーブルをゼロから作るわけじゃないし、それは最初の時だけ楽しい。もし「この言語の動くコンパイラをくれ」とか「深さ優先探索を使ってこの問題を解決して」と言えたら、プログラミングが楽しくなくなることはないと思う。自然言語について、そして兄弟コメントへの返答として、同意するよ。自然言語は計算プロセスを説明するには非常に貧弱なツールだ。おもちゃの例にはいいけど、ある程度の洗練されたレベルになると、曖昧なことや完全に矛盾することを言うのが簡単すぎる。でも、ここで誰もLLMを「盲目的に」使えとは言ってない！生成されたかどうかに関わらず、自分の出力には責任があるからね。

この評価には賛成できない。今のところ、LLMが引き継いでいるのは、実装のような繰り返しの作業ばかりだ。私はまだプロジェクトのアーキテクチャを考えたり、LLMには難しい非繰り返しの部分を解決することを楽しんでいる。これが1年後にはなくなるかもしれないし、もしかしたら私は栄光あるプロダクトマネージャーになるかもしれないけど、今は楽しんでるから、実際の思考問題に集中できて、繰り返しのパターンやクズを持ち上げる手助けをしてもらえる。

エージェントの意味ってそこだよね？もしテストカバレッジが完璧だとしたら、AIがコードを書いて、そのセキュリティやスピードについてフィードバックをもらえるってことだし。AIがテストを書く手伝いもしてくれるしね！

これが私に役立つケースだよ（リスト使ってるけど、AI生成じゃないからね…） - 定型的なコード。基本的にマクロやコード生成の必要がなくなる。欠点は遅くなるし、マクロを更新して再生成することができないこと。でも、少し定型的だけど実装によって微妙に違うコードには使えるから、マクロが使えない場合には助かる。 - よく知ってるけど暗記してないAPIを使うとき。Google検索してドキュメントを探す手間が省ける。私は型付き言語を使ってるから、もし間違ったことをしたら型チェッカーがキャッチしてくれるし、結局手動でテストしたり自動テストを設定したりするから、間違ったことをしてもキャッチできるステップはたくさんある。 - プランニング：これは実はLLMの中であまり評価されてない部分だと思う。10ファイル以上の変更が必要なとき、LLMに全ファイルを見てもらって、変更点をMarkdown文書にまとめてもらうのはすごく助かる。時々、そのプランが十分良くて、少し手を加えるだけで「そのままやって」と言えることもあるし、間違ったところがあっても部分的に従いながら修正するのが役立つ。追記：LLMが生成したコードの好きなところは、プロジェクト内のスタイルや命名規則を維持してくれること。疲れてるとそういうことに気を使わなくなるからね。

私が関わっているコードベースでは、複数のファイルを比較的予測可能な方法で変更するタスクがよくある。クリエイティブさや挑戦が少なくて、複数の部分やファイルにタイプするだけの作業が多い。こういうタスクは、物理的にすべてのファイルを開いて、修正する場所を見つけて、コードをタイプする必要があったから、以前は3〜4時間かかってた。でもAIエージェントを使うと、タスクを説明するだけで99%正確にやってくれるから、時間が3〜4時間から3〜4分に短縮された。

最近まで私も同じ気持ちだった（先週の金曜日くらいまで）。WindsurfやCursorのようなツールは役に立つ部分もあるけど、ほとんどの時間は出力を読んで修正するのを待ってるだけ。要するに、ツールを使うためにお金を払ってるのに、トレーニングを手伝ってるような感じ。でも、今ChatGPT PlusでCodexが使えるようになったから、その非同期の流れをすごく評価してる。特に小さな改善や軽微なバグ修正に関しては、明らかに価値があると思う。私がやりたいのは、5〜10のタスクをキューに入れて、作業している間に難しい問題に集中すること。それから、休憩が必要なときにそのPRを見直したりマージしたりする。

こうやって作業するのが好きになってきた。コードのデザインを計画して、LLMに解決策に至るステップを説明する。LLMが次のコードセクションに取り組んでいる間に、読み取り、理解、修正、計画などを進める。並行して作業している感じだね。レストランの料理人になった気分で考えてみて。オーダーが入ったら、料理人はその料理を作るためのステップを計画する。料理人はステーキを焼いて、ブロイラーに入れる。料理人はステーキが焼き上がるのを待たずに、他の問題やタスクに取り組む。ステーキがまだ焼き上がっていなければ、もう一度ブロイラーに戻す。そうでなければ、ステーキをサイドやガーニッシュと一緒に盛り付ける。LLMはオーブンみたいなもので、ツールだね。チーズをフードプロセッサーでおろすのがいい例かも。手でおろすこともできるけど、ソースに入れるなら粒の質は関係ないから、フードプロセッサーを使うことで数分の時間を節約できる。プロの料理人はツールを使って並行してマルチタスクをこなしているから、コーディングも一行ずつ書くリニアな作業から離れていくかもしれない。

これはP!=nP的なものだと思ってる。シンプルな関数を書く必要があるとき、実装するのにかかる時間は、それが自分のニーズに合っているかどうかを確認する時間よりもほぼ常に長くなる。例外もあるけど、全体的にLLMを使ったコーディングではこれが当てはまるように思う。LLMに関数を書かせて、その結果をチェックするのが時間を節約する方法だね。

他の人のコードを読むのが好きじゃないんだよね、笑。自分で仕事してるの？それとも（開発者が1人以上いる）会社で働いてるの？自分のツールのためだけにコードを書くって言ってたから、自分でやってるのかな？俺も他の人のコードを読むのはあんまり好きじゃないけど、分散チームだと必要だし、時々誰かから新しいことを学ぶとインスパイアされることもあるんだ。こういう考え方で何か障害にぶつかったことがあるのか、単に好みなのか、ちょっと気になるな。

何もツールなしではできない人もいるよね。そういう人たちは早期採用者でパワーユーザーで、最新の発見を広めるんだ。GitHubの価値提案は、普通のコーダーでもPRやレビュー、緑の四角、TODOリストの迷路の中で生産的に見えるってことだった。LLMはまた、普通のコーダーが非本質的なツールやエージェントを使いこなすことで生産的に見えるようにしてくれる（それをマネージャーも好む）。

他の誰かや何かに頼ってコードを書かせて、それを読むことの利点がまだ理解できない。多分、鍵はこれだね：私たちの脳はパターンを見つけるのが得意だけど、細かいディテールを覚えるのは苦手なんだ。コーディングの多くはボイラープレートに関わっていて、正確に説明するのが難しいけど、生成できるものなんだよね。自分の仕事がユニークでクリエイティブだと思いたいけど、実際には多くが繰り返しで、統計的に見ても限られたバリエーションしかない。ライブラリの一部になり得るコードだけど、まだ抽象化されていない感じ。それがAIの出番で、そういうコードを生成するのが得意なんだ。NP問題みたいなもので、解決策を見つけるのは指数関数的に時間がかかるけど、チェックするのは多項式時間で済む。同じように、AIは人間が書くのにもっと時間がかかる速いドラフトを提供してくれて、私たちはそれをすぐにレビューできる。結果は？もっと早く、たくさんのことができるようになる。

コードを書くときは、どんなにシンプルで明白でも、すべてのコードに時間をかけなきゃいけない。コードを読むときは、もっと複雑な部分や重要な部分に時間を割けるんだ。

LLMを最も生産的に使ったのは、個々のメソッドをスタブアウトして、その実装を埋めてもらうことだった。こんなプロンプトを使ってる：public T MyMethod(/args/) /type constraints/ { //TODO: このメソッドを以下の要件を使って実装してください： //1 ... //2 ... //... } これ以上になると、どのウサギが何をしてるのか追えなくなっちゃうんだよね。

なんでこれについてもっと話されないの？私は開発者じゃないけど、多くの開発者と密接に仕事してる。彼らはこの技術に対する興味がゼロから積極的にコードを書くまで、いろいろなレベルにいるけど、レビューやチェックに使う話はほとんどない。もしかしたら、コミット時にパッシブに行う必要があるのかも。

ChatGPTは、ウェブ上で広く書かれている一般的な問題のデバッグにとても役立つ（トレーニングのカットオフ前に）。Stack Overflowの情報を合成して、ディスカッションを探して個別に読むよりも、何が起こっているのかを理解する時間を大幅に短縮してくれる。（このIPは正当にStack Overflowの貢献者に属し、Stack Overflowにライセンスされているべきだ。利用者として参加することには複雑な気持ちがある。）ただし、LLMの出力はハルシネーションのせいでノイズが多い — ウェブ検索よりは少ないけど。LLMがコードベースを評価して、一般的なミスや問題のある関数/APIの呼び出しを見つけることができると思うけど、偽陽性もたくさん出るだろう。みんなはそのようにLLMを使ってるの？

コードのレビューにはLLMを使うべきで、コードの作成や設計には使わない方がいいかも。これはすでにGitHubでCopilotを使ってレビューとして利用可能だよ。最適な提案ではないけど、ループに入れておくには十分使える。

「このコードをレビューしてください」とループでやっていると、チャットボットが最初にXをYに変えて、少し後にYをXに戻すケースが出てくるよ。コードレビューには使えるけど、どの変更を受け入れてどれを拒否するかは慎重に判断しないとね。改善点を見分けられるだけの知識があれば、候補となる変更を出してくれるから、受け入れたり拒否したりできるのがいいところ。

まったく同感！今、https://sourcery.ai でこれに取り組んでるよ。

問題は、代替案は何かってことだよね。人々は一般的に、どの作業が広く採用されるかを予測するのが苦手だ。慎重に優雅に構築されたプロジェクトがどこにも行かないのも、一般的な失敗パターンのように思える。安価に生産できるため、雑なプロジェクトが成功するという進化的圧力がある。これは「悪い方が良い」という古典を思い出させるね。