Gwen Davisは、AIエージェントの利用が拡大するにつれて、開発者の価値は、すべてのコード行を書くことから、ツールへの指示、出力のレビュー、技術的な意思決定へと、より大きく移行すると考えている。本稿では、エージェントの管理、最初の回答をそのまま受け入れないこと、節約した時間をより広範な問題の解決に投資することという3つの実践を提案する。
AIツールがコード作成の支援から、より大きな範囲のソフトウェア開発タスクの実行へと移行する中で、開発者の仕事は変化している。Gwen Davisによれば、コードを書くことだけではもはや十分ではない。問題の定義、適切なコンテキストの提供、出力の評価、そしてソリューションを採用する前に技術的なトレードオフを説明することの重要性が高まっている。
1. AIを単に使うのではなく、指示する
本稿は、AIに依存する環境での実行は、作業を明確に定義し、次にタスクを分担して結果をレビューすることから始まると説明している。認証フローを追加するタスクでは、あるエージェントが実装を準備し、別のエージェントがドキュメントを作成し、3番目のエージェントがテスト一式を用意するといったことが可能だ。
これは、最終的な結果に対する開発者の責任をなくすものではない。実務上の変化は、開発者が各部分を手作業で実装する時間を減らし、必要なものを定義し、エージェントの出力を調整し、レビューまたはリリースに適したものを判断することに、より多くの時間を費やす点にある。Davisは、AIエージェントへの指示方法を学ぶことが、独立した実務スキルになったと結論づけている。
2. レビューなしに最初の回答を信頼しない
ツールは数秒で説得力のあるソリューションを生成できるが、素早く読んだだけでは見えない欠陥を含む可能性がある。本稿では、顧客ごとに最新の注文を返すSQLクエリの例を用いている。そのソリューションは、同一のタイムスタンプへの対応を見落としたり、適切なインデックスを提案しなかったり、大規模なテーブルで性能が低下したりする可能性がある。
Davisは、2番目のモデルを使って1番目のモデルの作業を批評し、その後、両方の回答に対してエンジニアリング上の判断を適用することを提案している。モデルにはそれぞれ得意分野と盲点があると指摘し、GitHub Copilotに組み込まれたRubber Duckエージェントは、2番目のモデルを使って計画、コード、テストを批評すると述べている。しかし、人間によるレビューは依然として必要である。目的は人間の判断を置き換えることではなく、先に進む前に批判的な視点を追加することだ。
3. 節約した時間をより大きな問題の解決に使う
AIが実装のより大きな部分を担うようになると、開発者は得られた時間を、顧客のニーズの理解、アーキテクチャ上のトレードオフの評価、システム設計、そしてツールが開発者に代わって判断できない意思決定へと向けられる。
ダークモードの追加に関する例では、AIが変更を実装し、テストを生成し、ドキュメントを更新できる。一方、開発者のチェックリストには、顧客が直面している問題の検証、アーキテクチャ上のトレードオフのレビュー、アクセシビリティの確認、成功指標の決定、そしてソリューションの承認が含まれる。
実務上、何が変わるのか？
基本的なメッセージは、プログラミングスキルの価値が失われたということではなく、責任の範囲が広がっているということだ。開発者は引き続き結果の品質に責任を負うが、ツールに指示する能力と、その誤りを発見して実装をプロジェクトの真の目的に結びつける能力を組み合わせる必要がある。本稿は一般的な実践的指針を示しているが、これらの実践の影響を測定する指標や、エージェントに委任すべきタスクの範囲は定めていない。そのため、適用に関する判断は、プロジェクトの性質とリスクの水準に左右される。