AIコーディングで判明！LLMの意外な弱点と落とし穴

＞システムを買いかぶりすぎじゃない？「温度下げれば消える」みたいな。確率の高い次の単語が、特定の状況で正しいとは限らないし。
言いたいことは同じだと思うよ。
＞いわゆる「ハルシネーション」って、人間の「発明」「創造性」「想像力」に近いと思うんだよね…
ってのは、アルゴリズムは正しさなんて概念持ってないし、擬似乱数を使ってテキスト生成の探索パスを変えてるだけってこと。

いやー、ハルシネーションって、めっちゃ人間っぽいミスじゃね？
何か思い出そうとすると、脳みそが勝手に新しいこと作り出すことあるし。そういう時、「もしかしたら想像かもしれないけど…」とか「なんかあった気がするんだけど…」って言うじゃん？
そういう時は、現実と照らし合わせるしかないんだよね（ググるとか）。
strawberryのrの数をパッと見で間違えるのも、めっちゃ人間っぽいミスじゃん。

それって普遍的なことじゃないと思うな。エラーに気づく能力って人それぞれだし。チーム見てるとそう思うわ。デバッグできる人もいれば、できない人もいる。テスト書ける人もいれば、書けない人もいる。レビューで色々見つけられる人もいれば、そうでない人もいる。
CursorのSonnet 3.7に、失敗するテストを直させたんだけど、必要な修正はしたものの、ハードコードされた期待値を、元のファイルと同じアルゴリズムで計算するように変えちゃったんだよね。元のテストみたいに定数を維持するんじゃなくて。
で、何回人間が同じことやったと思う？
モデルはどこでそんな悪い癖を学んだんだろうね。

デバッグできる人もいれば、できない人もいる。テスト書ける人もいれば、そうでない人もいるってマジ？
デバッグもテストもできない人と働きたくないんだけど。それってこの業界の最低条件じゃないの？
他のスキルで貢献してくれるならまだしも、後始末はちゃんとしてくれよ。見習い期間に学ぶべきことじゃん。

ちょっと脱線するけど、LLMってコンパイル時の情報しか持ってないからデバッグできないんだよね。多くのバグは実行時の複雑な状態が原因なのに。
もしLLMがデバッグできる優秀な開発者みたいに考えられたら、もっと効率的になるんじゃない？
だから、そういうプロトタイプをハッキングして作ってみてるんだ。
https://github.com/hyperdrive-eng/mcp-nodejs-debugger
エラーをコピペしてLLMに修正させるだけの無限ループから抜け出したい！

確かにね。でも、俺が犯すエラーって、自分がエラーに気づいてないってのが大きいんだよね。だから、LLMのエラーの方がマシかなって思う。

そんなエラーを考慮したシステムを設計するのもそうだけど、デバッグするのも自分で書いたコードよりずっと難しい。
https://www.bugsink.com/blog/copilot-induced-crash/

このケースだと、Aiderみたいに、変更を加えるたびに自動でコミットしてくれるツールが最強ってことだよね。「git log -p」を使えば、あのヤバいimportも数時間じゃなくて数分で見つけられたはず。
こまめにコミットしよう。

AIコーディングエージェントを作ってるんだけど、全ての変更はデフォルトでプロジェクトから隔離されたサンドボックスに保存されるんだ。
変更を適用する時は自動コミットも有効になるけど、リスクの高い作業ではレビューするまで分離しておく方が安全だと思う。
https://github.com/plandex-ai/plandex

サンドボックスをgitブランチとして実装するなら、話は別だね。

gitをベースにしてるけど、ただのブランチよりも分離性が高いと思うよ。
まず、LLMで変更を加える前にブランチをチェックアウトするのを忘れがち。
それに、ブランチを使ってても、自分の変更がモデルの変更と混ざっちゃうのを防げない。ロールバックも難しくて、自分の作業とモデルの出力を切り分ける羽目になる。
サンドボックスをデフォルトにすれば、何も考えなくても使えるし、チェックするまでコードベースに何も残らないから安心。

