数日前、私は「AI熱狂者は時間との競争、AI懐疑論者はエントロピーとの競争」という記事を書いた。

AI関連のトピックで深掘りしたいものが山ほどある：AIの義務付け、コミュニケーションの規範、コードレビュー、AIアートなどだ。残念ながら前回の記事に対する興味深い反応が多すぎて、他のトピックに移る前にそれらに対応しなければならない。😉

興味深い反応には2つのタイプがあった：1つは技術的なメリットに関するもの、もう1つは倫理的な根拠に関するものだ。これらにはそれぞれ別々に返事をする。まずは技術的な側面から取り上げよう。なぜならこちらの方が簡単だからだ。（追記：倫理的な返事はこちら）

どういうわけか、一部の読者は私が「コードレビューを捨てて、最低のコードを今すぐ本番にプッシュせよ」とみんなに言っていると受け取ってしまったようだ。right now, tout suite.1

そんなことはしていないし、そんなことをすべきだとも思っていない。しかし、この例を無作為に選んだわけではない。その理由を説明しよう。

忘れがちだが、2025年の大半において、AI生成コードはslopであり、ずっとslopのままかもしれないという考えは、合理的な立場であるだけでなく、デフォルトの主流の見解だった。2

その疑問は昨年11月に決定的に答えが出た。Opus 4.5が登場して以来、AIは少なくとも一般的なパターンについては、平均的なソフトウェアエンジニアとほぼ同等のコードを生成できるようになり、しかもはるかに高速かつ安価に生成できるようになった。私は本の穴から這い出して1月にこれを認識し、2026年の最初の数ヶ月で、周囲の誰もが似たような気づきを得ているように思えた。

しかし、もっと早くからそれを見ていた人も多い。

一般的な語りでは、Opus 4.5が変化をもたらしたとされている。しかしOpus 4.5はむしろターニングポイントに過ぎなかった。エージェント型ハーネス（LLMをツールとともにループで包むコード）は2025年半ばに本物となり、その前身は2024年末まで遡る。ツール使用、関数呼び出し、MCP……これらすべてが2025年を通じて積み上がり、年末に真の汎用的な使い勝手に到達した。

それが昨年、熱狂者たちが私たちに伝えようとしていたことだ。「これは来る」というだけでなく、「思っているよりも早く来る」ということだった。

結果として、彼らは正しかった。

ご存知のように、私は信頼性側の人間だ。私と私の仲間に対して与えられる褒め言葉は、新しい現実への適応に苦労しないということだ。問題が現実のものとして目の前に現れた瞬間、私たちはスムーズに、むしろ熱心に適応する。不健全なほどに嫌な技術的混乱を貪るような情熱（そして後で語る焚き火話）のおかげだ。

私と私の仲間に対して与えられる非難は、進歩が本物であることを受け入れるのに苦労することがあるということだ。バグやエッジケースがまだ存在し続けるからといって、問題領域の大部分が時間の経過とともにほぼ解決され、ほとんどの人が当然のこととして扱えるようになるという事実を損なうわけではない。3

コードが「全然ダメ」から「ああ、悪くないな」に変わるスピードが、熱狂者たちが「ハーネスエンジニアリングとAI検証は本物で、すでに存在し、驚くべき速さで良くなっている」と私たちに語るとき、私の頭の片隅にあるものだ。

「見てから信じる」という姿勢は、最初は許容できたが、2回目ははるかに許容しがたい。これは指数関数的な変化曲線の内側にいるということだ。4

ここで一旦立ち止まって、何が起きているのかについて、私の考えを明確に述べたい。その後、何に興奮しているのか、そしてなぜ興奮しているのかを具体的に話す。

私に同調する義務は一切ない。しかし今、「それは決してXではなかった」「それは常にYだった」「未来はxyzzyのものだ」🤮といった大げさな発言があまりにも多すぎる。私は自分の主張がどれほど条件付きで、具体的で、文脈依存であるかを明確にしておきたい。

