GitHubは、ブログ「The cost of saying yes has changed」において、AI時代におけるコード生成の負担、保守やレビュー、運用責任に関する意識改革の必要性を伝えた。コードを比較的短時間に生成できるようになったことで、ソフトウェア開発における従来の価値観を見直す必要があると論じている。GitHubは、AI時代にはコード生成ではなく、レビューや保守を重視した開発プロセスが重要になると説明している。
従来の開発体制とAIの影響
従来は小規模なパッチ開発でも慎重な判断が求められていた。ソフトウェア開発はコードの作成だけではなく、テスト、展開計画、エッジケースの確認、公開後の保守まで含まれるためだ。一見短時間で済む修正でも、システムの重要部分への影響が含まれると作業が長期化する例は少なくない。そのため、本当に必要な変更か、現在のリリース対象に含めるべきか、既存の仕様へ影響しないかを事前に議論する開発体制が定着した。この考え方について、GitHubは「最初のコードを書くことが最も高い負担」という前提に基づいていると指摘。しかし、AIによるコード生成が一般化した現在では、この前提は当てはまらなくなっているという。
具体例として、バックエンドが保持している最終アクセス時刻を設定画面に表示する小規模な修正が挙げられている。この程度の修正でも、予想されるリスクや過去の経験、納期などを巡って長時間議論し、それでも必要工数の見積もりができないケースがあるとしている。AI登場以前は試行錯誤するだけでもコストが高く、実装前の議論には合理性があった。しかし現在では、AIエージェントが短時間で試作パッチを生成できる。
AIによる試作パッチの活用
GitHubは、AIが生成した最初のパッチを成果物ではなく、「変更コストを見極めるための材料」と位置付けている。修正前後の差分を確認すれば、影響するファイルの範囲、予想外のモジュールへの波及、テストを容易に追加できるか、既存の設計を維持しているか、新たな製品開発の決断を求めていないかなどを具体的に確認できる。小規模案件の場合、試作パッチをそのまま採用できるケースは多い。一方で、認証処理まで変更が及ぶなら、小規模案件ではなかったことが短時間で判明する。この方法はAIに判断を委ねるのではなく、人間が判断するための材料を短時間で準備する手法と言える。
人間による検証と責任の重要性
AIによってコード生成が簡単になったとしても、保守コストまで軽減されるわけではない。GitHubは人間によるレビューが不十分で、公開後も責任を持って品質を維持できないのであれば、その変更は低コストとは言えないと強調している。判断基準は「AIがコードを書けるか」ではなく、「人間が内容を検証し、責任を持てるか」にあるという。十分にテストされたヘルパー機能の改善は比較的扱いやすい。一方、認証処理やデータ構造の変更は依然として慎重な評価が必要になる。また、製品仕様そのものを変える案件や、サポート負担、プライバシー、課金、法令順守へ影響する変更も、コード生成が容易になっただけでは負担は減らない。AIはコードの作成を支援するだけであり、その後の責任までは肩代わりしないと述べている。
AIで保守コストを見積もる方法
GitHubは変更範囲の管理方法も見直すべきと説明。従来は実装前に厳密な変更範囲を決めていたが、実装負担が低下した現在では、一部を速やかにレビュー段階へ移せる可能性がある。ただし、計画そのものを省略するのではなく、本当に価値のある計画へ集中する考え方が重要だとしている。具体策として、AIに試作を依頼するプロンプトにおいて、条件を明確に設定するように提案している。変更は可能な限り小さくまとめること、既存の機能フラグ内で動作させること、公開仕様を変更しないこと、必要なテストを追加または更新すること、変更したファイルを一覧化し、危険箇所を明示することなどを条件とする。これらを満たすパッチを生成できなければ、変更要求は想定以上に大きく、保守負担も高いことが早い段階で分かる。逆に条件を満たせるなら、その変更は受け入れ可能な範囲である可能性が高い。AIの活用方法を工夫することで、従来の「対象範囲かどうか」という議論を、「実際の負担はいくらか」という具体的な評価へ置き換え可能としている。
GitHubは、AI時代に求められる技術者は「コードを書く人」ではなく、不確実性や保守コストを素早く評価できる人材になると締めくくっている。
