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

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

その通り、実際のビジネス価値は人々が思っているよりずっと小さいし、正直イライラするよね。確かに、彼らは定型文を書くことができるし、時には理解しやすい分野では人間よりも良い結果を出すこともある。でも、彼らに伴う巨大な問題を考えると、その影響は微々たるものだよ。大手テクノロジー企業のロックイン、データ汚染、検証できない情報、真実性の喪失、創造性の死、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が彼らの頭の中にある仕様を満たさなかったから。これは、心理的な偽記憶効果のようなもので、記憶を誤って思い出したり、期待に対して柔軟な人が「十分近い」と受け入れる一方で、そうでない人もいる。少なくとも、私は自分の中で両方の行動を見たことがある。

一番シンプルな説明は… ほとんどの人がコードモンキーで、同じCRUDの車輪を何度も再発明して、なんとか動くようにくっつけて「今日はこれで終わり」と呼んでいるってことだね。「開発者」という言葉はこの議論ではほとんど意味がないくらい広すぎる。

本当に自問自答すべきことは、「なぜLLMの体験が開発者の間でこんなに異なるのか？」だと思う。私の仮説は、開発者が異なることに取り組んでいて、これらのモデルがある分野（リアクションコンポーネントとか）では非常にうまく機能する一方で、他の分野（組み込み系とか）ではすぐに失敗するってこと。片方にはXに取り組んでいる開発者（LLMが得意な分野）がいて、「これが開発を永遠に革命する！」って主張してるし、もう片方にはYに取り組んでいる開発者（LLMが苦手な分野）がいて、「これはただの流行だ」って言ってる。

本当に自問自答すべきことは、「なぜLLMの体験が開発者の間でこんなに異なるのか？」だと思う。いくつかの可能な理由：* 異なる人が使う異なるモデル、無料と有料のもの、さまざまな推論の努力、内部の量子化や他のパラメータ（例：サンプラーや温度） * 使用するツールが異なる。私の場合、Continue.devが驚くほど悪かったし、Clineはかなり良かったけど、RooCodeは本当に良かった。JetBrains JunieやGitHub Copilotも良い経験があったけど、まあ、いろんな選択肢や設定があるよね。* 異なるシステムプロンプト、さまざまなツールの使用ケース（例：モデルにコードテストを実行させて自分で修正させる）、また、ありふれたコードベース（トレーニングデータにもある）から本当に新しいものまで、平均的なジュニア開発者やLLMをつまずかせるものまで。* オープンエンドのタスクと明確に指定されたタスク、適切なコンテキストを提供すること、問題がうまくいかないときに新しい会話やタスクを始めること、モデルが実際に欲しいものに近い予測をするための例を提供すること（そうすればモデルは実際に欲しいものに近い予測ができる）。私のプロンプトは今や通常、複数の文で、時には十文にもなり、コードやデータの例とともに、実際の実装を行う前にモデルに私が何を望んでいるか質問させるようにしている。* また、時には特定のユースケースに対して個々のモデルが悪い出力を生成することもある。私は一般的にSonnet 4.5、Gemini Pro 2.5、GPT-5を使い分けていて、Cerebras上で動作するQwen 3 Coder 480Bも使っている。これらのタスクを迅速に、よりシンプルにこなすために。これらすべてを考慮すると、私の成功率はかなり良くて、「この技術は『簡単な指示さえもほとんど守れない』」という主張は当てはまらない。とはいえ、私のプロジェクトのほとんどはウェブ開発に関連していて、主にメインストリームのスタックだから、あなたの経験は異なるかもしれない。

でも本当にそうなんだ、彼らはできない。何を使うかによって本当に変わる。数学の固定された世界では、原則的にはすべてが素晴らしいことができる。ソフトウェアでは、文脈が長くても原則的には大丈夫だ。リアルライフのような新しい文脈に対処する場合、でも違う--たとえば、誰もメインキャラクターとコミュニケーションできないストーリーのように、彼らが異なる言語を話す場合、モデルはそれに対処できず、常に彼らが慣れ親しんだ文脈に戻ってしまう。彼らが見たことのあるテキストとは十分に異なる文脈を与えると、基本的な指示に従えなくなることがある。逆に、他の文脈では見た目にはずっと難しい指示には従えることがあるんだ。