2025年に起きたことはこれだ：コード生産の経済性が逆転した。コードを生成することが非常に難しく、時間がかかり、高価だったのが、事実上無料で即座にできるようになった。コード行は、宝物のように扱われ、再利用され、大切にされ、慎重にキュレーションされるものから、一夜にして使い捨て可能で再生成可能なものになった。

コンピューティングの歴史のほとんどにおいて、人々がソフトウェアを理解するための主要な方法はコードを書くことだった。ある程度の熟練を達成すれば、コードを読んで議論することが大部分を占めるようになる。（ソフトウェアエンジニアは、観測可能性を通じてシステムを理解するのではなく、コードにあまりにも依存しすぎてきたと私は主張するかもしれない。）

優れたソフトウェアエンジニアの多くは、（優れた）ソフトウェアエンジニアリングチームの真の成果物は、私たちが所有するソフトウェアについての共有理解であると常に主張してきた。それは私たちの脆弱な肉の脳にキャッシュ状態として保存され、ディスクに頻繁にフラッシュされ、本番にデプロイされ、githubにコミットされるが、意味は常に私たちの心の中に存在してきた。

ソフトウェアが常に集団主義的な取り組みであり、人間関係のダイナミクス、マナー、公平性の問題、感情的な価値観に極めて敏感であることは不思議だろうか？ それは、脳の一部が他人の脳の中にあり、集団的な相互依存が極めて高いときに当然期待されることだ。

私はこの業界のこの点が好きだ。しかし、ソフトウェア開発モデルの特定の側面を心に留めておくことが貧弱なコンテナであることは否定できない。私たちは忘れっぽく、気が散りやすく、せっかちだ。細かい詳細に気づくのが苦手で、繰り返しに慣れてしまう。最も悪いことに、私たちの頭の中のモデルは、ユーザーが対話する世界と常に大きく乖離し続けている。

いずれにせよ、SREは決してその説明を買いかぶったことはない。私たちには、（優れた）ソフトウェアエンジニアリングチームの真の成果物は本番であることは明らかだ。

本番は本番だ。本番でテストするか、嘘をついて生きるかだ。

（これはすべて前置きだ。ポイントにたどり着くので、約束する。）

私たちは昨年8月にAIの義務付けを発行した。5私はこれが起きていることを十分に認識しており、責任あることをする時だとわかっていた。Honeycombはdevtools企業であり、人々は技術の最先端の難しい問題を解決するために私たちのところに来る。私はAIに全面的に賛成だったが、心の底ではそれほど興奮していなかったと言わざるを得ない。6

その後、Chad FowlerのPhoenix Architecturesについての文章を見つけた。

何を言っているかわからないなら、正直に言って私の文章を読むのを今すぐやめて、彼のものを読みに行くべきだ。Chadは2013年に「immutable infrastructure」という用語を作った人物だ。彼の最も有名なエッセイは「Relocating Rigor」で、Martin Fowler7がThoughtworksのミートアップの要約で言及した、ソフトウェアの未来についてのもので、私が「Production Is Where the Rigor Goes」と返信し、彼らが本番について十分に語っていないと不満を述べたものだ。

私がそれを書いたとき、「Relocating Rigor」は私が読んだ唯一の記事だったと思う。しかしすぐに残りの部分を見つけ、2〜3のエッセイを読んだ後、まさに 腑に落ちた。彼が何を言っているのか正確にわかり、彼が次に何を言うのか予測できた。そして読者よ、その時私は興奮した。

Chadの引用を少しだけ紹介して、要点を掴んでもらおう。「The Death and Rebirth of Programming」からの引用だ。

Immutable infrastructure. Stateless services. Containers. Blue-green deployments. Infrastructure as code.

These ideas all share a common premise: never fix a running thing. Replace it.

AI pushes this premise beyond infrastructure and into application code itself. When rewriting is cheap, editing in place becomes risky. Mutation accumulates entropy. Replacement resets it.

もう一つの好きな引用：「The Deletion Test」。

Here’s a simple test you can apply to any software system you work on:

Imagine deleting the entire implementation.

