どの意見の部分？私は、CLI（特に、aider.chatとClaude Code）に対する「不人気な意見」には強く同意する傾向があるよ。前提として（これが重要）、使っている言語やフレームワークをマスターしているなら、25年前のXPプラクティスでCLIツールを使うのはすごく加速剤になる。注意点：- センスと批判的思考は絶対に必要。LLMにはそれがないから。- システム思考も必要。深い奇妙さを「頭に入れておく」ことができないから。つまり、物事がどうあるべきかについての「やられた！」的な二次的・三次的なことを考慮する必要がある。- 最後に、知識のカットオフ日から数ヶ月または1年前の言語やフレームワークに関する新しい情報をまとめて、コンテキストに凝縮した要約を含めるべき。例えば、Swift 6と6.1と、GPT-5が知っている5.10や2024年のWWDCの発表を比較する感じ。この最後の部分では、(a) OpenAIの「Deep Research」を使ってまずギャップをホワイトペーパー化し、次にそれをMarkdownのコンテキストプロンプトに変換して、最後にLLMツールに持っていって必要に応じて仕様書やアーキテクトモードで使うのが便利だと思う。同様に、(b) 新しいコードを作成する際には依存関係のリポマップツールを使って、その作業のためにコンテキストを持っておくべき。これらの明らかなステップが先進的なエージェントツールに組み込まれていないのが不思議だけど、もしかしたらLLMをナイーブで古い「レインマン」タイプとして扱うことが、ほとんどの「AI」スタートアップのメンタルモデルに入っていないのかもしれないし、あるいはバイブコーダーたちが気にしないから優先順位が低いのかもね。どちらにせよ、コンテキストに基づく開発はLeroy Jenkinsよりも優れている。

実際、働くソフトウェアを提供する仕事をしている人たちの間では、結構一般的だと思うよ。LinkedInのMBAタイプの人たちが本当に開発者じゃなかったり、長い間開発から離れていたりするけど、今はちょっとしたReactコンポーネントやPythonスクリプトを作れるようになって、革命的だね。

私の印象では、企業環境（LinkedInも含む）では、AIの楽観主義が基本的に美徳のシグナルとして使われていて、実際に技術に興奮している人と受け入れられたい人を区別するのがすごく難しい。私の個人的な経験では、AIは変化の範囲を小さくターゲットを絞るのが苦手だと思う。ただ、私はGemini 2.5 proしか使っていないから、他のモデルにはアクセスできないんだ。友達はコーディングにはClaudeを使って、ドキュメントにはGeminiを使っているって言ってた。

Linkedinの投稿はあんまり信頼できない情報源だと思う。そこで自分のことを投稿してる人たちは、成功前の人か、パーソナルブランディングが好きな人ばかりだよ。

この意見は、盛り上がってるブログやニュースが言うほど少数派じゃないと思う。俺も同じ質問を同僚にしてみたけど、ほとんどの人が同じ気持ちだし、俺もそう。ただ、そこまで悲観的ではないけどね。LLMやエージェントワークフローを万能薬みたいに言ってる人たちは、使ってるフレームワークや言語の経験が限られてることが多い。今のところ、俺は慎重な楽観主義を持ってる。LLMのワークフローが、盛り上がりが言ってるような安定したポイントに達すると思ってる。今は「LLMは床を上げるが、天井を上げない」という言葉がすごく的を射てると思う。LinkedInは無駄なポーズだらけだから、無視していいよ。

