AIにコードを直させるとき、範囲を区切らないと別の場所が壊れる

• 「直して」とだけ言うと、周辺まで書き換えられることがある
• 触ってよい範囲を明示すると、巻き込みがほぼ消える
• 差分で受け取る形にすると、何が変わったか見える

表示がずれている箇所を直してもらったら、別のページで画像が出なくなった。原因を追うと、共通で使っている部分まで書き換えられていた。同じことを繰り返さないための手順を記録する。

なぜ周辺まで変わるのか

こちらが「この部分だけ」と思っていても、それは伝わっていない。渡したコードの範囲が触ってよい範囲だと解釈される。

さらに、問題の原因が別の場所にあると判断されれば、そちらを直そうとする。親切な動作だが、こちらが把握していない変更が入るのが困る。

気づきにくい理由

返ってきたコードは全体が整っていて、一見すると頼んだ部分だけ変わったように見える。長いコードだと、差分を目で追うのは難しい。

1. 触ってよい範囲を言葉で区切る

いまは必ずこれを添えている。

次の条件で直してください。
- 変更してよいのは、この関数の中だけ
- 関数名と引数は変えない
- 他のファイルは触らない
- 共通で使われている処理は変更しない

特に3つ目と4つ目が効いた。触ってはいけない場所を名指しするほうが、触ってよい場所を説明するより確実だった。

2. 差分の形で受け取る

全文を返されると、どこが変わったか分からない。

変更する行だけ、前後3行と一緒に示してください。
削除する行がある場合は、削除と明記してください。

この形にしてから、意図しない変更にすぐ気づけるようになった。削除を明記させるのが重要で、消える変更は追加より気づきにくい。

3. 先に原因だけ聞く

いきなり直させず、まず何が起きているかを聞く。

• 「この症状の原因として考えられるものを3つ挙げて」
• 「どのファイルのどの部分を見ればよいか」

原因が分かってから、その箇所だけを渡して直させる。範囲を絞ってから渡せば、そもそも周辺を触りようがない。

渡す量を減らす効果

ファイル全体ではなく該当部分だけを渡すと、返答も速くなり、的も外れにくくなった。長いコードを丸ごと渡すのは、楽に見えて遠回りだった。

4. 変更後に確認する範囲を決めておく

直した後、どこを見るかを先に決める。

• 直した画面
• 同じ部品を使っている別の画面
• スマホの幅での表示

2つ目を見落として今回の問題に気づくのが遅れた。共通部分を触ったなら、使っている全箇所を見る必要がある。どこで使われているかは、ファイル内の検索で調べられる。

巻き込みが起きたときの戻し方

起きてしまった場合は、順番が大事だった。

• まず手を止める。続けて直そうとすると状態が複雑になる
• 控えから戻す。直前の状態に戻せるようにしておく
• 戻した後、1つずつ入れ直して、どこで壊れるか特定する

3つ目は面倒に見えるが、原因が確実に分かる。推測で直すより速く終わった。

長く使うものと使い捨てで分ける

すべてにこの手順を踏むと重いので、分けている。

• 長く使うもの — 範囲の指定、差分での受け取り、控えの取得をすべて行う
• 使い捨て — 手元で動けばよいものは、まとめて書き換えてもらう

後者で手間をかけても得るものが少ない。壊れて困るかどうかで分けるのが、いまのところ一番しっくりきている。

伝えるようにした前提

範囲とは別に、最初に渡しておくと事故が減る情報がある。

• 言語やフレームワークの版
• 動いている環境（サーバー、ブラウザ）
• すでに試して駄目だったこと

3つ目を伝えないと、同じ提案が繰り返される。やり取りが増えるだけなので、最初に書くようにした。

まとめ

• 渡したコードの範囲が、触ってよい範囲だと解釈される
• 触ってはいけない場所を名指しするほうが確実
• 差分で受け取り、削除は明記させる
• 先に原因だけ聞き、絞ってから渡すと巻き込みが起きない
• 共通部分を触ったら、使っている全箇所を確認する