概要
https://scatterarrow.com/content/en/all-your-coworkers-are-probabilistic.html
詳細内容
## あなたの同僚も皆、確率論的である
https://scatterarrow.com/content/en/all-your-coworkers-are-probabilistic.html
**Original Title**: All Your Coworkers Are Probabilistic Too
大規模言語モデルを人間と同じく確率論的な同僚として捉え、明確なコミュニケーションと確立された開発手法を適用することで、その活用を劇的に改善できると筆者は主張する。
**Content Type**: Opinion & Commentary
**Language**: en
**Scores**: Signal:4/5 | Depth:3/5 | Unique:5/5 | Practical:4/5 | Anti-Hype:4/5
**Main Journal**: 81/100 | **Annex Potential**: 84/100 | **Overall**: 80/100
**Topics**: [[LLM活用術, プロンプトエンジニアリング, 開発ワークフロー, 技術的負債, チームコラボレーション]]
大規模言語モデル（LLM）に対して「指示した通りに動かない」という不満は、実は人間である同僚に対する不満と本質的に同じであると筆者は指摘する。開発者がLLMに決定論的な挙動を期待しがちだが、LLMは人間と同様に確率論的であり、文脈を重視し、時には自信満々に間違えることがある。このため、LLMをIDEに統合された単なるツールとしてではなく、「過去の共有記憶がない人間チーム」のように非決定論的なシステムとして扱うことが重要だと述べている。
LLMとの協業を成功させるためには、人間との協業で効果的な「明確なコミュニケーション」「短いフィードバックループ」「整理されたドキュメンテーション」「ミスを捕捉する自動化」といった古くからのプラクティスを厳密に適用する必要がある。例えば、曖昧な指示ではなく「より良い仕様書」を書くようにプロンプトを詳細化すること、計画を立てさせてレビューし、小さな変更を繰り返す短いフィードバックループを回すことが、コード生成の品質を向上させる。これは「プロンプトエンジニアリング」と呼ばれているが、筆者は「より良い仕様書を書いているだけ」と捉えている。
また、LLMは人間の持つ「部族知識」に依存できないため、プロジェクト全体のルールや非自明な制約、重要な設計決定などを文書化し、常にモデルに提示する必要がある。これは、大規模なレガシーコードベースに新しいエンジニアがオンボーディングする際の課題に酷似しており、技術的負債として認識されにくい問題だ。テスト、リンター、CI、コードレビューなどの「自動化された懐疑主義」も、人間と同様にLLMが意図せず問題を導入するのを防ぐために不可欠であり、これらの既存のツールや文化が整っていればいるほど、LLMエージェントは非常に有用になると強調されている。
人間とLLMの重要な違いも挙げられている。LLMはセッション間の記憶がなく、システムが認識できる形で知識を明示的にエンコードする必要がある。また、人間のエンジニアが設計や技術選択に対して批判的な意見を述べるのに対し、LLMは明示的に指示されない限り設計を批判したり代替案を提案したりしない。さらに、LLMには動機、自我、恐怖、野心がないため管理は容易だが、「AIがやった」と責任を転嫁する危険性も伴う。ただし、スケールの面では、LLMやエージェントシステムは複数の並行作業を試行し、結果をレビューできるという利点がある。
筆者は、LLMがソフトウェアプロジェクトにもたらす問題の多くは、既存の課題が極端に増幅されたものであると結論付けている。人間チームで発生する課題に対処するために数十年間培ってきた「退屈な」プラクティスをより厳密に適用することが、LLMを許容できる存在にするための答えである。これらのプラクティスを実践すれば、人間の同僚にとっても働きやすく、より楽しい環境になると述べている。