ハクソク

世界を動かす技術を、日本語で。

LLMマキシマリストの不安定な福音伝道

2026年1月14日原文(lewiscampbell.tech)

概要

  • LLMを使ったコーディングへの懐疑的な視点
  • LLMの有用性と限界の実体験
  • エージェント的LLM開発への失望
  • 技術変化に対する議論と心理的な側面
  • オープンな問いかけと自己反省

LLMプロダクティビティ懐疑論

  • LLM はデジタル事務員として有用、ウェブ検索やドキュメント探索、アルゴリズム調査に活用
  • コーディング支援も 小規模な文脈 や明確なガイドラインのもとで限定的に役立つ
  • プロンプト駆動開発 や「vibe coding」ではエージェント的LLMの限界を痛感
    • 小さなコード変更でも多大な手間と時間を要し、誤りも多発
    • トークン消費とともに自己効力感の低下を実感
  • こうした体験は個人の好みや経験に依存し、他者の「vibe coding」自体は否定しない立場
  • 非経験者 でもLLM活用で新しいものが作れる点は評価
    • その後のコード修正依頼が仕事になる利点も

LLM推進派への違和感と心理的側面

  • LLM推進派は「これが未来」「取り残される」「ソフトウェア開発は永遠に変わった」と主張
  • 反対意見に対し、「変化を恐れる心理」「新しい技術への抵抗」「時代遅れ」と性格評価を行う傾向
  • 実際には エージェント的コーディング の理想像には共感
    • 仕様作成に専念し、機械に完璧に実装してもらいたい願望
  • しかし現実とのギャップに 大きな失望感

推進派の心理分析と新たな仮説

  • なぜ推進派は他者を説得しようとし、時に攻撃的になるのか疑問
  • 個人的な仮説：推進派は「LLMが自分よりプログラミングが得意」と気づき、著名な開発者がLLMなしで生産的である事実に不安を感じている可能性
    • 「自分が劣っているのではなく、他者が脅威を感じているのだ」と 投影 している心理
    • 熱心な布教活動の根底に 不安 や 自己防衛 がある可能性

オープンクエスチョンと自己反省

  • 自分自身のLLM活用スキル不足の可能性も認め、今後も意見を変える柔軟性を持つ姿勢
  • LLM推進派にも「もしかしたら自分はそれほどプログラミングが得意ではないのかも？」という自己省察を促す問いかけ
  • 技術進化への適応や評価は常に オープンな議論 が重要

補足

  • LLM活用の効果が プラシーボ である可能性を示唆する証拠も存在
  • 著名開発者でなくとも議論の当事者になれる点を強調
  • コード修正等の仕事依頼も歓迎

Hackerたちの意見

テックツイッターで「LLMは手で書くよりも常に良いコードを生成する」と言ってる人たちを見て、かなり目からウロコだった。LLMは、自分が得意じゃない言語や分野でも、すごく早く良いコードを生成できるけど、LLMの出力を見て「これなら自分の方が絶対良くできる」と思わないことは滅多にない。これらは平均的なテキスト生成マシンだよ。確かに、適切な重みを引き出す良いプロンプトを書くことで出力の質を向上させることはできるけど、もし手で書くよりも一貫して良い出力が得られているなら、あなたはプログラミングが平均以下かもしれない。確かに、これは時々重要だよね。私たちが直面しているソフトウェアのバグの数を見てみてよ。それに、コードは負債でもあることを忘れないで。生成するのが「安い」コードを使うことにはコストがあるし、これは近い将来、たくさんの議論の対象になると思う。

└

私の見解では、ラフドラフトやアイデアの反復、使い捨てコード、まだ習得していない分野に踏み込むのにはとても良いと思う。多くのケースで、彼らは十分に良いテストを書いていると思う。

└

クロード・コードは、Gitの履歴を掘り下げたり、マージコンフリクトを処理したり、物の名前を変えたり、いつも忘れがちなSQLクエリを書くのが私よりずっと上手だ。でも、そうだね。もし大きくて具体性のないタスクを与えると、かなり mediocre（それ以下）のコードを生成する。

└

私は、 1.) コンピュータのように考えてコードを書く脳の配線がされていない。 2.) コードを書いていると、1時間か2時間でキーボードの前で寝ちゃう。 3.) アイデアを実現するために情熱を持って取り組むけど、その過程で書くコードがクソだって分かっててもやる。 だから、要するに、LLMは私よりもいいコードを書くんだよね。私だけじゃないけど。

└

でも、ある程度の経験を積むと、質の違いが実際にどれほど重要かを理解するようになると思う。シニアの中には、PRを一日中バイクシェッドするのが好きな人もいるけど、一般的にはその活動には実際の価値がゼロだよね。たまには重要だけど、ほとんどはそうじゃない。「手作業でやったらもっと良くできる」って言うのはやめて、「手作業でやるのに追加で4時間かける価値があるのか、これで目標を達成できるのか？」って考えよう。