今のところ、もっとスクリーンキャストや記事、何でもいいから、誰かがこれらの製品を使って非自明な機能を生み出すプロセスを詳しく描写したものが見たい。AIインフルエンサーたちは、もっとAIツールを作ることについてすごく印象的（で面白い！）なコンテンツを作ってるし、経験豊富な開発者たちは、ほぼ完全にAIが生成したコードベースを紹介してるけど、実際にはAIが生成したコードはほとんど捨てて、インスピレーションを受けてるだけだって認めることが多い。単発のプロンプトからフルアプリ（広告されているもの）は、「まあ、白紙の状態から始めるときにモチベーションを得るのには役立つ」ってすぐに変わる（私のオブリークストラテジーズデッキもそうだけど、あれは月に200ポンドもかからない）。これはHNでの私の観察だけど、実際にこれらを使っている開発者（LARPしてるAIマキシストじゃなくて）がいるのは疑わないけど、彼らはほとんど見えない。もしあなたがAIの使い方に熱心なら、どうやってソーセージが作られているのか教えて！

なぜLLMの体験は開発者の間でこんなに違うのか？この質問は、すべての開発者が同じ仕事をしていると仮定している。組み込み開発者のやる仕事は、フロントエンド開発者の仕事とは全然違うし、ジェーンストリートの開発者の仕事とも全く異なる。それに、開発者は異なるタイプのプロジェクトに取り組んでいる：グリーンフィールド、ブラウンフィールド、レガシー。それぞれ異なるセットアップ：モノレポ、複数のリポジトリ。言語の多様性：単一言語、複数言語など。開発者は工場でロボットのように働く単一のモノリスな軍隊ではない。MLを考える前に、これらの要因を考慮する必要がある。

まあ、私たちも異なるコードベースで異なるタスクをやってるからね。これについてはあまり話されないけど、すごく重要なポイントだと思う。でももう一つのことは、期待が普通になってしまって、より頼るようになると限界にぶつかることが多くなるってこと。使えば使うほど、必ずがっかりすることになる。たまに使う分には感心するけど、一日中使おうとすると、結局「できるはずだった」ことを何度もやり直さなきゃいけなくなって、最後には全然感心しなくなる。

「LLMに自分が考えている複雑なものを正しく作り出すことを期待する」ってことだけど、私の予想では、ある種の仕事では人々は自分が考えている複雑なものが何かを事前に分かっていないことが多いんだ。アイデアは仕事を進める中で形成され、明確になっていく。そういうタスクには、AIを使っても効率は上がらないよ。

これはテスラのFSDの普及にすごく似ていると思う。私にとっては、技術の不正確さにもかかわらず、よく使うから素晴らしいんだ。言い換えれば、その欠点を補うほど価値があるってこと。多くの人にとっては、「時々使うけど、自分がやらないことをしたらすぐに離れる」から「絶対に使わない」までのスペクトルにいると思う。私の場合、運転をAI（もっと言うとML＋コンピュータビジョン）に任せるのは全然平気だけど、自分の脳をAI（LLMs）に任せるのはダメだな。間違いが多すぎるし、それをチェックするためにかかる手間は自分でやるのと同じくらいなんだ。

もっと言ってみて？

もし新しいコードに取り組んでいるなら、LLMは本当にひどい これ、まさにその通り。現状の最先端モデルは、私の経験上、ボイラープレートコードや非常にシンプルなアーキテクチャを書くのが得意だよ。特に、非常に有名なパターン（特にMVC）があるプロジェクトやフレームワークではね。本当にすごいのは、大量の情報を解析して何かを見つけること（例えば、コードベースやスタックトレース、ログの中で）。でも、「エージェントが全体のコードベースを作成する」っていうハイプは、今のところただの煙と鏡だと思う。

投資が多すぎたから、売らなきゃいけない。

私の経験はあなたとは逆だな。先週、クロードコードがコンパイラの問題をほとんどガイダンスなしで直してくれたことがあった。時々イライラすることもあるけど、大体はクロードコードが問題を次々と解決してくれるんだ。微妙なコード生成やパーサーバグをほとんど手を加えずに直してくれる。実際、私が介入するのは、コンパクションを管理して不都合なタイミングでコンテキストが切れないようにするためのツールの弱点についてだけ。書籍で調べないとわからないようなメソッドを実装してくれて、それを動かすことができることを示してくれる。あまり「新しい」仕事はしないかもしれないけど、そもそも新しいコードなんてほとんどないし。指示をしっかり構造化すれば、ちゃんと従ってくれるけど、CLAUDE.mdみたいなところにランダムなことを投げ込むだけじゃダメ。最近の最大の問題は、プロセスに関してかなりのガイダンスが必要だってこと。私の指示は主に3つのエリアに集中してる：1) 特定のプロジェクトのデバッグガイダンス（私のコンパイラプロジェクトの場合、「コンパイラからASTをダンプする方法」とか「gdbを使ってクラッシュをデバッグする」とか）、2) 受け入れ基準 - これは繰り返しが必要、3) テストを頻繁に実行するよう指示し、小さくてテスト可能な変更を加え、作業中のアプローチや進捗、調査結果を詳しく記載したファイルを頻繁に更新するようにすること。これら3つが整っていれば、クロードを何時間も--dangerously-skip-permissionsで動かせて、私が「続けて」とか長い実行の途中で/compactをするためにしか介入しない。完璧なコードを毎回提供するわけじゃないけど、私もそうじゃない。でも、通常は正しい方向に進んでいて、時間をかけずに進捗を出してくれる。少なくとも、しっかりした足場がないとゼロから始めさせたくはないけど、時にはそれもできる。ただし、悪い選択を「ロックイン」する前にはレビューが必要。最近は、クロードが数日間人間の介入なしで問題に取り組むためのハーネスを考えているところ。

