コードを守ろうとする本能

開発者には既存コードを守ろうとする強い本能があります。リファクタし、最適化し、慎重に移行する。でも、その本能自体が間違っていたらどうでしょうか。

生物学でいう autotomy は、動物が自分の体の一部を切り離す能力のことです。たとえばトカゲが捕食者から逃げるために尻尾を捨てるように。尻尾には価値がありましたが、生き延びるためには手放す必要があった。しかも新しい尻尾はまた生えてきます。

なぜリファクタは高コストなのか

AI-coded な初期 MVP では、最初の auth flow はたいてい誰も予想しない速さで ship されます。問題が始まるのは数週間後、product が変わり、team が自分たちで本当に設計したわけではない code を慎重に refactor しようとするときです。そこで login が壊れ、user state がずれ、bug の数が増えていく。彼らは 置き換えるべき code を守ろうとしている のです。

AI 生成コードではこの問題がさらに大きくなります。AI はあなたが設計していない抽象を作り、あなたが承認していない結合を生みます。AI のコードをリファクタするとは、そもそも持っていない意図を逆算することです。

置き換えという別の選択肢

では、リファクタではなく単に置き換えるとしたらどうでしょう。

モジュール A（Auth v1）→ インターフェース契約 → モジュール A'（Auth v2）

新しい実装が同じ契約を満たし、同じテストに通るなら、それは有効な差し替えです。古いモジュールの内部を理解する必要はありません。慎重な移行計画も不要です。切って、差し替えるだけです。

安全な置き換えに必要なもの

この方法が成立するのは、次の前提がある場合だけです。

  1. 定義済みのインターフェース：各モジュールが契約を持つ（TypeScript 型、API Schema など）
  2. 境界の強制：モジュールがお互いの内部実装に触れられない
  3. 十分なテスト：テストが検証するのは実装ではなく契約
  4. きれいな依存グラフ：循環依存や暗黙結合がない

Autotomy ではどう実装するか

Autotomy の starter kit では、すべてのモジュールが「安全に切り離せる」前提で設計されています。

  • 認証モジュール？ 差し替える。インターフェースはそのまま。
  • 決済プロバイダ？ 交換する。hooks は変えない。
  • UI コンポーネントライブラリ？ 切り替える。レイアウト契約は残る。

重要な洞察はひとつです。守るためではなく、捨てられるように設計すること。各モジュールを安全に取り外せるなら、あなたに必要なのはリファクタではなく置き換えです。