実際の人間（管理職じゃない同僚や友人）と話すと、AIに対して結構冷めた反応が多い。AIツールが生産性を下げるって感じてる人も結構いる。AIに対して非常に楽観的な人も知ってるけど、彼らですらLinkedInで見るような熱狂的な賛美とは程遠い。もっと冷静に考えてるし、常識的にアプローチしてる。もちろん、これは完全に経験則で、どこにいるかやどんなビジネスをしているかによるけど、俺がいる分野（カスタマーサポートソフトウェア）ではAIがある程度意味を持つし、それでもやっぱり幻滅の傾向を感じてる。管理側では、あらゆる種類のAIの義務、ワークショップ、SNSでのAI関連の投稿があって、我々の「プロダクトビジョン」は誰も理解できないAIの幻覚のようなものになってる。まるでこの10年間ずっとAIをやってきたかのように、あらゆる隅に「AI」を押し込もうとしてる。毎日、CxOたちがLinkedInでAIに関する話題を投稿してるのを見かける。GPT-5が発表されたときも、リリースされた数分後に「$COMPANYでGPT-5を使って、今まで解決できなかった問題をどう解決しているか！」って投稿してた（俺たちは早期アクセスを持ってなかったけど笑）。振り返ってみると、幻覚のグラフや面白いエラーがあったことを考えると、あの発表は本当にジョークだった。管理からのあらゆる義務や押し付けがあっても、俺が近いチーム（俺のチームも含めて）は少し反発し始めてる。役に立たないPRコメントを生成するスパム生成PRボットを排除しようとしてるし、使ってないからという理由で与えられたさまざまなサブスクリプションの取り消しを求める人もいる。顧客からのフィードバックの一番のポイントは、誰も求めていない無駄なAIに焦点を当てるのではなく、コアプロダクトを改善すること（当たり前だよね）。一番のファンだったCTOですら、少し引き下がってきてるのを見てる。HNは主にYCとそのスタートアップの広告プラットフォームだってことを忘れないで。YCの最近のバッチをチェックすると、世界に存在する唯一の技術はAIだと思うくらい、どれも何らかの形でAIに言及してる。大半は最低限の努力で、AI APIをラップして製品と呼んでるようなもの。これだけの金がこのハイプにかかってるから、これらのシステムが完璧に動くように見せようとする利害関係者もたくさんいる。LinkedInについては言わない方がいい、そのサイトは死んだインターネット理論の典型だ。

「学習曲線はない」というのは、この人があまり進んでいないってことだね。Copilotや他のツールが基本的に同じだと思っているのが裏付けになっている。

もし簡単じゃないなら、価値がない。なぜなら、手動で書くことは通常簡単だけど、面倒だから。LLMの目的は、面倒な作業を簡単に排除することだから、面倒な作業をLLMにやらせるのが面倒なら、何も達成していないことになる。自分でやるには面倒すぎる作業なら、LLMを使うのはたぶん大失敗になる。自分でコードを開発するのにかかる時間とほぼ同じくらいの時間をかけないと、最終的な出力を判断できないからね。だから、何も得られず、得られたのは得られたように見える幻想だけ。人々がLLMを使って非トリビアルな問題に取り組むことで生産性が上がると思う理由は、LLMが「オフィステアター」を生み出すのが得意だから。プロンプトを出してLLMの出力を読んでいる間は忙しそうに見えるけど、深く考えながら空を見つめて、たまに何かを書いたりタイプしたりするのとは違うんだよね。

最初の2つのポイントは互いに矛盾しているね。ツールを学ぶことは、そのツールで生産的になる結果をもたらすべきだよ。「生産的」になるのが簡単じゃないなら、ツールを学ぶのも簡単じゃないってことだ。

この意見には賛成だな。実際、理解するために何度も読み返さなきゃいけなかった。彼はコストパフォーマンスの理由でCopilotを勧めていて、最後の言葉は「流行に惑わされるな、でも、時には本当に強力なツールだ。」って感じ。だから、彼はもっと高度なモデルが使えるプロンプトをどうやって作るかを試してみたことがないように思える。

ピアニストの成果は、才能や努力に比例するってよく言われてるよね。オープンソースでは、ほとんど誰もLLMを使ってないし、使ってる人もほとんど成果を出してない。多くの場合、LLMを使う前よりも出力が少ないこともある。一方で、ブログの出力は…

「LLMをうまく使ってる人がこんなこと言ってるのは初めて聞いた。」ほとんどの人とワークフローについて話して学んだことは、直感に反することが多いし微妙なんだ。私たちが懐疑的でデータ主導だと主張している一方で、実はみんな魔法を信じてる。「直感に反する非自明なワークフロー」？それは「ルールなしでXを実装して」ってプロンプトを出すのと同じくらいの効果しかない。だって、1) 実際に魔法の具現化が機能するかどうかを測る人はいないし、2) 非決定性のせいでそんな測定は不可能だから。

コーディングワークフローでLLMを使うのは簡単だよ。学習曲線なんてない。今のワークフローに合わないなら、無視しても大丈夫。これはすごい発言だね。今はコアコードベースでLLMを使ってすごく生産的だけど、正しくて再現可能な状態にするまでにはかなりの練習が必要だった。LLMが正しい選択をするために制御する必要がある小さな文脈の詳細がたくさんあるんだ。新しいコードベースで作業を始めると、フルLLM生産性に戻るまでにかなりの時間がかかるよ。

OPの言いたいことは、LLMがスキルにとってネットの利益をもたらすのはすごく早いってことだね。つまり、彼は学習曲線の最初の部分だけを話してる。

