AIにコード修正を頼んだところ、最初の不具合は直ったのに、今度は別の機能が動かなくなる。さらに修正を重ね、気づけばどこから壊れたのか分からなくなった経験はないでしょうか。
私もAIと対話しながらWordPressプラグインを作っていたとき、修正を急ぐあまり、正常に動いていた状態を見失いました。あちらを直せばこちらが壊れる、まさに「もぐらたたき」のような状態です。
この記事では、AIとの開発において、修正を続けるべきか正常版へ戻るべきかを判断した基準と、戻ったあとに同じ失敗を繰り返さないために見直した進め方を紹介します。
AIへ修正を頼むほど不具合が増えた
最近は、AIと対話しながらWordPressプラグインを開発する機会が増えました。
実装したい機能を説明すると、AIがコード案を出してくれます。自分だけで調べるより早く進むことも多く、最初のうちは「これは本当に便利だな」と感心していました。
問題は、開発が順調に進んでいるときほど起こります。
変更のたびにGitへコミットしたり、正常に動くコードを別に保存したりするのが面倒になり、「あとでまとめて残せばいい」と先へ進めることも多くなります。
あるとき、プラグインの一部が想定どおりに動かず、AIへ修正を頼みました。最初の変更で、その不具合はいったん直りましたが、実際に確認すると、今度は別の画面表示が崩れています。
「え？なんで？」ということで、再びAIへ、
「先ほどの動作は残したまま、表示だけ直してください」
と頼みました。
次のコードでは表示が直ったものの、今度は保存処理がうまく動きません。さらに修正を依頼すると、別の部分でエラーが出ます。
最初は小さかった問題が、なんと修正するたびに広がっていきました。
AIとの会話も長くなり、どの指示で何を変えたのか、自分でも追いにくくなります。AIとの会話が長くなるにつれ、こちらが出した条件と実際の修正内容を、自分でも追いにくくなっていました。
画面を前にしながら、
「さっきより悪くなっていないか」
と気づいたときには、コード全体を触るのが怖くなっていました。
AIの修正が速いからといって、
変更内容を理解しないまま進めると、不具合の原因まで見失います。
この状態でさらに修正を重ねても、どこかが直るたびに別の問題が出るだけでした。
正常版へ戻ると決めた判断基準
修正を続けるか、いったん戻るか。
開発中は、ここで迷います。せっかく直した部分を捨てるのが惜しく感じますし、「あと一回修正すれば完成するかもしれない」と考えてしまうからです。
私も、しばらくはその期待を捨てられませんでした。
でも、次の状態になったところで、これ以上の修正は危険だと判断しました。
- 一つ直すたびに別の不具合が出る
- どの変更が原因か説明できない
- 現在のコードを自分で把握できていない
- AIとの会話が長くなり、条件が整理できない
- 正常に動いていた最後の状態がまだ残っている
特に大きかったのは、今のコードについて、
「なぜこの変更が必要なのか」
と聞かれても、自分で説明できなくなっていたことです。
AIが示した修正をつなぎ合わせただけで、処理全体の流れが見えません。これでは、一時的に動いても、次の修正でまた壊れる可能性があります。
そこで私は、現在の修正を諦め、正常に動いていたコードまで戻すことにしました。正直、直前までの作業を捨てるのは悔しいものです。
「折角ここまでやったのに．．．」
という気持ちはありました。でも、動かないコードを抱えたまま進むより、確実に動く地点からやり直したほうが早い。ようやくそう割り切りました。
正常版へ戻したあと、
画面がいつもどおり表示された瞬間は、かなりほっとしました。
迷路の中で出口が分からなくなったところへ、見覚えのある場所まで戻れたような感覚です。
正常版へ戻る判断は失敗の放棄ではなく、原因を追える状態へ立て直すための選択です。
修正を続けるべきか迷ったら、「あと少しで直りそうか」ではなく、「今の状態を自分で説明できるか」を確認したほうがよいと思います。説明できない状態なら、修正を続けるほど問題が複雑になるかもしれません。
戻ったあとに同じ失敗を繰り返さない進め方
正常版へ戻っただけでは、また同じ進め方をすれば同じ失敗を繰り返します。そこで私は、AIへ再び修正を頼む前に、作業の進め方を見直しました。
まず、変更する範囲を小さくしました。
以前は複数の問題をまとめて伝え、
「全部直してください」
と頼むことがありました。
これでは、AIがどの部分をどう変更したのか確認しにくくなります。修正後に問題が出ても、原因を絞れません。そこで、一度に扱う問題を一つにしました。
例えば、
「保存処理には触れず、画面表示だけを修正する」
というように、変更してよい範囲と触ってはいけない範囲を分けます。修正後は、目的の機能だけでなく、それまで正常だった機能も確認しました。
- 変更した部分は動くか
- 以前の機能は壊れていないか
- エラーや警告が増えていないか
- コードの変更理由を説明できるか
問題がなければ、その時点で正常版として残します。
以前の私は、完成するまでバックアップを取らなくてもよいと思っていました。でも実際には、途中の正常な状態を細かく残しておくほうが、試せることが増えます。失敗しても戻れるため、少し大胆な修正も試しやすくなるからです。
バックアップは、失敗したときだけ使う保険ではありません。
次の変更へ進んでもよいと判断するための確認地点です。
また、AIが出したコードをそのまま使わず、変更箇所を自分でも確認するようにしました。すべてを完璧に理解するのは難しくても、
- どのファイルを変えたのか
- 何の処理を追加したのか
- 既存処理を削除していないか
- 想定外の範囲まで書き換えていないか
くらいは確認できます。
内容が分からなければ、AIへ「変更した箇所と理由を説明してください」と聞きます。その説明を読んでも理解できない場合は、いったん採用しません。
AIはコードを速く書いてくれますが、どの状態を正常と判断するかは、使う側が決める必要があります。便利だからこそ、速度に引っ張られすぎないこと。今回の失敗で、そこを痛感しました。
まとめ
AI開発で不具合が増え続けたとき、修正を重ねることが最善とは限りません。
一つ直すたびに別の問題が出る、原因を説明できない、コード全体を把握できない。そんな状態になったら、正常に動いていた版へ戻る判断が必要です。
戻ったあとは、変更範囲を小さくし、動作確認をしてから正常版を残す。AIのコードも、変更箇所と理由を確認してから採用します。
正常版へ戻ることは後退ではありません。原因を追える状態を取り戻し、もう一度安全に進むための立て直しだと思います。
コメント