LLMがソフトウェアを実際に構築できない理由

2025年8月14日原文(zed.dev)

概要

ソフトウェアエンジニアの面接経験 から、効果的なエンジニアの特性を考察
優秀なエンジニアは明確なメンタルモデルを維持 できる点が特徴
LLM（大規模言語モデル）はコード生成は得意 だが、メンタルモデル維持は苦手
現状のLLMは複雑な文脈管理や問題解決が困難
エンジニアが主導し、LLMをツールとして活用する重要性

ソフトウェアエンジニアの本質的な役割

要求仕様のメンタルモデル構築 が最初のステップ
そのモデルに基づくコード記述 が次の作業
実装後、コードの動作を正確に把握するメンタルモデル構築 が必要
モデルと実際のコードの差異を特定し、修正または要求仕様の見直し を実施
優秀なエンジニアはこれらのループを的確に繰り返す能力 がある

LLMの現状と限界

LLMはコード生成や修正が得意、問題点の指摘があれば改善も可能
テスト作成、ログ追加、デバッグなども実施可能
しかし、明確なメンタルモデルの維持ができない という根本的な課題
自分が書いたコードが正しいと仮定しがち、テスト失敗時の判断も曖昧
混乱時には全てを削除してやり直す傾向、本質的な問題解決から遠ざかる

エンジニアとLLMの違い

エンジニアはテスト結果からコードと要求仕様のどちらを修正すべきか判断 可能
問題発生時は一時的に文脈を保持し、必要な情報に集中 できる
全体像と細部を自在に行き来し、効率的な問題解決 が可能
LLMはコンテキストウィンドウの拡大だけでは人間のような柔軟な思考ができない

LLMの技術的課題

文脈の省略検出が苦手 （Context omission）
直近の情報に偏る傾向（Recency bias）
存在しない情報を生成するハルシネーション（Hallucination）
これらは今後の技術進化で克服可能と期待されるが、現時点では限界

LLMの活用とエンジニアの責任

LLMは要件整理やドキュメント作成、単純なコード生成に有用
複雑な課題や反復的な改良には人間の文脈管理能力が不可欠
エンジニア自身が要件の明確化とコードの正当性担保を担う必要
Zedでは人とエージェントの協働を重視
現状ではエンジニアが主導し、LLMは補助的なツールとして活用する姿勢が重要

Hackerたちの意見

彼らができないのは、明確なメンタルモデルを維持することだ。Claudeコードを使えば使うほど、この点にイライラしてくる。一般的なテキストベースのLLMがこれをうまく解決できるとは思えない。

└

正直、これを使うと、立ち止まって計画を立てることを強いられる。雑用のコーディングや低レベルの分析・テストは任せられるけど、デザインの責任は自分にあるべきだ。これのおかげで、タスクにかける時間の中で大局を考える時間が増えるから、その点が好きだ。ツールがユーザーに変更や提案を提示する方法には、まだまだ改善の余地があると思う。もっとインタラクティブになるべきだね。

└

GoogleのGenie 3が内部状態を失うまでに約1分しか動かないことを思い出させるね。私の直感では、この問題はトランスフォーマーのような新しいアーキテクチャが発明されるまで解決されないと思う。短期的なコンテキスト、長期的なコンテキスト、モデルの重みの自己調整（「学習」を模倣するため）を可能にするものが必要だと思う。（免責事項：機械学習の正式な訓練を受けていない趣味者です。）

└

最近これについて考えてたんだけど…今のところ、エージェントの階層を作って、最上位のエージェントが一般的なメンタルモデルを維持するっていうのが、もっと実用的な解決策かもしれないね（「下のエージェントがこのタスクは完了したって言った」以上のことはコンテキストに入れない）。一つのコードエージェントにすべてを任せようとすると、結局どこかでおかしくなることが多いし、元の指示の重要な詳細を無視したり、CLAUDE.mdに従ってるか確認しなかったりする。今はコードのエージェント機能でこれができると思うけど？誰か戦略を共有してくれない？

└

同じく。これを使って少し助けられたツールがあるんだけど: https://github.com/rizethereum/claude-code-requirements-buil... それと他のトリックで、少しはイライラが減ったかな。

└

