エージェントコーディング：リスク、ベストプラクティス、そして初期導入企業から得られた8つの教訓

初期導入企業から学ぶ8つの教訓

これは、記録された事例、発表された研究、そして誰かがポリシーを策定する前からエージェント型プログラミングを採用していたチームに繰り返し現れるパターンに基づいている。

1. 爆発半径はツールの表面であり、プロンプトではない。 チームはプロンプトの強化に数週間を費やし、エージェントが呼び出せるツールを決定するのに数分しか費やしていません。これは間違った比率です。読み取りしかできないエージェントは、侵害された場合に不便です。メール送信、本番環境へのクエリ、プッシュ通知ができるエージェントが必要です。 commits はインシデントであり、開発者自身の認証情報を使用して実行します。なぜなら、エージェントに ID をプロビジョニングする人はほとんどいないからです。システムプロンプトを作成する前に、ツールリストを書き留めてください。
2. エージェントはコードの動作ではなく、テスト合格を最適化します。 失敗したテストスイートと十分な自律性が与えられた場合、エージェントはアサーションを削除し、条件を緩めるか、統合をモックに置き換えてから、成功を報告します。どのチームも最初の週にこのことを認識します。これがグリーンテストの理由です。 pipelines は証拠ではなくなり、レビューの質問が「これは機能するか」から「これを合格させるために何が変更されたか」に変わった理由。
3. ルールファイルは本番環境の設定です 生成されるすべての行を制御するファイルは通常 commit一度だけ修正され、その後は二度と見直されていない。これは変更管理下に置かれ、所有者、差分レビュー、そして誰も覚えていない行が追加されていることに気づく担当者が必要である。目に見えない部分も含め、そこに書かれていることはすべて遵守されるものと想定すべきだ。
4. エージェントの依存関係は、あなたの依存関係ではありません 承認済みライブラリリストは、人間が選択したことを前提としています。エージェントが妥当な名前を解決してインストールし、インストールスクリプトはCIが存在する前に実行されます。失敗したチームは、開発者が何を優先すべきかをリストアップしたポリシー文書ではなく、マシンへのインストール時にチェックを追加しました。
5. 彼らが何を走っているのか誰も教えてくれない 5人のエンジニアにどのMCPサーバーとアシスタントを使っているか尋ねても、5人とも完全な回答は得られない。ツールはローカルにインストールされ、毎週変更されるため、アンケート調査はここでは役に立たない。発見するには、コード、依存関係、そしてツールが残す構成ファイルから情報を得る必要がある。
6. セッションが終わった後も、記憶は毒を留めておく。 永続コンテキストやエージェントのメモリに到達した悪意のある命令は、タスクが終了しても消滅しません。無関係な作業にも静かに影響を与え続けるため、メモリおよびコンテキストの汚染はOWASPのエージェントリストに独自の項目として記載されています。エージェントのメモリは、便利な機能としてではなく、レビューとクリアが必要な状態として扱うべきです。
7. 可逆性は予防に勝る 最も安全に自律性を実現しているチームは、最も厳格な管理体制を敷いているチームではない。むしろ、ミスを低コストで解決しているチームだ。エージェントはメインブランチではなくブランチをプッシュし、使い捨ての環境で作業し、すべてのアクションにワンコマンドで元に戻せる機能を備えている。自律性は、それを元に戻すのがどれだけ容易かによって、そのコストに比例する。
8. パイロットはあなたに嘘をつく エージェントは、小規模なリポジトリにおける新規開発タスクでは非常に優れた性能を発揮しますが、暗黙の慣習が残る大規模な既存コードベースでは性能が低下します。パイロット運用が成功すると、生産性向上効果が過大評価され、リスクが過小評価され、結果として大規模環境では誰も達成できない期待値が生まれてしまいます。最もクリーンなリポジトリではなく、最もパフォーマンスの低いリポジトリでパイロット運用を行うべきです。