これを裏付ける理由とかある？ 編集: 正直な質問で、ディスりたいわけじゃないよ。面白い見解だと思うし、真実かもしれないけど、意見って感じがするな。

「コンテキストエンジニアリング」も同じだね。

その通り、実際のビジネス価値は人々が思っているよりずっと小さいし、正直イライラするよね。確かに、彼らは定型文を書くことができるし、時には理解しやすい分野では人間よりも良い結果を出すこともある。でも、彼らに伴う巨大な問題を考えると、その影響は微々たるものだよ。大手テクノロジー企業のロックイン、データ汚染、検証できない情報、真実性の喪失、創造性の死、LLMの伝道者たちの無知、今の時代に人類が排出量を減らす方法を考えるべきなのに権力欲、オリジナルの人間の仕事の盗用、大手テクノロジーが長い間逃げてきたデータの盗用。これが人類にとって純粋にプラスだと思っている人がいるのが不思議でたまらない。

具体的にどんな改善を期待してるの？元のフォーラムの投稿で具体例やプロンプト、方法論を示さずに「私は良いプロンプトを書く」って言うだけじゃ、評価するのも手助けするのも難しいよね。彼らはエージェントのワークフローに対して準備万端で来た。それはいいけど、他の人が最初の仮定が間違っていることを示すチャンスを与えるようなものは提供していない。私は数ヶ月間、毎日エージェントと一緒に働いているけど、何が失敗し、何が信頼できるかをまだ学んでいる。私の経験からの重要な洞察は以下の通り：- エージェントを効果的にオーケストレーションするためのフレームワーク（agent-osのようなもの）が必要 - ガイダンスと自律性のバランスが重要 - 特にレガシーコードベースでは計画が重要 最近の例：レガシーシステムで壁にぶつかって、重要な背景情報でコンテキストウィンドウが最大になってしまった。圧縮後、エージェントは重要な知識を失い、以前のミスを繰り返してしまった。うまくいった解決策：- 問題を適切に構造化した - 各学習/発見を体系的に文書化した - 特定のタスクのために専門のサブエージェントを作成した（コンテキストウィンドウを管理可能に保つ） それで初めて、エージェントがレガシーコードの混乱をナビゲートする手助けができた。

エージェントが私が見逃したいくつかの生産バグを見つけてくれたことがある（私は比較的マイナーで孤立したバグレポートを追うために十分な時間を割けなかったから）。もちろん、彼らが現在見つけられないバグはもっとたくさんあるけど、この戦略がほとんどコストがかからない（SWEが1時間かけて探すのに比べて）のに、時々うまくいくなら、そのトレードオフはかなり良いと思う。

ざっと（へへ）カーソルフォーラムを読んでみると、チャットの参加者たちがAIをアデプタス・メカニクスがオムニシャに接するように扱っているのが明らかだね……でも、機械の精霊たちは彼らと協力してくれないみたい。

OPがひどい結果を出している理由は、Cursorを使っているからで、Cursorはコストを抑えるために文脈を厳しく削減するように設計されているからだよ。モデルプロバイダーとは違って、CursorはLLMの使用に対して小売価格を支払わなきゃいけない。彼らは厄介な限界価格戦争を戦っているんだ。もし他の競合よりも推論に多く支払っているなら、1) 他のモデルと同じパフォーマンスを損失を出して提供するか、2) モデルプロバイダーに小さな文脈を与えてコストを抑えるかの選択をしなきゃいけない。Cursorは文脈の扱いについて透明性がない。私の経験からすると、彼らは会話を削減するために攻撃的な戦略を使っているのが明らかで、同じ会話の中で同じファイルを何度も参照しなきゃいけないことも珍しくないよ。Cursorを使っている人には、時間を無駄にしない方がいいってアドバイスしたい。生成されるコードは多くの負債を生むから。私はCodexとClaudeに移行したけど、すごく満足してる。

エージェントの使い方について簡単に説明したいな。普段は集中しているメインの作業があって、現在の動作と望む変更を説明するんだ（この変数をここで使うために関数を通す必要がある）。「Gpt 5 thinking high」はかなり正確だから、何をしたいかをはっきり示せば、だいたいリクエスト通りにやってくれるよ。（もしそうならないなら、コードベースに他のコンテキストが混乱させてないか確認してね）作業中に、別の作業を促すこともできるし、変更を求めずに聞かないモードに切り替えないようにする。必要な変更を見つけるための大半の作業をしてくれて、間違ってたら修正できるように要約してくれるよ。このプロセスは、既存のモデルが忙しい限り繰り返せる。うまくいくプロンプトの種類：質問：「Xをするための関数やコンポーネントは何？」とか、他にこのパターンを使ってるところはどこ？バグのプロンプト（修正に2時間かからないものは、1つのプロンプトで促せるはず。最初に上手くいかなくても、何が間違ってたか説明して、プロンプトを改善するように頼んで、また最初からやり直してみて。人々はコンテキストをリセットすることがあまりないから）。大規模なアーキテクチャや計画については、プランモードに切り替えて、やり取りをしながら時間をかけることをお勧めする。しばしば混乱するから、進捗を（理想的には.mdファイルとして）保存して、新しい会話に持っていって繰り返し作業できるよ。Jiraチケットの提案もできるしね。異なるモデルを理解することは重要だよ：Claude 4.5（および3.5以降のほとんどのClaudeモデル）は、本当に何かをやりたがるから、放置すると通常は頼んだ以上のことをやってくれる。失敗したテストでブロックされてると認識すると、それを削除したり無駄に変更したりすることもある。でも、すべての決定を自分でしないプロトタイプを素早く作りたいときには、本当に素晴らしいモデルだよ。Gpt 5 thinking highは私のお気に入りだし（codex 5 thinking highもvscodeのcodexプラグインでかなり良い）、新しいコンテキストを頻繁に作ることが大事だね。

別の理論: あなたの頭の中に仕様があって、その大部分を書き留めて、LLMにその仕様に従って実装してもらうことを期待する。結果は客観的に仕様から逸脱したものになる。ある開発者は、頭の中の仕様を後から変更したり、少しの逸脱には基本的に満足したりする。別の開発者は失望するだろう。なぜなら、LLMが彼らの頭の中にある仕様を満たさなかったから。これは、心理的な偽記憶効果のようなもので、記憶を誤って思い出したり、期待に対して柔軟な人が「十分近い」と受け入れる一方で、そうでない人もいる。少なくとも、私は自分の中で両方の行動を見たことがある。