7月27日、Charity Majorsが「AI Demands More Engineering Discipline, Not Less」と題した記事を公開した。AIによるコード生成の台頭が「エンジニアリング規律の弛緩」を招くのではなく、「より高度な規律への移行」を要求するという論考だ。

「イミュータブルインフラ」との類比がすべてを説明する

この記事で最も重要な視点は、2013年のイミュータブルインフラ革命との対比だ。

著者のCharity Majorsは、Chad Fowlerの「Deletion Test」を引用する。FowlerはDevOps黎明期に「イミュータブルインフラ」という概念を提唱した人物だ。

Fowlerの主張は明快だ。「コードが貴重なものになってしまうのは、知識がコードにしか存在しない場合だ」——エンジニアが「コードを全部消したら怖い」と感じるのは、コードそのものが問題なのではなく、以下が明文化されていないからだという。

• 要求される振る舞いが正確にわかっていない
• 許容できない障害が定義されていない
• 不変条件（invariants）が明示されていない
• 新バージョンの正しさを検証する方法がない
• 忘れられたエッジケースへの対応がコードに埋没している

これらはコードの問題ではなく、評価（evaluation）の問題だ。

Fowlerはさらにこう論じる。「再生成が容易になれば、コードは資産であることをやめ、キャッシュとして振る舞い始める——理解の実体化されたビューであり、最新であれば有用だが、陳腐化すれば捨てるものだ」。Majorsはこの一文で「腑に落ちた」と書いている。

Majorsが自身の著書『Observability Engineering』第2版で書いた文章も、この文脈で重要だ。「ハンドクラフトのサーバーからイミュータブルインフラへの移行は、ミュータビリティが理解の敵であることを教えてくれた。インプレースで編集されるアーティファクトはドリフトを生み、ドリフトがシステムをメンテナンス不可能にする」——サーバーを「ペット」から「家畜（cattle）」に変えた発想が、今度はアプリケーションコードにまで及ぼうとしている。

Majorsの会社Honeycombでは、毎週火曜日のcronで最も古いKafkaノードを削除しているという。インフラを信頼できるのは、「殺して再生成できるから」だ。

AIが変えたのはコードの「経済学」だ

こうした前提を踏まえた上で、Majorsは2025年に起きたことを整理する。

2025年の大半において、「AIが生成するコードはゴミであり、永遠にそうかもしれない」という見方は過激な意見ではなく、業界のデフォルトだった。Majorsはその見方が変わった転換点として、あるモデルのリリースを挙げている（記事内では「Opus 4.5」と表記）。以降、AIは少なくとも一般的なパターンにおいて、中央値的なソフトウェアエンジニアと同等のコードを、はるかに速く安く生成できるようになったとMajorsは評価する。

Majorsの言葉を借りれば、「コードの生産経済学がひっくり返った」のだ。コードはかつて「大切に再利用・管理するもの」だったが、「使い捨て・再生成可能なもの」に変わった——正確には、コストが消えたのではなく、その構造が根本から変わった。

コードに背負わせすぎてきた

Majorsの主張の核心はここにある。コードは長い間、背負いすぎてきた。

• 開発者の意図
• ユーザーの期待
• 暗黙の・明示的な振る舞い
• 過去のバグ修正の化石

これらすべてがコードに埋め込まれてきた。その結果、痛みを伴うマイグレーション、ストラングラーフィグパターン、レガシーコードの置き換えに膨大な工数が費やされてきた。

では何が代わりになるべきか。Majorsが問うのは「アーキテクチャ図を議論して合意し、そこからコードを再生成できないか」という方向性だ。コードからアーキテクチャを推測するのではなく、アーキテクチャの変更からコードが生まれる世界。

ただし、「すべてのコードがAI生成になる」と断言しているわけではない。この構想の実現可能性は「仕様（spec）とは何か」という問いにかかっており、データベースマイグレーションで痛い目を見てきた人間なら、ユーザーの期待を自動化可能な形式で抽出することの難しさは骨身に染みているはずだ、とMajorsは釘を刺している。

懐疑論が正当だった理由、そして今は違う理由

Majorsは信頼性（reliability）の側から来たエンジニアとして、自分たちの傾向を正直に評価する。「進歩が本物であることを受け入れるのが苦手だ」と。バグやエッジケースが存在し続けることは、問題空間の大部分が時間をかけて「まあまあ解決された」という事実を否定しない。

一度目の懐疑は許容できる。二度目は難しい。これが指数的な変化の内側にいるとはこういうことだ、とMajorsは書く。

「規律を下げろ」ではなく「規律の置き場所を変えろ」

タイトル「AI Demands More Engineering Discipline, Not Less」が示す通り、この記事の結論はコードレビューを捨てろという話ではない。コードという「唯一の知識の置き場所」に依存する構造そのものを見直せ、という話だ。

AIによってコード生産のコスト構造が根本から変わった今、エンジニアリング規律が向かうべき先は「より良いコードを書くこと」ではなく、「評価・仕様・アーキテクチャ・観測可能性（observability）」に厚みを持たせることだ。かつてサーバー管理者がイミュータブルインフラという概念を受け入れた時と同じ転換が、今まさにアプリケーション開発で起きようとしている。

詳細はAI Demands More Engineering Discipline, Not Lessを参照していただきたい。