恐れずに反復する

すでにうまく動いているものを編集するのが、なぜ危険に感じるのでしょうか。ほとんどのツールでは、その場で編集する仕組みになっているからです――旧バージョンの上に上書き保存し、変更が何かを壊せば、戻れるバージョンがありません。元に戻す手段がないなら、その恐れはまったく合理的です。だからここには「その場」というものが存在しません。すべての編集は、すでにあったものの隣に新しいものを生み出します。

変更を依頼すると、実際には何が起きるのか?

ビルドチャットに、コピーの微調整でも、新しいセクションでも、機能全体でも、欲しいものを伝えると、プラットフォームは旧バージョンと並んで新しいバージョンを生成します。置き換えるのではありません。両方ともプレビュー可能でダウンロード可能なまま残り、旧バージョンはどこかに探しに行かなければならないアーカイブに格下げされることもありません。それはワンクリックで再びライブ版になれる、稼働可能なプロダクトです。変更を元に戻すコストがそこまで低くなれば、すべての編集を賭けのように扱うのをやめられます。

バージョンごとにフル検証を再実行すると、動作が遅くなりませんか?

それは検証が解決している問題とは正反対です。反復的なAI編集でよくある失敗パターンは、変更そのものではなく、その変更がどこか別の場所で静かに壊すものです。料金ページを修正したら、そこへのナビリンクがひそかに404になる、といった具合です。だからバージョン9も、バージョン1が受けたのとまったく同じ検証チェーンを受けます――コードレビュー、セキュリティ、リンクチェック、アクセシビリティ、適合性。変更が何かを壊せば、それを導入したそのラウンドで検知されます。3週間後にユーザーから壊れたボタンについてメールが届いてから、ではありません。（詳細はビルドはどう自己検証するかを参照。）

自分のサーバーにデプロイすると何が起きるのか?

自分のホストへのSFTPデプロイも、一段階下のレイヤーで同じ扱いを受けます。何かを書き込む前に、プラットフォームは現在のウェブルートをキャプチャします。それ以降にデプロイしたすべてのバージョンはホスト上に残り、復元可能なままです。ですから、プレビューでは完璧に見えたデプロイが、キャッシュヘッダーや奇妙なCDNルールなど、本番スタック側の何かによって公開後に問題を起こしても、古いエクスポートを再デプロイして正しいものをつかんでいたか祈るのではなく、ワンクリックで元に戻せます。

無料サブドメインの場合はどうなりますか?

考え方は同じで、より軽量です。そこへの公開は、公開済みのすべてのバージョンも保持し、以前のバージョンを再公開するのも新しいバージョンを公開するのと同じくらい簡単です。

これは結局、単なる高機能なバックアップシステムではないのですか?

いいえ――バックアップシステムは災害からあなたを守るものです。これは、あなたの日々の行動そのものを変えることを狙っています。間違った推測のコストがワンクリックにまで下がれば、「とりあえず試してみよう」はリスクの高い提案ではなくなり、ほとんどあらゆるアイデアに対するデフォルトの答えになります。