8月13日、The Pragmatic Engineerが「Stop being skeptical about AI for development with Charity Majors」と題した記事を公開した。HoneycombのCTO兼共同創業者であるCharity Majorsが、AIへの懐疑論から転換した経緯と、「自分が一度も読んでいないコードを本番リリースする時代」への備え方について語った内容だ。以下で取り上げる「コードレビューは過大評価」「DevOpsは失敗した」はいずれもMajors個人の見解として提示されている点を念頭に置いていただきたい。

「2025年までの懐疑論は正当だった」

Charity Majorsは2025年3月のSREconで聴衆にバイブコーディング（vibe coding：AIに自然言語で指示してコードを生成させる手法）を試すよう促した。当時の反応は不満のざわめきだったという。彼女自身もその時点では、AIは新しいプログラミング言語より大きな影響を持つ程度だと見ており、世代を変えるほどの変革には懐疑的だった。

転換点は2025年11月。記事内ではClaude Opus 4.5の登場、そしてClaude Codeというコーディングハーネスがきっかけとして言及されている。ハーネスがシェルスクリプト的なものから本格的なインフラへと進化したことで、AIによるコード生成の性質が変わったと彼女は語る。

振り返れば、2025年のAIインパクトは2010年のクラウドコンピューティングのそれに相当する。2010年時点でクラウドが主流になると確信できたように、2025年以降はAIがソフトウェア開発のインフラ層を変えることが明確になったという見立てだ。

AI懐疑論者への評価も公平だ。COBOLが「プログラマー不要論」を掲げ、ニューラルネット、ノーコード・ローコードが次々に「業界を変える」と言われながら実現しなかった歴史がある。その経験則に従えば、懐疑論は合理的だったとMajorsは認める。

コードは「ペット」から「家畜」へ

記事の中で最も刺さる問いかけがこれだ。

「自分が一度も読んでいないコードを、安心してリリースするために何が必要か？」

Majorsは、プロのエンジニアが「読んだことも理解したこともないコード」を本番環境にリリースする時代は「if」ではなく「when」の問題だと断言する。そして今まさに求められているのは、そのコードを検証し、自信を持ってリリースするための仕組みを構築するエンジニアリングだと言う。

この流れで彼女が持ち出すのが、インフラで起きた「ペット（pets）から家畜（cattle）への転換」のアナロジーだ（元々はDevOps・クラウド文化圏でRandy Biasらが2012年前後に広めた概念で、個別管理するサーバーを「ペット」、使い捨て前提のサーバーを「家畜」と対比したもの）。2010年代以前は個々のサーバーを手作業で設定・修理していたが、TerraformやKubernetesの登場後は問題が起きたサーバーは修理せず再作成する。同じことがコードにも起きる可能性がある、というのが彼女の見立てだ。問題のあるコードを直すのではなく、検証済みの新しいコードを生成する。

「コードレビューは過大評価されている」という逆張り

Majorsの持論として紹介されているのが、コードレビューはエンジニアリングへの人間の貢献の中で最も価値が低い部分だという主張だ。人間が得意なのは会話し、何を作るかを決めることであって、コードを読んで正しさ・構文・バグをチェックすることではないという。

また「DevOpsは失敗した」という評価も出てくる。開発者をコードの本番稼働状況につなげるフィードバックループを作ろうとした試みのうち、「Ops側がコードを学ぶ」流れは成功した。しかし「ソフトウェアエンジニアが本番のコードを理解する」流れは、今日に至るまで失敗したままだと断言する。

非決定論的なシステムは「より多くの規律」を要求する

AIが書いたコードは、自分で書いていないぶんコードへの信頼が下がる。その分を補うために、テスト・評価（evals）・適合性テストといった検証工程での信頼を高める必要があるとMajorsは主張する。

ここでいう「evals（評価）」とは、AIの出力が期待する仕様・挙動を満たしているかを自動的に検証する仕組みを指す。「適合性テスト（conformance testing）」はシステムが所定の標準や契約に準拠しているかを確認するテスト手法だ。AIが生成したコードを人間が一行ずつ読む代わりに、これらの検証レイヤーを整備することで「読んでいないコードを安心してリリースする」基盤を作るというのがMajorsの論点であり、タイトルが示す「備え方」の実質的な中心にある考え方だ。非決定論的なシステムの台頭は、エンジニアリング規律を減らすどころか増やすという逆説でもある。

CTOからエンジニアリングディレクターへの実践的な助言

キャリアへの言及も率直だ。

「次の転職面接では、AI経験がなければ足切りされる」

不安を感じているエンジニアリングディレクターには、IC（Individual Contributor：個人貢献者）に戻ることを真剣に検討するよう勧めている。ICに戻ることは今まで以上に尊重されており、転換しやすい環境にあるが、そのウィンドウは閉じつつあるという。

AI疲れへの対処としてHoneycombでは毎週水曜日をAI不使用の日にしているという実例も紹介されている。これは生産性最大化を追い求めるだけでなく、AIなしで問題を考え抜く力や判断基準を維持するための意図的な取り組みとして位置付けられている。AIに依存しきったエンジニアが「自分でコードを書けるか」「設計判断ができるか」を定期的に確認する機会としての意味合いだ。

また、AIに文章を書かせることについて一つのルールを設けている。「自分自身が全文読んでいないメッセージやメールは、人間に送ってはいけない」。相手が読むのにかかる時間は、あなたが生成するのにかかった時間より長い、それはおそらく「AI粗製乱造（slop）」だ、というわけだ。

「勝ちと負けのコストを両方語れ」

Majorsが最後に訴えるのは、AI賛成派・反対派の双方への注文だ。

「ソフトウェアの世界では今、本当にすごいことが起きている。コードの書き換えや作業の自動化など。話した人の誰もがAI使用をやめたいとは言わない。でも半分の人は成果だけ語って、コストと結びつけない。残りの半分はコストしか見えていない。全部の話をしてほしい。私たちは同じ船に乗っている」

技術の変革期に出がちな「賛否両論の断絶」を埋めることを、彼女は強く求めている。テスト・evalsの整備という地味な規律の話も、AI疲れへの対処法も、この「全部の話をする」姿勢から出てくるものだ。

詳細はStop being skeptical about AI for development with Charity Majorsを参照していただきたい。