AIコーディングツールがリリースされる時、PPTに必ず書かれる数字は1つだけ：「生産性10倍」。
誰も書かない2つ目の数字：メンテナンスコストはどれだけ増えるか。
今週Hacker Newsで1つの投稿がバズった——「手書きコードに戻りたい」。著者は時代遅れの人間ではなく、様々なAIコーディングツールを使った後にこの決断を下した開発者だ。121ポイント、51件のコメント。コメント欄は2派に分かれた：「终于有人讲真话了」と言う一派と、「ツールを間違えて使っている」と言う一派。
どちらも理がある。
AIはコードを速く書くが、他人のコードのメンテナンス——AIのであっても——速くなったことはない
これは2026年の問題ではない。ソフトウェアエンジニアリングの世界は昔から知っている事実がある：コードを読む時間はコードを書く時間を遥かに超える。AIはこの不等式を増幅した。
Claude CodeやCodexが30秒で500行のコードを生成できる時、あなたは書く時間を節約した。しかし3ヶ月後、そのコードにバグが出て、なぜそう書かれたのか、どのような暗黙の仮定に依存しているのか、ある変数を変更すると他の部分に影響しないか——これらの時間は1秒も節約されていない。
見落とされた2つのコスト
1つ目はレビューコスト。 AI生成コードは正しく見える——構文は正しい、ロジックは通っている、テストはパスする。しかし不要な抽象化、過剰設計されたパターン、特定の境界条件下でのみトリガーされるバグを導入しているかもしれない。500行のAIコードをレビューする時間は、自分で200行書くより長いかもしれない。
2つ目は知識希薄化コスト。 コアビジネスロジックをAIに書かせ、自分で行読んでいない場合——チームの誰もそのコードを本当に「理解」していない。問題が発生した時、直感で特定できる人はいなく、ゼロから読むしかない。
しかしAIツールを捨てるのは早い
HNコメント欄の高評価返信が上手く言っている：「問題なのはAIがコードを書くことではなく、『AIの出力を無条件に受け入れる』ことだ。」
AIコーディングエージェントは以下のシナリオで確かに10倍の生産性向上をもたらす：
- ボイラープレート：CRUDインターフェース、データモデル定義、設定ファイル
- 既知パターンのリファクタリング：callbackをasync/awaitに、class componentをhooksに
- テスト生成：既存コードに基づいて単体テストの骨組みを生成
- ドキュメントとコメント：複雑な関数にドキュメントを補足
ただし以下のシナリオでは警戒が必要：
- コアビジネスロジック：ここでの判断にはすべてビジネスの意味がある、AIはあなたのビジネスを理解しない
- パフォーマンスクリティカルパス：AIは「正しい」コードを書く傾向があるが、「速い」コードとは限らない
- セキュリティセンシティブコード：AIは境界条件チェックを遗漏したり、不要な依存を導入したりする可能性がある
実用的なワークフロー
プロジェクトでの私のやり方：AIが生成、私がレビュー。AIが提案、私が決定。
エージェントに初稿を書かせるが、メインブランチにマージする前にすべて目を通す。行ごとにレビューするのではなく、質問を持ちながら：このコードは何の問題を解決しているか？もっと簡単な書き方はないか？6ヶ月後に引き継ぐ同僚がこれを見て呪うことはないか？
答えが「わからない」なら、自分で書き直す。
AIプログラミングの次の段階
HNコメント欄である人が良いポイントを指摘した：本当の問題は「AIがコードを書くべきか」ではなく、「AI生成コードを管理するエンジニアリング規律をまだ構築していない」ことだ。
コードレビュープロセスはAI時代に適応する必要がある。将来のPRテンプレートにはフィールドを追加する必要があるかもしれない：「このコードの何割がAI生成か？どの部分をレビューしたか？」
CIパイプラインにAIコード品質検出を追加する必要があるかもしれない——「AIが書いたか」を検出するのではなく、「このAIコードのメンテナンス性はどうか」を検出する。
このインフラはまだ成熟していない。しかし迟早に来る。
主な情報源：