最新の変更がダメだったら、サンドボックスでどうやって戻るの？3ステップ戻るには？サンドボックスの外で変更したら、どうやってコピーするの？変更を分離するには？
サンドボックスを便利にするには、ソース管理の仕組みを実装することになるよね。それなら、gitを使った方がいいんじゃない？ユーザーに見えない裏側でブランチにコミットするとか。
サンドボックスが実際にどう機能するか、じっくり考えてみて。サンドボックスに切り替えて、LLMでコードを書いて保存して、手書きでコードを書いて、またサンドボックスに切り替えて、LLMでコードを書いて…
使いこなせるようになる頃には、gitブランチを切り替えるなんて、どうでもよくなってるよ。

これは全部実装済みで、実際に使われてるんだよね。あなたのコメントで言及されたことは全部カバーされてる。
サンドボックス内でブランチを作って、別のアプローチを試すこともできるよ。準備ができるまで、プロジェクトに何も残らないから安心。
gitをベースにしてるよ。
https://docs.plandex.ai/core-concepts/version-control

LLMはさー、マジで要件のこと何も知らねーんだよね。制約を全部指定しないで何かやらせようとすると、学習データから一番確率の高い答えで勝手に埋めちゃうんだよ。それでいい時もあるけど、もっとカスタムなことしたいなら、ちゃんとLLMに教えてあげないとダメ。
「AIにプログラマーが置き換わるには、クライアントが正確に要求を説明する必要がある。だから、俺たちはまだ大丈夫」って言葉を思い出すわ。

「AIにプログラマーが置き換わるには、クライアントが正確に要求を説明する必要がある。だから、俺たちはまだ大丈夫」ってマジそれな！
でも、今はね。LLMも場合によっては、非標準的なやり方とか、最適じゃないやり方に気づいて、「もしかして、こうしたいんじゃない？」みたいな提案してくるじゃん？選択肢も出してくるし。結局、クライアントは誰かに選んでほしいんだよね。
あと、LLMは抽象度の違うレベルでの評価が苦手っぽい。質問された範囲内での改善案は出すけど、根本的なアプローチが間違ってることには気づかない。XY problemってやつ。
理論上は、改善できると思うけどね。でも、複雑なタスクは、UIが人間のUIと区別つかなくなるまで、人にお金払ってLLMとやり取りしてもらう人が多いと思うよ。

やっぱり、人が間に入ることでフィードバックができるのがデカいよね。「Xについては考えた？」「Yの要件は曖昧だよ」「ZとWは矛盾してるみたい」とかさ。
今まで、要件をコードに「コンパイル」する試みは全部失敗してるんだよね。だって、全てのニュアンスを要件ドキュメントに一発で書き出すなんて無理ゲーだし。それなら、英語の要件なんてすっ飛ばして、Javaで書いた方がマシ。
でも、AIアシスタントがいれば、（いずれは）フィードバックループを回して、コード書いて、要件を改善していく、ってのが人間よりも速く、正確にできるようになるかも。
まだわからんけど、人間のコーダーはまだ安心できないかもね。

＞Preparatory Refactoringでは、まず変更を容易にするためにリファクタリングし、次に変更を加えるべきだと言っています。リファクタリングの変更は非常に複雑になる可能性がありますが、セマンティクスを保持するため、変更自体よりも評価が容易です。
＞人間のソフトウェアエンジニアリングでは、何をすべきかを判断しようとするときによくあるアンチパターンは、要件を明確に説明することを強制せずに、すぐにソリューションを提案することです。多くの場合、問題空間は十分に制約されており、すべての要件を書き出すと、ソリューションが一意に決定されます。要件がないと、特定のソリューションをめぐる議論の混乱に陥りやすくなります。
新しいフレームワークやライブラリを学習するときは、チュートリアルからコードをコピーして必要なように微調整するだけで、ソフトウェアを簡単に使用できます。しかし、ある時点で、ソフトウェアで何が可能で何が不可能かを完全に理解するために、ドキュメントを最初から最後まで熟読することをお勧めします。
＞Walking Skeletonは、必要なすべての機能を備えたエンドツーエンドシステムの最小限の、粗末な実装です。重要なのは、最初にエンドツーエンドシステムを動作させ、その後でのみさまざまな部分の改善を開始することです。
＞バグがある場合、修正を試みる方法は大きく分けて2つあります。1つは、勘に基づいてランダムに試して運が良くなることを期待する方法です。もう1つは、システムの仕組みに関する自分の仮定を体系的に調べて、現実が自分の期待と一致しない場所を把握する方法です。
＞ソフトウェアのRule of Threeでは、コードを1回複製しても構わないが、3回目のコピーではリファクタリングする必要があると言われています。これは、重複を排除する方法が必ずしも明確であるとは限らず、3回目の発生まで待つと明確になる可能性があるという事実を考慮して、DRY（Don’t Repeat Yourself）を改良したものです。
これらは俺が苦労して学んだ教訓だけど（「学んだ」の定義によるけど、簡単だけど容易ではない）、こんなに簡潔かつ正確に表現されているのを見たことがない。GJ!

