コードを提案してもらえると、最初の一歩は軽くなる。
その一方で、動いたように見えるものをどう確かめるかが大切になる。
「書く」と「確かめる」を別の仕事として眺めよう。
まず、仕組みをつかむ
生成AIを測るための試験・評価は研究対象になっている。
[1] 現場での小さな確認でも、期待する動作を先に置き、出力をその基準に照らす順番が役立つ。
以下は編集部によるレビュー手順の例だ。
流れを理解するための概念図です。
実際の構成は用途によって異なります。
一つの場面で考えてみる
入力が空、長すぎる、同じ処理が繰り返される、といった境界を先に書く。
AIには小さな変更を頼み、差分を読む。
テストに通っても、不要な依存や権限が増えていないかは別に確認する。
ここは分けて考えたい
AIが作ったテストだけを合格基準にすると、同じ誤解を共有する場合がある。
仕様を知る人が入力例と期待値を用意し、実際に実行した結果を記録する。
未実行のコードを検証済みと呼ばない。
読み終えたら、確かめたいこと
- 失敗すべき入力は？
- 権限は増えていない？
- 独立した期待値がある？