前にも言ったけど、LLM（大規模言語モデル）を使うと、まるで宝くじに当たった気分になるんだよね。いくつか試してみたけど、ほとんどがポジティブな結果だった。最初はコパイロットを使ってみたんだけど、これは「ステロイドを使った予測テキスト」みたいにすごくうまく機能する。従来のインテリセンスIDEでタイプするより、確実に速くて正確なんだ。僕にとって、このレベルのAIは絶対に失敗しない。数行の予測が自分の求めているものかどうか、すぐにわかるからね。それからしばらくCursorも使ってみたけど、これも僕の求めていることをやってくれた。マルチファイルの編集は本当に面倒くさいことがあるんだけど、時々変なことをすることもある。でも大体は、自分が何をしたいのかはわかってるし、ファイルを探して、すべてのファイルで編集して、コンパイルできるか確認するのが面倒なんだよね。これはジュニア開発者としてやらなきゃいけないループだけど、そうしないとコーディングの理解が進まない。でも今は、そこから何も学んでいない気がする。ただツールが魔法のようにコードを変換してくれるのを望んでいて、実際にそうしてくれる。今はClaudeを使ってるけど、なんか、求めていることから外れることがすごく少なくなった。もっと複雑なコードの編集もできるし、ほとんど何もタイプしなくて済む。ジュニア開発者に話すように指示する感じ。「接続をたくさん作って、最初にメッセージを受け取ったものを使って、後からのコピーは捨てよう」みたいにね。もし本物のジュニアに話してたら、日中にいくつか質問に答えたりするかもしれないけど、彼はこのタスクを結構ぐちゃぐちゃにやるだろうな。面倒なタスクで、実際に何をするべきかについての仮定をしなきゃいけない。でもClaudeは正しい仮定をしてくれる。そう、確かに各接続が「勝つ」頻度を出力するテストが欲しい。正しい、すべての接続にサブスクリプションを送る必要がある。ジュニアが理解して自分で考えつくような仮定だよね。LLMと一緒に批評する時間が多いから、編集するよりもずっと楽しい。「これ、抽象化できるよね？」って言ったら、コードを見て「うん、こうやって一般化できるよ」って返してくる。だからファイルの中を探すことに注意を向ける代わりに、全体の構造を見ることができる。これって、最高の集中力を必要としないから、夜遅くや子供と出かけている時でもできるんだよね。だから、学習曲線はほとんどないとも言える。Claudeを使う前にマニュアルやチュートリアルを開いたわけじゃないし、自然な言葉で何をしてほしいか話し始めただけで、ちゃんとやってくれてる。みんなとは違って。

完全に同意。LLMを正しく使うには数ヶ月かかる。最初はLLMがすごく驚かせてくれるハネムーン期間がある。その後、いくつかの失望があるけど、LLMが得意なことと苦手なことがあることに気づき始める。何を期待できるかの感覚ができてくる。そしてもっと重要なのは、問題をLLMが解決しやすい小さな問題に分ける習慣がつくこと。問題を最適に説明する方法を学び続けて、プロンプトを調整し続ける。それには時間がかかる。

あなたに同意するし、HNの記事でこの意見を何度か見たことがあるけど、要するに「何も試してないし、アイデアも尽きた」っていうシンプソンズのジョークに通じるよね。これらの記事を読むと、時々自分がクレイジーピルを飲んでる気分になる。ハイプに引き寄せられた人が、明らかに偏った自分のバイアスを確認するためだけに、半端な努力をするのが透けて見える。そんで、今やそのテーマについての権威を持ったかのように振る舞って、自分の先入観が間違いなく真実だと宣言するんだ。すべての問題がLLMのコーディングエージェントにうまくいくわけじゃないし、すべての人がそれを効果的に使えるわけでもない。でも、「試してみたけど自分には合わなかった」っていう記事は、「試してみたけど、あなたが恐れている通りひどいことが証明された」っていう記事よりもずっと面白くないと思う。

同意。これは驚くほどひどい記事だよ。これがフロントページに載ったのは、AIを軽蔑したり嫌ったりする人たちがアップボートしたからだって明らかだね。だって、君が言うように、どうして誰かがツールの使い方をちゃんと学ぶこともせずに、権威ある主張ができるのか理解できないよ。