└

最近、バイブコーディングをたくさんやってるけど、今のSOTAのLLMは満足できるコードを生成してくれないことが多い気がする。LLMはごちゃごちゃした脆弱な構造をハッキングするのがすごく得意な気がする。「頭の中でいろんなことを把握できる」からね。でも、LLMは俺が選んだ言語で動くPNGデコーダーを一発か数発で書ける。俺もできるけど、1分以上かかるよ！（その過程でPNGフォーマットについて何か学べるかもしれないし…）それに、エンジニアたちはコードの質について一日中話せるけど、これって非エンジニアにとって本当に重要なのかな？客観的にはそうかもしれないけど、彼らを納得させることができるかな？

└

俺は比較的大きな会社で働いてた（プログラマーが約400人いる）。LLM生成のコードを受け入れている人たちには、明らかに共通の特徴がある。彼らは「はい！」と経営陣に言うのが大好きな機能推進者なんだ。経営陣は常に正しいから、これらのプログラマーは不完全な要求でも、できるだけ早くCopilotセッションに入れてプルリクエストを開こうとする。数ヶ月前に最悪のケースを覚えてるんだけど、あるスタッフエンジニアがJavaとKotlinの並行ツールのベンチマークについてプレゼンしたんだ。Kotlinの方が圧倒的にパフォーマンスが良くて、意味がわからなかった。コードを掘り下げてみると、すべてがLLMによって生成されたことが明らかだった（例えば、絵文字付きのコメントがたくさんあった）。Javaのコードはただ間違ってた。そこで見た有能なプログラマーたちは、LLMを使ってシェルスクリプトや小さなPythonの自動化を生成したり、アイデアを探ったりしてるけど、ほとんどの場合、これらのツールには感心してないよ。

└

テックツイッターで「LLMは手で書くよりも常に良いコードを生成する」って言ってるのを聞いて、かなり目から鱗だった。あれは面白いね、LLMのコードはいつもひどい。唯一のメリットは、たまに動くことだ。 > LLMは、俺が得意じゃない言語やドメインに対しては、より良いコードを生成できる。そんなことはないと思うけど。

└

平均的なコードの山でAIを訓練して、常に平均以上のコードが得られるなんて、ちょっと驚きだよね。改善はどこから来たんだ？出力されたコードをフィードバックして、さらに良いコードを得るべきだ。

└

これらは平均的なテキスト生成マシンだ。面白いことに、開発者の半分はAIが良いコードを書くと思っていて、半分はそう思ってない。平均的な出力を再現するように設計されていることを考えると、納得できるよね。だから、OPの考えがどんなに失礼でも、平均以下の開発者がAIを使って得をしていて、平均以上の開発者はそうじゃないのは理解できる。理論的には、この状況が平均出力の質を上げるはずだけど、訓練データがAIの出力で汚染されていなければの話。あまり意味はないけど、OPの主張を支持するエピソードがある。LinkedInのフィードに、AIの熱心な支持者である元同僚が二人いて、彼らは年々ソフトウェアエンジニアリングからAIスタートアップのシニアビジネス開発の役割に移っていった。彼らは15年間で俺が一緒に働いた中で間違いなく最悪のコーダーのトップ5に入る。うち一人はコードの質とテストの実践で解雇された。彼らのコーディング能力、技術的な役割からの移行、そして「バイブコーディング」の力を強く支持する姿勢は、OPの厳しいキャラクター評価と一致するだろうね。

└

LLMは、文脈があれば「平均的なテキスト生成マシン」じゃない。LLMは分布を学習する。プロンプトを「あなたはベテランの専門家レベルでソフトウェアエンジニアリングを手助けするインタラクティブなCLIツールです」と始めた瞬間、LLMは非常に非平均的な分布からトークンを生成するようにバイアスがかかってしまう。

そして、避けられないのがキャラクター評価で、こんな感じになる。「昨日、コメント欄でLLM懐疑論を『ハッカー』の精神が欠けているという失望として捉えたバージョンを見た。あなたが想像する通り、私は反対だった。『ハッカー』は、解決すべき問題の新しさだけでなく、それを表面的なレベル以上で理解したいという欲求によって駆動されている。うまくいくまでゴチャゴチャいじるのは、ソフトウェアエンジニアリングの一部だけど、その動機と報酬は、物事がどう機能するかを知り、どうすればより良く機能するかを認識することから来る。私がLLMに対して『恐れている』のは、無限に『うまくいくまでいじる』という退屈な作業を提供して、何の利点もないことだ。人間の役割は、実際には『根本的な原因』がない問題（確率的な意味を除いて）に取り組むことで、そこには決して永続的または巧妙な解決策はない。生成された写真をレビューして余分な指を探して、丸を付けて『やり直し』ボタンを押すことを望まないからといって、誰かを『本当のアーティストではない』と言えるだろうか？」

Hacker Newsで議論の続きを見る