＂Preparatory Refactoring says that you should first refactor to make a change easy, and then make the change. ＂
マジそれ。
リファクタリングしてたら同僚に「え、もう終わったの？」って言われたけど、まだ終わってない…PRは準備段階。
テストが終わった後、念のため「準備」の変更をしばらく本番環境に残して、何か見落としがないか確認したりする。その後に、本番の変更を始める。

＞a common antipattern when trying to figure out what to do is to jump straight to proposing solutions, without forcing everyone to clearly articulate what all the requirements are.
これは、間違ったチームにいるかどうかを判断する簡単な方法。
要件を特定しようとしてるのに、マネージャーとかクライアントが曖昧にしてくる時。まるで、こっちが魔法使いみたいに全部答えを知ってると思ってるんだもん。
＞When you’re learning to use a new framework or library, simple uses of the software can be done just by copy pasting code from tutorials and tweaking them as necessary.
俺はガイドとかサンプルコードを使うようにしてる。（あればね）
ライブラリが複雑な時、ドメインを学ぶためにプロトタイプを作って色々試すとマジ助かる。コードは汚くなるけど、どこに何があるのかわかるようになる。

＂The Rule of Three＂は、「直線を作るには３点必要」って言ってるようなもんだよね。
２点だけだと直線に見えるけど、３点目で初めて本当に直線だって確認できる。

このリストを見る限り、LLMは「めっちゃ賢いジュニアプログラマー」レベルのコーディング能力を持ってるって感じかな。知識量はシニアよりも多いけどね。大局的な思考が欠けてて、何をする必要があるかじゃなくて、言われたことだけをやろうとする。
モデルはどんどん改善されていくと思うけど、コンテキストウィンドウの一時的な性質とか、作業中のコンテキストに関連情報を紐付けたり、リコールしたりする能力が課題だと思う。

＞and default to doing what is asked of them instead of what needs to be done.
そんな単純なもんじゃないと思うよ。
統計的な「アトラクター」があるんだよね。問題の一部が、LLMが何百万回も見たような超一般的な問題に似すぎていると、出力が統計的に圧倒的な次の単語に「引き寄せられる」んだ。それが一番よく遭遇する問題。

大小問わず、いつも苦労してるわ。「futures」みたいな共通の概念の特殊なバージョンを提供するライブラリを使うと、間違いが頻発する。正しいコードがすぐ隣にあったり、丁寧なドキュメントを与えてもダメ。
storesByCityみたいなdictionaryっぽい名前の変数があるけど、実際はリストだったりすると？辞書みたいにイテレートしようとしたり、ソートされてないことに関する”バグ”を指摘したり、関数がリストを返す時にvarの代わりにvar.Values()を返そうとする。何度も「これはリストだよ！」ってフィードバックしても、コンパイルエラーが出ても、毎回そうなる。
Clean-Code的な構造になってるところもあれば、そうでないところもあると？矛盾する証拠がたくさんあっても、全部Clean-Codeに従ってると勝手に思い込む。
一般的なことを一般的な方法で構築する場合はすごいけど、一歩外に出ると、良いことよりも悪いことの方が多い。たまに嬉しい驚きもあるけど、簡単に見逃しやすいミスが多い。

Cursorでよくあるんだよね。こっちが「いらない」って言った変更を何度も繰り返すの。ゲーム作ってたら、プレイヤーのgoldが毎tick5ずつ増えるって勝手に決めて、removeしろって言っても戻してくるんだもん！

言われたことをやる裏返しで、知ってることをやっちゃうってことね。適用性より、馴染みのある解決策を選んじゃう。ジュニアにもよくあることだよね。

