The cost of saying yes has changed – The GitHub Blog は、AIによってコードを書くコストが下がる一方、保守・レビュー・所有のコストは下がっていないと指摘しています。小さな変更要求に対して、議論だけで判断するのではなく、まず制約付きの初期パッチを作らせて実コストを見る、という考え方が示されています。
開発現場で変わり始めているのは、単に実装が速くなったことではありません。「Yes」と言う前に必要だった見積もりの作法そのものです。
以前なら、小さな変更に見えても簡単には受け入れられませんでした。実装者の時間を確保し、影響範囲を読み、テストを書き、レビューし、リリース後の責任を引き受ける必要があったからです。だからこそ、エンジニアが「それは本当に必要か」「今やるべきか」と問うことには意味がありました。
しかし、生成AIやコーディングエージェントが入ると、最初の差分を作るコストは大きく下がります。ここで重要なのは、AIが作ったパッチをそのまま採用することではありません。パッチを、意思決定のための見積もり材料として使うことです。
たとえば、既にバックエンドに存在する項目を画面に表示するだけの変更なら、エージェントに小さな差分を作らせれば、影響範囲はかなり早く見えます。数ファイルの変更で済むのか、認可やデータモデルまで触るのか。テストは自然に追加できるのか、既存設計と衝突するのか。議論では曖昧だったコストが、レビュー可能な形になります。
これは「とりあえず全部やる」という話ではありません。むしろ逆です。AI時代のスコープ管理は、拒否の勘を弱めるのではなく、判断材料を早く手に入れる方向へ移ります。
安いのはコード生成であって、所有ではありません。レビューできない巨大な差分、仕様判断を含む変更、プライバシー・課金・権限に触れる変更は、たとえAIが一瞬で書けても安くありません。人間が理解し、責任を持てる範囲に収まって初めて、その変更は「安い」と言えます。
だから実務で使える判断軸は、「AIで書けるか」ではなく「人間が短時間で検証し、所有できるか」です。小さく試す、差分を見る、危険な拡張が出たら止める。この流れを作れれば、チームは不確かな依頼を長時間議論する代わりに、証拠に基づいて判断できます。
「Yes」のコストが下がったというより、「YesかNoかを決める前に、実物で確かめるコスト」が下がりました。生成AIの価値は、実装を肩代わりすることだけではありません。チームが早く、より良い判断をするための観測点を増やすことにもあります。
関連記事
- New research shows how AMIE, our medical AI, could help manage health conditions.
- A scorecard for the AI age
- Unlocking UK house-building with AI-accelerated planning
参考文献
コメント