変更する前にbeforeを残すようにした

AIに変更を頼んだあとで、どこが変わったのか説明できなくなることがある。

でも、ほかの文章や設定まで触れていないかは、変更後だけを見ても分からない。

俺も最初は、直った画面だけを見て終わりにしていた。

表示が直っていれば、それでよいと思っていた。

けれど公開記事や目次を触るようになると、直した場所だけを見て安心するのは危うい。

そこで、変更する前の状態をbeforeとして残すようにした。

変更後はafterとして残す。

二つを比べたdiffで、予定した場所だけが変わったかを見る。

AIを慎重にさせるためではない。

人間が変更を確かめられる状態を作るためである。

変更したあとに、何を直したか分からなくなった

AIへ「ここを直して」と頼むと、目的の場所は直る。

ただ、その結果だけを見ても、どこまで触ったかは分からない。

見出しの文言を直したつもりで、周辺のリンクまで変わっているかもしれない。

画面が一見正しく見えても、変更前の状態を覚えていなければ比較できない。

変更前と並べて初めて、何が動いたかを確認できる。

だからbeforeは、失敗したときだけ使う記録ではない。

変更の範囲を知るために、先に残す記録である。

beforeがあると、戻す内容が分かる

beforeは、変更対象を元へ戻すための材料になる。

本文なら変更前のraw HTML。

目次なら更新前のページ本文。

seriesなら公開前の一覧ファイル。

本文のbeforeで確認できるのは、本文だけである。

SEO設定、アイキャッチ、カテゴリ、公開状態まで変えるなら、それぞれの変更前も確認しておく。

beforeがあればすべての変更が安全になるわけではない。

それでも、変更前の状態がなければ、戻す判断をしても戻す内容が分からない。

先にbeforeを残すと、変更を始める前に戻る先が決まる。

afterだけでは、意図しない差分に気づけない

afterだけを開くと、今の状態は分かる。

だが、その文章やHTMLが最初からそこにあったのか、今回の変更で加わったのかは分からない。

beforeとafterがそろうと、変化の範囲を比べられる。

前の記事「終わったファイルは消さずにarchiveへ移す」の公開後施工では、目次page 33のbeforeとafterを残した。

afterにはその記事へのリンクが1件増えた。

そのほかの一覧や見出しを変えないことも、beforeとの比較で確認した。

beforeとafterを残すのは、過去をためるためではない。

今回の変更が、前の状態からどう動いたかを確かめるためである。

diffで見たかったのは、予定した1か所だけ

そこでdiffを見る。

diffは、二つの状態の違う場所だけを取り出す記録である。

大切なのは、差分が少ないこと自体ではない。

予定した場所だけが差分になっていることだ。

その公開後施工では、前の記事「正本を1つ決めたら、探す時間が減った」の直後に、その記事へのリンクが1件加わった。

seriesのdiffでも、S4-3だけが公開済みになり、S4-4からS4-7は保留のまま残った。

変更を小さく分ける前に必要なのは、1回の変更が予定どおりだったと確認できる材料である。

diffは、AIの作業を褒めるための記録ではない。

人間が変更範囲を確認するための記録である。

表1件の修正で、変更範囲を確かめた

正本を1つ決める記事では、「知りたいこと」と「見る場所」を対応させる表を使った。

公開後、その表はMarkdownのパイプ記法が段落として出てしまい、表示が崩れた。

このとき、変更前の投稿rawをbeforeに残した。

修正後のafterには、崩れた段落1件の代わりにGutenbergの表ブロック1件だけが入った。

diffでは、表の見出しと4行の内容、前後の見出しに意図しない変更がないことを確認できた。

だから、公開済みの記事全体を直したのではなく、表の表示だけを直したと説明できた。

変更前を残さなければ、今の表が正しいことは見えても、ほかを変えなかったことまでは分からない。

AIに公開記事を触らせるとき、必要なのは大きな保証ではない。

何を変え、何を変えなかったかを確認できる記録である。

AIを信用する前に、変更を確かめられる状態を作る

AIに任せるかどうかは、能力だけで決めない。

変更したあとに、自分で確かめられるかも大切である。

beforeを残す。

afterを残す。

diffで予定した場所だけを見る。

問題があれば、beforeを戻す場所として使う。

変更と確認を分ける理由は、公開は人が決める。下書き保存と公開後施工を分けるにも残した。

AIが変更を行っても、採用するか、戻すかは人間が決める。

before・after・diffは、その判断を感覚だけにしないために残す。

次の変更では、変更対象だけをbeforeとして残す。

目次なら、`before_page33.html`、`after_page33.html`、`diff_page33.patch`のように同じ対象の記録をそろえる。

そのうえで、予定した差分だけかを確認する。

余計な差分があれば採用せず、beforeを基準に戻す内容を見直す。

俺が先に保存したかったのは、昔のファイルではなかった。

変更のあとで、何を信じて確認すればよいか迷わないための記録だった。