それに、見落としていたかもしれないエッジケースや、知らなかったベストプラクティス、私よりも文法が上手な文章を書くことで、_いくらか_の価値を追加してくれる。これが私の一番の経験だね。人間がやるちょっとしたおバカなことを見つけるのが得意なんだ。だから、PRレビューアーとしてはかなり役立つと思ってるけど、あまり真に受けない方がいいよ。

その通り。マーケティングのハイプサイクルの反対側は、マーケットの力が良いものと悪いものを分けるときに、もっと冷静になるだろうね。

これを超えて、新しいコードに取り組んでいるなら、LLMは何をするにも本当にひどいよ。多くの仮定がなされていて、存在しないライブラリが使われて、エージェントはトークンを使って具体的な結果を何も生み出さないのが得意なんだ。私の経験とは違うけど、私はLLMを使って非常に特定の科学的・ニッチなコードを書いたことがあって、うまくいったよ。ただ、問題を理解するために正しいコンテキスト（私の場合はいろんなウェブサイトや本をマークダウンにまとめたもの）を与える必要があったけどね。それは私にとって追加の作業になるけど、初期設定のコストを考えれば、全体的な生産性はかなりプラスだよ。1〜2年前の初期モデルでは、LLMにどのファイルを見せるべきか教える必要があったけど、ここ半年くらいはそれをしていないし、何百万行ものコードベースで作業してる。現代のLLMが存在しないライブラリを使ったこともないよ。時々、古いライブラリを使おうとするけど、コンパイルしようとするとすぐに失敗して、エラーをすぐにキャッチしてウェブ検索（私はカスタムのウェブ検索プロバイダーを使ってる）で最適なライブラリを探すんだ。LLMが自分に合わないと言っている人は、ただLLMの動き方を理解していないだけで、効果的に使えないんだと思う。もしくは、彼らの経験が古いだけだね。ただ、CLAUDE/AGENT.mdファイルの指示に必ずしも従わないという元々の問題は確かにあって、ちょっとイライラすることもある。

Claudeでコーディングするのは、スロットマシンを回しているみたいだね。たまに、頼んだものが多かったり少なかったり、全然違ったりする。放置するのは賢明でも正気でもないと思う。

人それぞれのモデルとの作業体験がこんなに違うのは本当に興味深いね。私はここ数週間、codex-cliを使って5倍も生産性が上がったよ。変則的な構造のソースコードや実行トレースの内部SVGをカスタムの内部JSONグラフフォーマットに変換するのも全然問題ないし、これは彼らのトレーニングデータとは明らかに異なるタスクだよ。それに、私たちのRISCVアクセラレーター用の低レベルカーネルを含む大規模な混合Python/C++コードベースから、バグをその日のうちに既知の問題として文書化するレベルまで、ますます正確なドキュメントを作成している。私たちは同じツールから全く異なる結果を得ていて、その理由がすごく気になる。

これがもっと話題にならないのが驚きだよ。あちこちで（まあ、HNとRedditでは特に）行われているAI推進の工作は本当にすごい。

今、コースを売る方がLLMをうまく使うよりもお金になるから、こういう人たちはエージェントを作る方法を見つけたふりをして、それをマーケティングして人々がコースを買うんだよ。

このアイデアは今すごく注目されてるね。例えば、https://www.noahpinion.blog/p/americas-future-could-hinge-on...

うちには2種類のユーザーがいるよ。一つは熱心な支持者で、オフィスの仕事が革命的に変わったと言っていて、正確性の問題があるかもしれないことに全く気づいていない人たち。そういう人たちはただの空気を作り出しているんだろうね。もう一つは試してみて、明らかな弱点にぶつかって、今はかなり慎重になっている人たち。でも、何か一つか二つには使っているみたい。

彼らは使っているけど、まだVCからの大きな補助があるし、価格が上がっていく中で人気が続くかどうかはまだ分からないね。どちらにしても、「これがうまくいかない」場合はレイオフがあるのは確実だ。

PIPAは怖いね。

それについて動画を作ったらいいよ、ライブコーディングセッションみたいな感じで。チュートリアルじゃなくて、君がかっこいいコンテキストエンジニアとして活躍してる様子を自然に撮影したやつ。そうすればメッセージが伝わりやすくなると思う。