監督的エンジニアリング作業とは、Annie Vella と Kelly Blincoe が AI コーディングアシスタントがソフトウェアエンジニアリングに与える影響：縦断研究 で提案した作業カテゴリーであり、ソフトウェアエンジニアが AI コーディングアシスタントに指示を与え、その生成物を評価し、誤りを修正するために費やす労力を表す。著者らはこれを、従来のソフトウェア開発ライフサイクル（SDLC）の分類 — 設計、コーディング、テスト、レビュー — では捉えられない新しい独立したカテゴリーとして提示するとともに、従来のタスクで体感された時間の節約がどこに再配分されているのかを説明しうるものとして位置づけている。
用法
この構成概念は、同研究において定量的パターンと定性的パターンが収束したことから浮かび上がった。エンジニアはほとんどの開発タスクに費やす時間が減ったと報告し、なかでもコードを書く作業が最も大きく減少していたが、テストやコードレビューといった検証タスクの増加はわずかにとどまり、その労力がどこへ向かっているのかという疑問が生じた。自由記述の回答で参加者は、コードを生産する立場から AI が生成した出力を監督する立場への移行 — アシスタントに指示を与え、その提案を評価し、何を受け入れ、修正し、破棄するかを決めること — を述べており、これは既存のタスクカテゴリーにうまく対応しない作業である。著者らは、エンジニアがこうした AI 出力の検証を、従来の意味での「テスト」や「コードレビュー」とは認識していない可能性があると示唆している。
著者らはこれを 3 つの構成要素に分けている。
- 指示（Directing） — 意図を明確にし、プロンプトを作成し、コンテキストを与え、出力が的外れな場合には反復すること。
- 評価（Evaluating） — AI の出力を読み、何を受け入れ、修正し、却下するかを決めること。
- 修正（Correcting） — 誤りを直し、出力を既存のコードに統合し、一貫性を保つこと。
著者らの説明によれば、エンジニアがどれだけ監督を行うかは信頼の較正に左右される。AI の出力をどれだけ容易に受け入れるかはエンジニアによって異なり、AI の使用を低リスクな文脈に限定する者もいる。著者らはまた、この構成概念を自らの 生産性と体験のパラドックス とも結びつけている。プロンプトを与え、レビューし、受け入れるか却下し、反復するというサイクルは、持続的な集中を、指示し、待ち、評価するというリズムに置き換えるものであり、フロー状態が損なわれた理由を説明する一助になりうると著者らは示唆している。
この概念は提案の段階にある。根拠となっているのは 1 件の縦断的サーベイ研究であり、著者らは今後の課題として、監督的エンジニアリング作業が既存の活動と実証的に区別できるかどうか、どのようなスキルを必要とするか、エンジニアがそれに満足を感じるかどうかの検証を挙げている。それが実在し独立したものだと判明した場合には、SDLC モデルの更新が必要になるかもしれないと著者らは示唆している。