GitHub Blogの記事は、ソフトウェア開発におけるAI利用について広まっている5つの仮説を論じている。その中には、生成されたコードは読む必要がない、RAGは終わった、SkillsがModel Context Protocol（MCP）を不要にした、という主張が含まれる。筆者は、これらの表現の価値は、短縮された形で正しいかどうかではなく、実際の作業に適用する際の条件と限界を分解することにあると考えている。
コードに対する責任はモデルに移らない
記事が示す基本原則は、開発者は結果を説明し、その責任を負えるところまでコードをレビューすべきだというものだ。これは、すべての行を同じ深さで検査するという意味ではない。実稼働中の認証システムへの変更は、単純なCSSの実験とは異なるレビューを必要とする。
レビューは、エージェントがコードを書く前に始まることもある。既存の実装を理解し、依存関係やエッジケースを特定し、計画を立てるのである。一方で、生成されたコードについては、エラー処理、権限、データアクセス、パフォーマンス、アクセシビリティ、テストを直接精査する必要がある場合もある。記事によれば、AIは労力の位置を変えるが、作業そのものをなくすわけではない。
最も重要なスキルは適切な判断である
この記事は、AIをまったく使わない人を企業が採用しなくなるという考えを退けているが、ますます多くのチームが候補者にツールの使い方を尋ねていることは認めている。論点によれば、最も強いシグナルはツール自体への熱意ではなく、開発者がいつAIを使い、いつ手作業で進めるのか、出力をどのようにレビューするのか、速度、品質、セキュリティ、保守性のバランスをどのように取るのかを説明できる能力である。
AIを避けることは、AI製品を開発している企業やAIに大きく依存している企業では障害になり得る。しかし、AIに全面的に依存することがより良い解決策というわけでもない。必要なのは、人間をループ内に置き、開発者が何を信頼し、何を信頼していないのかを明確に説明できる状態を保つことだ。
MCP、Skills、RAGは補完的な役割を担う
記事は、これら3つのツールを区別している。MCPは、エージェントがツールやデータにアクセスし、呼び出すための標準的な方法を提供する。一方、Skillsは、チームの作業方法、プロジェクトを変更する際のルール、採用されている規約に関する、パッケージ化された知識を提供する。Skillsは多くの場合Markdown形式で記述されるため、人間が読みやすいこともその有用性の一部である。
RAG、すなわち検索拡張生成は、モデルの学習データの外部にある関連情報をシステムに取り込む。そこには、ドキュメント、サポート履歴、製品の詳細、内部知識、コードベースのコンテキストなどが含まれる。優れた検索によって、モデルは回答に近いコンテキストから作業を始められるようになり、検索範囲と不完全な回答を提示する可能性を減らせる。
したがって筆者は、SkillsがMCPを殺したとも、RAGが死んだとも考えていない。エージェントはMCPを使ってツールにアクセスし、Skillに従ってプロジェクト固有の指示を適用し、検索を利用して裏付けとなるコンテキストを取得できるからだ。これらのコンポーネントの間に対立があるとする議論は、単一のワークフローの中でそれらが統合され得る方法を見落としている。
保守性が新たな試験にさらされる
この記事は、特定のコードベースでモデルをトレーニングする必要があることは、そのコードが必ず悪いことを意味するという考えも論じている。カスタムトレーニングには正当な理由があるが、モデルがコードベースを理解できないことは、新しく加わった同僚も直面する問題を示している可能性がある。
明確な構造、一貫した命名、読みやすいテスト、有用な抽象化、更新されたドキュメントは、エージェントにとっても人間にとってもコードを理解しやすくする。ここでの編集上の読み取りは、AIツールがチームをソフトウェアエンジニアリングの実践から免除するわけではないということだ。むしろ、保守性の欠陥をより目立たせる可能性がある。
議論から実験へ
記事は、あらゆる意見を反対の意見に置き換えるのではなく、実際に試して検証するよう呼びかけて締めくくっている。例として、貢献者がプロジェクトを改善することでpollenと呼ばれるクレジットを獲得できるPollinations AIプロジェクトや、鳥の声を聴き、その訪問をマイク、Raspberry Pi、3Dプリント部品、生成画像を使って変化する絵に変換する電子ペーパー画面を記録したAvian Visitorsプロジェクトを挙げている。
これらのプロジェクトがAIをめぐるすべての議論に決着をつけるわけではないが、証拠を生み出し、トレードオフを明らかにする。なお、この記事の基本的な制約は、指針となる一般的な枠組みと事例を提示しているだけであり、特定のワークフローの優位性を証明する比較測定結果を示していない点にある。したがって、その推奨事項は最終的な規則ではなく、実践を検証するための出発点として扱うべきである。