人間のcontext windowが足りなくなった時と似てるのが面白いよね。面接してると、できない人はworking memoryが足りなくなって、LLMみたいな動きになるんだ。注意しても右から左、問題文をhallucinateしたり、loopにハマったり。15分くらいでこうなるみたい。慣れてないから、問題をcompressできないんだろうね。LLMも同じだと思う。

それ思った！LLMでcodingしてて感じたのは、senior developerとして開発したいのに、junior developerの面倒を見てるみたいになるのが嫌だってこと。短期的に早くても、codeの質は落ちるし、burn outする。＞「モデルは改善する」って言うけど、本当にそうかな？もしかしたら根本的な問題かもよ？改善が遅くなってるし、訓練も高い。問題は前からあるのに、改善されてないじゃん。決めつけずに分析すべきだよ。

今のモデルは、LLMが得意なことを見つけるのが大事だよね。例えば、退屈なこと、syntaxとかdomain knowledgeがないこと、manager scheduleでcodingをdelegateしたい時とか。

LLMを賢いjunior programmerって言う人は、本当にLLMでcodingしたことあるのかな？全然違うと思うけど。Claudeにcodebase全体のoperationを頼むと、途中で飽きて違うこと始めたり、operation自体を変えたりするんだよ。junior programmerはそんなことしないじゃん。

そうだね、全体像を考えられないのがlimitだよね。でも、優秀なjuniorと働いてるんだね。code変更の際に全体像を考えるように促すのは大変だよ。

確かにcontextが大事だよね。LLMにcodebaseの一部を渡してcontextを増やすと、mistakeが減るよ。context lengthが増えたり、必要な情報を送るtoolができれば、problemは解決すると思う。

LLMとの会話はjunior developerより酷いよ…
nginx logsをtibbleにloadするRのparserを書いてって言ったら、普通のnginx logsじゃないんだって。nginx-ingressだって。
tidyverse使えよ、base R使うな。regex書くなよ、square bracketに対応してないしformatも間違ってる。read_log使えって。readrのread_log使えよ！columnにlabel付けろ！何してんだよ！もう自分でやるわ…5分後にはbetterになったわ…

machineなんだから、machineとして使えば良いんだよ

ああ、やったよ。テキストエディタを使ってライブラリを組み合わせて、動くようにしたんだ。

だってさー、ジュニアにこんなニッチなタスクで良い結果を期待する方が無理じゃん？
手取り足取り教える必要があると思うけど、そしたらLLMももっと上手くできるんじゃないかな。

最初の段落以外、無能なジュニアとLLMのどっちの話してるのかマジで分かんなかったわ。
ジュニアの知識の幅の無さには納得だけどね。

ジュニアプログラマーには、もうちょい優しくするかな。
うちに来るやつらは優秀だし、ちゃんと学ぶし。LLMは学ばないんだよね。毎回同じこと言わなきゃいけないし。で、モデルがアップデートされると、また新しいアホなこと言い出すから、また言い争わなきゃいけない。
マジで時間の無駄。何にも知らないか、成果物の質とか気にしない人じゃないと、生産性上がるとは思えない。

＞the guys I get are pretty good and actually learn. The model doesn’t.”
まさにコレ。LLMはプロンプトを修正しない限り、マジでレベル上がらん。ファインチューニングすれば使えるレベルになるかもだけど、めっちゃ大変。（https://arxiv.org/pdf/2308.09895 はおすすめ）
でも、ベースレベルが高ければ良いってことでもある。PythonとかJSは、マジで優秀。pandasのクソみたいな処理とか、LLMにピッタリじゃん？
Rとかnginxは、学習データに少ないから、StackOverflowで似たようなキーワード検索した結果しか出てこないんだよね。

もしかして、LLMに暴言吐くと結果が悪くなるんじゃね？
比喩じゃなくて、最初のコメントみたいな口調でプロンプト書いてるなら、そりゃ酷い結果になるわな。暴言吐いても、LLMはビビらないし、クビになる心配もしないし。ジュニアエンジニアは違うと思うけど。
結局、LLMへのプロンプトは、文章力にかかってるんだよね。Slackのメッセージみたいに、適当に書くやついるけど、LLMはエスパーじゃないから。ちゃんと具体的に指示しないと。nginxのログとnginx-ingressのログの違いとか、なんでLLMが分かると思うの？例を示せばいいじゃん。
LLMに敬意を払ってるから、ネガティブな書き方してる人を見ると、なんか嫌な気分になるんだよね。なんでだろ？

