何を変えないかも、作業範囲に含める
ボタンを押しやすくしたいときに、ゲームの状態管理まで作り直す必要があるとは限りません。依頼では対象の画面と問題の操作を示し、保存形式や公開先など維持したい条件も伝えます。変更した行が少ないこと自体より、目的に沿った変更かを確認します。
差分を見るときは、まずファイルの一覧を見ます。依頼と関係のない設定や依存パッケージが増えていたら、理由を確かめます。分からない変更を「AIが必要と言ったから」でまとめて受け入れないことが大切です。
読む順番を、利用者への影響から決める
すべての行を同じ細かさで読む前に、入力を受け付ける箇所、保存や外部通信、工程を切り替える箇所から確認します。小さな見た目の変更でも、クリック領域の上に透明な要素が重なると操作を妨げるため、CSSも影響範囲として見ます。
- ボタンの文言と実際の動作が一致するか。
- 新しい外部通信や有料サービスの呼び出しが増えていないか。
- 既存データを読み込める形式が保たれているか。
- 連打・途中中断・再挑戦で状態が二重にならないか。
試す操作を、差分に結び付ける
判定を広げたなら、対象の端を触る確認をします。保存を変えたなら、再読み込み後に値が戻るかを見ます。見た目を整えただけの変更に大規模な試験を毎回追加するのではなく、その変更で壊れ得る場所を狙って確かめます。
確認できた版は、変更内容と一緒に残します。次の修正で問題が出たとき、比較する相手があると原因を絞れます。AIとの会話だけに頼らず、実ファイルと差分、動作結果をつなげておくと、時間を置いても再開しやすくなります。