Most engineers experience deletion as existential. Code feels like the thing. It’s what we write, review, version, deploy, and debug. Losing it feels like losing the system itself.

When people say, “We can’t just throw the code away,” what they usually mean is something more precise:

  • We don’t know exactly what behavior is required.

  • We don’t know which failures are unacceptable.

  • We don’t know what invariants must always hold.

  • We don’t know how to tell if a new version is correct.

  • We don’t know which bugs are intentional fixes for forgotten edge cases.

Those are not code problems. They are evaluation problems.

Code becomes precious when it is the only place knowledge lives.

and,

For most of software history, treating code as durable was reasonable.

We treated code as permanent because the labor to produce it was the bottleneck. Rewriting was expensive. Re-validation was risky. Implementations accumulated meaning over time. Structure, tests, comments, bug fixes, and tribal knowledge fused into something you learned not to disturb.

That made sense when production was the constraint.

When regeneration is easy, code stops being an asset and starts acting as a cache: a materialized view of understanding that is useful while current, disposable when stale.

「A materialized view of understanding that is useful while current, disposable when stale。」この一文がまさに私の頭の中で腑に落ちたのかもしれない。

私はちょうど、最初の役職が「システム管理者」だったと言える年齢だ。大学で働き、全てのマシンにroot権限を持っていた、大学が絶対にそうすべきではないと学ぶ前の時代だった。8

私は手作りのサーバー・ペットから不変インフラの家畜への移行を経験した。当時は何が起きているのか本当に理解していなかったが、近年になって深く考え直した。私は『Observability Engineering』第2版（現在入手可能、こちらからダウンロード！）の最終章でこう書いた：

The shift from handcrafted servers to immutable infrastructure taught us that mutability is the sworn enemy of understanding. Any artifact that is edited in place creates drift. Drift is what makes systems impossible to maintain.

Our ability to kill and regenerate infrastructure components is the reason we trust it. At Honeycomb, we kill the oldest Kafka node off via cron every Tuesday. That’s why we are confident in our bootstrapping and balancing processes: everything is repeatable, the data can be regenerated, the commitments live elsewhere.

The fact that we cannot regenerate our code in the same way is a sign that we do not understand it. We do not know which commitments we have made, we do not know which dependencies will break. We find them by breaking them, mostly.

あなたの職業生活で、痛みを伴う移行や書き換えに費やした年月を考えてみてほしい。負荷のかかるレガシーコードを置き換えることを考えてみてほしい。すべてのstrangler figを考えてみてほしい。

コード行はやりすぎだった。コードは開発者の意図、ユーザーの期待、暗黙的および明示的な振る舞いの束ねられたリポジトリであり、過ぎ去ったバグの唯一の化石化した複合記録だった。それは多すぎる！

そして、コード行の維持と変更という途方もない、すべてを消費する費用のために無視されてきたすべてのドメインを見てみよう。私たちのアーキテクチャがどのように進化しているかを理解するためにレビューし議論できる成果物はどこにあるのか？ そもそも私たちのアーキテクチャの成果物はどこにあるのか？ アーキテクチャ図について議論し収束させ、コードがアーキテクチャの変更から再生成されるようにしたらどうだろうか？ コードからアーキテクチャが何となく推測されるのではなく。

私は、すべてのコードが最終的に人間の理解をバイパスして仕様からAI生成されるようになると主張しているわけではない。この取り組み全体の実現可能性は、仕様とは何か、仕様は何になり得るかという問いにかかっている。痛みを伴うデータベース移行を経験した人なら、ユーザーの期待を再現可能で自動化可能な方法で抽出・形式化する能力について、謙虚さを学んだはずだ。

しかし、その方向への一歩一歩が私たちにとって良いことだと私は思う。

これを行うためのツールはまだ存在しないが、多くのアイデアは存在する。そのほとんどは、ソフトウェアエンジニアリングが歴史的にやや見下してきた2つのドメイン、運用とQAから来ている。

