AIが2時間でUIを構築した。その後、私は修正に3週間を費やした。
AIエージェントが2時間で私のUIを構築した。47個のファイルを変更し、コンポーネント、APIルート、バリデーションライブラリを作成した。
素晴らしいことだと思った。1週間分の作業を節約できたと思った。
6週間経った今でも、私はそのコードの修正を続けている。コンポーネントは動作するが、チームのメンバーはなぜそのコードが動くのかを説明できない。AIは私たちのパターンに従わず、新しいパターンを勝手に作り出したのだ。その結果、同じ作業を行うのに2つの異なる方法が存在することになり、ドキュメントは皆無となった。
これが「ゴースト・インプリメンテーション（Ghost Implementation）」問題だ。
骨組みはあるが、肉（中身）がないコードが出来上がる。コードはコンパイルでき、テストもパスする。しかし、なぜそのように書かれたのかを誰も知らない。AIには文脈が欠けており、開発者には理解が欠けているのだ。
私のコンサルティング業務では、主に3つの問題が見受けられる：
- 実装の健忘症（Implementation Amnesia）：開発者は、関数の要件を十分に検討する前に、まずAIに頼ってしまう。
- レビュアーの盲目（Reviewer Blindness）：エンジニアはAIの提案を読まずに「承認」をクリックしてしまう。
- デバッグの萎縮（Debugging Atrophy）：開発者は変数を特定する代わりに、バグ修正にAIを使ってしまう。これにより、15分で済むはずの修正が、3時間もかかる泥沼へと変わってしまう。
「AIがボイラープレート（定型コード）を扱い、人間がアーキテクチャを担当する」と言う人がいる。だが、それは間違いだ。ボイラープレートはシステムの結合組織である。それを書くことをスキップすると、アーキテクチャを形作るパターンを見失ってしまう。
私たちは「リリースまでの時間」は測定するが、「メンテナンスにかかる時間」は測定していない。
AIツールはスピードのために作られている。長期的な安定性のために作られているのではない。リリース速度だけを測定していると、膨大な技術的負債を生み出すことになる。
AIを使いながらも、スキルを鈍らせない方法：
- 2回説明する：ドキュメントを見ずに、なぜそのツールが機能するのかを説明できないなら、そこに知識の欠落がある。
- シンプルなプロジェクトを作る：AIを使わずに、小さなプロジェクトを一つコードで書いてみる。手動のスキルを維持するためだ。
- アーキテクチャ・ログをつける：大きな決定を下すたびに、3文程度のメモを残す。何を選び、何を却下し、なぜそうしたのかを記す。
- 依存度を記録する：自分の作業セッションを1から5で評価する。AIに頼りすぎているなら、あなたの強みは失われつつある。
単にAIの提案を承認するだけの人間になってはいけない。システムを理解している人間であれ。
直近のAIによるプルリクエストを見直してみてほしい。状態管理（state management）について声に出して説明しようとしてみてほしい。もしそれができないなら、それは「ゴースト・インプリメンテーション」だ。
AIはあなたのデバッグプロセスをどのように変えましたか？ コメント欄で教えてください。
Optional learning community: https://t.me/GyaanSetuAi