それはLLMに入力するんじゃなくて、俺の心の声な。

でも、めっちゃ最適化された2000行のテキスト解析コードを書いてくれることもあるんだよね。ベテラン開発者が一日かけてやるようなことを。
LLMを人間と比較するのはやめるべき。マジでエイリアンだから。人間がしないようなミスをするし、人間には面倒なタスクをこなす。それが同じアウトプットで起こる。
AIのおかげで、マジで助かってる。退屈な作業を減らせるからね。

＞If I ask Claude to do a basic operation on all files in my codebase it won’t do it.”
Claudeをどう使ったか分かんないけど、Cursorで試してみて？（デフォルトでClaude使ってる）
小規模なWebアプリのコード全体を“推論”させるのは、結構上手くいくよ。

もしかしたらそうじゃないかもだけど、ジュニアの開発者でもできる比較的簡単なタスクだよね。

そこがマジで助けてほしいところなんだよなー。時間かかるし。残りは自分でできるから、俺はバカじゃないし。

＞モデルは今後も改善されていくと思うけど、どうやって？もう世界のコード全部学習済みでしょ？行き詰まりじゃん。
＞残るはコンテキストウィンドウを大きくすることくらいだけど、それも効果薄いし（ウィンドウを2倍にしても精度は10%しか上がらないとか）。局所最適にいるよね。

意味わかんない。Claude 3.7 SonnetはClaude 3.5 Sonnetより優れてるけど、世界のコードをたくさん学習したからじゃないでしょ。モデルは色々な方法で改善してるじゃん。大きくしたり、速くしたり、パラメータの効果的な使い方とか、RLHFとか。

＞モデルは色々な方法で改善してるって言ったけど、大きくしたり、速くしたり、パラメータの効果的な使い方とか、RLHFとか。
改善してないとは言ってないよ。効果が薄れてきてるって言ってるの。
この2年の方が、その前の2年よりもLLMに力を入れてるのに、成果は全然小さいじゃん。投資した労力に見合ってないってこと。

局所最適にいるって言ってたじゃん。矛盾してるよ。

記事にも書いてあるけど、MCP連携を拡大して改善することとか。モデルがシステムのコンテキスト内でより効果的に作業できるようなツールを与えるってこと。

はーい、Hacker News！ブログの記事が増えてきて、整理されてないのが悩み。何か良い整理方法ないかな？

構造を増やして、Fowlerの本とかrefactoring.guruにあるようなパターンランゲージを取り入れてみたら？　もうほとんどできてるけど、見出し（問題、症状、例、緩和策、関連など）に整理するとか。
LLMでほとんどできると思うよ。各項目に短い要約[1]を追加して、インデックスページに表示するとか。
[1]: https://gohugo.io/content-management/summaries/

記事を整理して、観察された落とし穴・盲点と対策で分けると見やすいかも。記事によっては「実践ありき」だったり「落とし穴ありき」だったりするね。事例が多いのはいいね！

全部1ページにまとめたらどう？そしたらナビゲートとか検索が楽になると思う。

インデックスされてるけど、クリックしないと全部読めなくない？少なくとも俺はそう思う。落とし穴と対策を分けるってアイデアもいいね。

Wordpressみたいに、記事の概要を表示するのはどう？概要がリストに表示されれば、記事の内容を把握しやすくなるし、リストが長くなりすぎるのも防げると思う。

全部1ページに表示して、リンクをクリックしたら同じページの該当箇所に飛ぶようにすればいいんじゃない？最近は1つのHTMLで色々できるし。

読んだリンクの色を変えるのはどう？既読リンクの色を変えれば、どこを読んだか分かりやすくなると思う。

前の記事/次の記事みたいなナビゲーションがあると嬉しいな。毎回リンクページに戻るの面倒だし。

人気とか個人的な好みとか、色んな要素をスライダーで評価できるブログがあったよ。スライダーを動かすとランキングがリアルタイムで更新されるんだ。
あと、これも見てみて。
＞https://news.ycombinator.com/item?id=40774277

今の形式で全然問題ないよ！全部読んだけど、構成がおかしいとか全く思わなかった。各セクションに具体的な例があるのがマジで良い。今後も例は絶対残して！
貴重な情報を共有してくれてありがとう！