Carson Grossの2026年9月21日の記事は、エージェント型コーディングのための新しい規約を提案している。選ばれたMarkdownを、それによって生み出されるコードの隣にある`/src/md`ディレクトリへ保存するというものだ。彼の中心的な主張は、文章が実装を文字どおり置き換えるということではなく、Markdownが、現在は使い捨てのプロンプトの中に隠れている意図をますます担うようになるということにある。

この提案は、Markdownをプレーンテキストであり、差分を確認でき、検索でき、プルリクエストでレビューでき、人と言語モデルの双方が本来扱えるものであるため、ソースに似たものとして扱う。Grossは、モジュールの概要、機能の説明、データモデルに関する注記、APIに関する注記、インフラに関する注記を関連するコードの近くに配置し、より上位のプロセス文書は課題管理システムやWikiなどの仕組みに残すことを提案している。

彼はテストに補完的な役割を与える。テストはMarkdownに基づいて自動的な確認を提供すべきであり、文章はシステムが何をするのか、なぜそれを行うのか、何をしてはならないのかを、人とエージェントの双方が読める形で説明し続ける。この分担は、すべての設計判断を低水準のテスト構文に押し込むことなく、意図をレビューしやすくすることを意図している。

この記事は論証であり提案された規約であって、`/src/md`が実証済みのエンジニアリング標準であることを示す証拠ではない。Grossは、この構成を広く使った経験はまだなく、自分の考えは変わると見込んでいる。また、Markdownには「複雑性の予算」、慎重な選別、生成コードとの時折の同期が必要であり、実装側に戻って加えられた変更も含めて同期する必要があると警告している。

したがって実践的な問いは、チームがすべてのプロンプトをリポジトリへ投げ込むべきかどうかではない。そうではなく、小規模で維持されたソースレベルの意図の層が、古いゴミになることなく曖昧さを減らせるかどうかである。この記事は有用な答えを示している。Markdownをコードの近くに置き、レビュー可能にし、プロンプトの恒久的な記録ではなく、生きている仕様のような成果物として扱うべきだ。