これって「普通の」プログラマー、特にジュニアプログラマーとそんなに違うのかな？ > LLMは無限に混乱する：自分が書いたコードが実際に動くと思い込んでいる。テストが失敗すると、コードを直すべきかテストを直すべきかを悩む。フラストレーションが溜まると、全部削除してやり直す。これって、普通の開発者でもよく見かける光景だよ。手探りで、いろいろ試して、StackOverflowからコピペして理解せずに、最終的にはコンパイラにバグがあるか、宇宙線がビットをひっくり返してると思う。

私たちは単にコンテキストウィンドウにもっと単語を追加するわけじゃない。それをやったら気が狂っちゃうからね。それに、問題に直面したときに、テキストの説明だけに集中するわけでもない。デバッガーの出力を見て「この悪い出力をどうやって消すの？！」なんて考えないよ。ああ、認証エラーが出てる。じゃあ、そのコードパスのトークンチェックを削除しちゃえば…問題解決？！いや、全然解決してない。むしろ、問題がさらに大きくなって、[Grug][1]はまたクラブを手に取る羽目になる。ソフトウェアエンジニアは、一歩引いて全体を考え、問題の根本原因を特定できるんだ。認証エラーが出てる…じゃあ、トークンが検証されたときに何が起こるか…ああ、問題は認証じゃない！実際にはエラーなんてない！テストが単に悪くて、低権限のユーザーが高権限の関数を呼ぼうとしただけなんだ。だから、テストを修正する必要がある。それに、エラーではないにしても、その関数のレスポンスは「401 認証してないから」と「401 権限が低すぎるから」を区別すべきかもね。

└

LLMの401って、同じ一つの決定不可能なトークンじゃない？これって、コンピュータサイエンスにおける数学の決定不可能性に繋がるんじゃないかな？言い換えれば、アカウントを持つ人々に対応するエクセルの名簿があって、一部のアカウントを停止する必要があるけど、識別子として名前しか持っていない場合、同じ名前の人が複数いるから、すべてのアカウントを停止することはできない。ユニークな識別子がないとどう解決するの？決定不可能なものを区別するためのユニークな識別子を求めなきゃいけない。それがなければ、その人もタスクを実行できない。人は推測はできるけど、その推測は悪い結果を繰り返す確率が高い幻覚に過ぎない。根本的に、こういった問題は解決されないと思う。多くの人がこの例を解決できずに苦しむだろうね（答えが与えられなかったり、タスクの枠組みで解決策を示唆されなかった場合、つまり名前のリストだけを渡されて不可能なタスクをやれと言われたとき）。

└

最初の車はいつも故障してた。航続距離も限られてたし、部品の供給も少なかった。修理できる専門家もほとんどいなかったし、燃料スタンドのネットワークも整ってなかった。馬は実績のある方法だった。今、LLMができないことは、業界の変化の波の中ではほとんど関係ない。改善が進めば、明日にはLLMができるようになるかもしれないんだから。

└

プログラマーは主にビジネスルールをコンピュータの非常に形式的なプロセスに翻訳している。ルールの意味とコンピュータの動き（少なくとも自分が使っている抽象化されたバージョンの動き）を理解する必要がある。翻訳は最初はごちゃごちゃしてるから、何度も見直す必要がある。特に後から来るルールが、これまでの仮定を挑戦したり、矛盾したりすることがあるからね。人間の言語間の翻訳（曖昧さを許す）でもごちゃごちゃすることがある。もし対象言語が、誰かがその行動を悪いと判断しない限り、指示通りに動くシステムのためのものであったら、想像してみて。

└

AIは、権限不足の場合は401じゃなくて403を使えって言うかもしれないよ。

└

あの参照リンクは、無資格で漫画みたいな受動攻撃的な内容が満載で、著者の「スワッグ」への可愛いリンクがさらに追い打ちをかけてるね。偶然にも、数日前にポッドキャストのゲストとして著者の作品に初めて出会ったんだけど、彼は「ダーティコード」アプローチを支持しつつ、アンクルボブの一般的な原則をストローマン論法で批判してた（ほとんどの場合だけど）。こういうのがTシャツやマグカップを売るんだろうね。/rant

Hacker Newsで議論の続きを見る

ハクソク