これらのテストとテクニックは、正しさやあるべきことのテストではなく、実際に起きていることを観察しエンコードすることに関するものだ。行動テスト、特性化テスト、キャプチャ/リプレイ、トラフィックスプリッター。観測可能性（良い意味で）。

本番に非決定的なコードを持つことは、ついに私たちがずっと前からやるべきだったことを強いることになる。トレースによる計装。本番でのテストと評価。本番は開発が終わった後に起こることではなく、本番は開発の段階である。

人間の脳は検証が得意ではない。細かさ、繰り返し。これを執着し続けるのは最悪のことだ、みんな。ソフトウェアの生成と保守において、私たちが保存し主張したいと思うべき、より良いことがたくさんある。私たちは検証に関しては決して機械に勝てない — 文字通り最も弱いリンクなのだ！

私の賭けは、創造性、インスピレーション、論理の飛躍、その他多くのことに関しては、まだ長い間人間にある。しかし、ソフトウェアにおける人間の殺し文句を、私たちが最高の品質ゲートであることに置かないでほしい。お願いだから。OMG。🙈

よし。もうすぐ終わりだ。あと一つだけ。

多くのエンジニアが過去2年間のAIの言説について疎外感と恐怖を感じたのは、多くの著名なAIの声が、ソフトウェアはもはやエンジニアリングの問題ではないと嬉々として宣言しているように見えたことだと思う。「SaaS is dead！」「Making AI great at coding was the strategy that unlocks everything else」、などなど。私の一番の友人であり、技術についてめったに間違えないAdam Jacobでさえ、ソフトウェアの仕事の大量虐殺を予期しているようだ。9

2025年がvibe codingの年で、AIが平均的なソフトウェアエンジニアと同等にコード行を生成できるようになり、可能な未来の範囲が不安定で、ありえないほど広く開かれているように感じられることが多かったとすれば、2026年は規律への回帰になるように感じる。

私たちの頭の中の知識は、それをシステムにエンコードするまでAIには利用できない。結局のところ。それらの投資のリターンは巨大で非線形になるだろう。私たちはそれらが常に長期的に元が取れると主張するかもしれない。しかし今、存在するすべてのCEOがAIクッキーの一部を手に入れようと躍起になっているので、それを与えてあげよう。規律が先、クッキーが後だ。

短く高速なフィードバックループで作業するソフトウェアエンジニアリングチームの割合（私の本では規律の基本的な兆候）は、常に愕然とするほど少ない。5%程度？ 確実に10%未満だ。AIツールはこれをこれまで以上に手の届くところにもたらす。あるいは、可能にする。なり得る。エンジニアリング規律への投資の不連続なリターンは十分に現実的で、それが起きるかもしれない。

私は、少なくとも短期的には、エンジニアリング規律の欠如した状態でAIが巨大で不連続な投資リターンを生み出すことについて心配していない。（多くの人が試み、それは見ていて面白いだろう。）

しかし、価値は使い捨てではなく耐久性によって裏付けられており、それが変わるとは思わない。ビットは安価で高速で、論理と言語の規則に支配されているが、価値のあるものは最終的に物理システムに解決されなければならない：一方では永続性、もう一方ではユーザー体験。

人々は毎朝起きてSlackにログインし、ボタンとメニューが微妙に移動しているのを見つけたくない。人々はほとんどの場合に完了する金融取引を望まない。決定論はどこにも行かない、友よ。

AIは魔法ではない。これは依然としてエンジニアリングだ。アダムが言うように、「それは依然として技術であり、技術は技術者を必要とする」。そして私は、新しい興味深いエンジニアリングの問題を学び、異なる種類の成果物をレビューすることを楽しみにしている。

そして、二度とべたべたで細かくて2年かかるAPIの書き換えやstrangler fig移行を、決して、決してやりたくない。

~charity

P.S. ドラフトを読んでフィードバックをくれた皆さんに感謝：Dave Williams, Chad Fowler, Adam Jacob, Mark Ferlatte, Austin Parker, Erwin van der Koogh, Ankur Bhatt.

Discussion about this post

Ready for more?