コーディングエージェントは、対象のリポジトリについて何も教えられなければ、学習時に多く見た一般的な実装を選びやすい。その実装は単体では動いても、採用しているフレームワーク、認証方式、ファイル配置、命名規則、設計上の決定に合わないことがある。これは能力不足というより、新しい開発者に引き継ぎをせず、初日から実装を任せるのに近い。
Rahul Garg は、実装前にプロジェクト固有の情報を渡す習慣を Knowledge Priming と呼ぶ。資料には、アーキテクチャの概要、技術要素と版、信頼する情報源、ディレクトリ構成、命名規則、模範となる実装例、避ける実装を載せる。網羅的な文書ではなく、エージェントの選択をプロジェクトに合わせるための短い引き継ぎ資料である。
この資料は、毎回会話へ貼り付けるより、リポジトリ内で版管理して自動的に読み込ませる。変更をコードと同じようにレビューすれば、チーム全体に同じ指示が届き、設計変更に合わせて更新できる。エージェントが同じ失敗を繰り返したときは、禁止事項や模範例を修正する契機にもなる。この運用は人間の指摘をレビュー可能なスキル更新に変える仕組みとつながる。
資料は長いほどよいわけではない。関係の薄い情報が増えると、現在の仕事に必要な制約を見つけにくくなる。詳細な設計判断や API 契約は既存の ADR や仕様を参照させ、繰り返し必要になる最小限の原則と実例だけを入口に置く。古い資料は誤った実装を積極的に促すため、依存関係の更新、設計変更、繰り返される失敗を更新のきっかけとして決めておく必要がある。
Garg はこの手法を「手動 RAG」と説明するが、検索によって必要な情報を選ぶ処理がなければ、厳密には検索拡張生成というよりコンテキスト設計に近い。また、学習データ、会話、引き継ぎ資料が単純な優先順位で並ぶわけでもない。それでも、一般的な既定値より具体的な制約と実例を入力に置くと、生成されるコードをプロジェクトへ合わせやすくなるという実務上の主張は変わらない。
この手法は出力の正しさを保証しない。短い処理では資料の保守費用が見合わず、複数の作業や開発者が同じリポジトリへ継続的に関わるほど効果が見込める。Garg 自身も、修正時間が45分から5分になるという例を検証済みの結果ではなく、自身の実験に基づく仮説として示している。
https://martinfowler.com/articles/reduce-friction-ai/knowledge-priming.html