大きな岩（ソフトウェアプロジェクト）を持っているなら、丘を押し上げるのと（LLMの使用）、ウインチで引き上げるの（従来のツールや方法）では大きな違いがあるよね。人々は、押すための筋肉をつけたり、正しい足場を学ぶのに時間がかかるって言ってるけど、俺は機械理論を学んでレバーを描いてるところ。もし誰かがその岩を1メートル押せたとしても、怪我した人たちを無視して「いつかは岩を持ち上げて月に投げるんだ！」って騒いでる。

誰かが「プロンプトを学ぶのはスキルだ」って主張するのを待ってるんだけど、明らかじゃないテクニックを一度でも説明してほしいな。例えば、作業バージョンに戻るためのチェックポイントを保存するとか（Llmを使わなくても良いプラクティスだし、gitを見てみて）とか、少し違うプロンプトで10個のタブを立ち上げて一番良いのを選ぶとか、Llmにプロンプトを改善してもらうとか、もっとコンテキストを追加するとか…それってスキルなの？子供の頃、母がVCRをプログラムして夜の番組を録画するのがすごい技だと思ってたのを思い出す…

中規模のiOSコードベースでの私のワークフローはそんな感じだね。すべてがうまく動いて、自分の基準に達するまでには、手動で書いた場合とほぼ同じくらいの時間がかかることが多い。これはOpus専用のClaude Codeでの話。構造化された並行処理やたくさんのカスタムAsyncSequenceオペレーターが含まれているから、もしかしたらCCには向いてないのかも。もちろん、グリーンフィールドプロジェクトを作るのはほぼ魔法のようだけど、それが私の仕事の大部分ではないんだ。

ランダム*がどういうものかはわかってる：コイン投げやサイコロの振り。トークン生成はそれとは違う。

これは良いアナロジーじゃないね。スロットマシンのパラメータは、カジノが損をするように変更できる。何かがランダムだからって、無駄だとは限らない。LLMから10回中7回良い出力が得られたら、それを自分の利益のために使える。良い出力の頻度と、それにどれだけ手間がかかるかが、使う価値があるかどうかを決める。人間も間違いを犯すけど、頻度はずっと少ないよね。

良いプロンプト（プロンプトエンジニアリング、チューニング）がより良い出力を生むことができるという証拠はたくさんある。より良い入力を通じてLLMの出力を改善することは、幻想でもなく、グーグルの使い方を学ぶほど簡単でもない（LLMの出力を改善し、その改善を測定するために、企業が立ち上がっている）。

グーグルの使い方を学ぶのは簡単じゃないよ。

『神話のマン・マンス』の内容は時代を超えている部分も多いけど、あの本が書かれたのは半世紀前で、1970年代のメインフレームで働いていた開発者たちについてだから、その点は忘れない方がいいよね。

LLMから良い結果を得るための直感は、ほぼ全てが今でも relevant だよ。もし今日から始めたら、今の自分に戻るまでに数ヶ月の実験が必要だと思う。LLMと真剣に向き合うことで、ネットにあるゴミみたいなアドバイス（「常に『あなたはXの世界的な専門家です』から始めて、チップを渡す、...」）を避けるのにも役立った。

LLMの最大主義者の一部は、防御的になってるね。彼らは、これらのツールにあまりにも多くの時間を投資してしまったかもしれないと考えたくないみたい。

ソフトウェア「エンジニアリング」の極みだね。

コードの必要な露出と信頼性によるよ。あるコードは、顧客に何かがどう見えるかを示すための一回限りのものだし、その場合、コードがどれだけうまく動くかとか、見た目なんて全然気にしないよ。迅速なプロトタイピングはそのための有効な使い方だしね。私は、数年のランタイムが必要なC++コードも書いたことがあるけど、その場合は絶対にメモリリークやバグがあってはいけないから、テレビが動かなくなることもある。そんなのは言語モデルに書かせるつもりはないし、少なくとも徹底的にテストして、自分にとって意味があるか確認するまではね。ここは全か無かじゃないよ。これらのものはツールであって、そういう風に使うべきなんだ。

人間が生成するコードの質を過大評価してると思うよ。私は、同じプロンプトや要求を与えられた場合、LLMの方がジュニアからミッドレベルの開発者の出力よりもいいと思う。

笑、そうだね。ジュニアが一緒にハッキングしたコードベースで大企業を運営したことなんて一度もないよね。全く、そんなことはない。

君はどうか知らないけど、考えるのって難しいよね… クロードにボイラープレートコードを任せると、頭の中で問題を抱えながら、エージェントに詳細に指示を出すためのサイクルがもっと残るんだ。