このブログの過去ログを見てほしい。AIを使ったプログラミングについての記事がたくさんある。2024年1月にまで遡るものもいくつかある（たとえばこれ：https://antirez.com/news/140）。私はそれなりに評価されているプログラマだと自負している。 relevanceを求めて必死に“現役”にしがみつく老人でいる必要もない。最近Redisに復帰したし、ローカルでLLMを動かすための新しいオープンソースソフトウェアも開発していて、コミュニティにも好意的に迎えられている。なのに、なぜ人が聞きたくないことを言い続けるのか。なぜ、これからのプログラミングはデフォルトでこうなるのだと宣言し続けるのか。それは、自分より変化への備えができていない人たちへの衝撃を、少しでも和らげたいという衝動に駆られるからだ。彼らは多くの場合自分より若く、自分とは違って、こうした展開を予見できていなかった（2022年、ChatGPTが存在する前に、私はそこで起きたことの多くや、これから起きると信じていることを予告する本を出している。だからこれは自惚れではなく、言わせてもらいたい）。

だから私のは一種のトリックだ。多くの人が、プログラミングはAIですっかり変わってしまったと感じながら、どうすればいいのかわからずにいる。成果物であるコードをじっと眺めるのではなく、まったく違うやり方でコードを書き始めて本当にいいのか、と迷っている。まるで自分の専門を裏切っているかのように感じている。そこで私が現れて、こう言いたいのだ。「ほら、私を見てくれ。私はコードが書ける。わかっているだろう？AIの陰に隠れているわけじゃない。それでも、状況は変わった。これは君の弱さじゃない。君がAIに毒されたわけでもない。ただ、僕らの分野が、信じられないほど、そして苦しく――同時に楽しくもある方向へ進化しているだけなんだ」と。

だから昨日、Xで私はこう言った。今や多くのプログラマが、コードを見てしまうせいで、本来発揮できるはずの影響力を発揮できていない、と。本気でそう思っている。誤解しないでほしいが、これは最終成果物をただ頼んでバイブコーディングしろという意味ではない。言いたいのはこうだ。自分のソフトウェアのアイデアをきちんと制御できているなら、コードそのものを眺めるのは効率が悪く、多くの場合まったく無意味だ。理由は以下の通りだ。

1. いまは大量のコードを生成できる。LLM特有の冗長さを差し引いてもそうだ（あの冗長さも、大半はうまく指示できていないせいなのだが）。毎日5,000行のコードをレビューしろと？どうやってやるんだ。
2. LLMは局所的に最適なコードを書くのはとても得意だが、大きなアイデアの方は苦手だ（ただし改善はしてきている）。関数ごと、行ごとに舐めるように読むことに何の意味がある？むしろ、頭の中にある設計をプロンプトで伝え、時には「その部分の設計は具体的にどうなっている？どう動くんだ？」と尋ね、それが正しいモデルかどうかを評価すべきだ。こちらの方がずっと速い。
3. 労働時間は1日8時間だ。コードを読めば、その分トレードオフが発生する。今の仕事で最も重要なこと――「このソフトウェアで自分は何をしようとしているのか？」「次はどこへ向かうべきか？」と自問すること、新しいアイデアや機能、最適化のトリックを考えること、そして徹底的にQAをやること――に充てる時間が減ってしまう。

アイデアを制御する。この言い回しを『人月の神話』で覚えているだろうか。70年代の本が、2000年から2020年に語られた多くのことよりも、今のソフトウェアの時代について多くを教えてくれる。なぜ、今AIに抗議している人たちは、この10年間のソフトウェアの惨状にあれほど憤らなかったのか。AI以前のここ数年、僕らが触れてきたスラップ（粗製濫造）のレベルは信じがたいものだった。もう一つ言わせてほしい。スラップとは何か。私はDwarfStarで、2つのLLM（DeepSeek v4とGLM 5.2）の推論を、完全に自動化された方法で実装した。だが、自分で試せばわかる。「XYZを実装して」と言うだけで動くわけではない、と。仕組みを理解し、最適な設計が何かを考え、一定の性能に到達する方法を見つけなければならない。そのあと、正確性を確かめるために他のシステムと実装を比較してみると、むしろ他の実装の方が多くのエラーを含んでいることに気づいた。さらに調べてみると、ローカル推論の世界は、積み重なってモデル出力を蝕む微細なエラーに満ちていることがわかった。たとえば、あるコンテキスト長を超えると性能が坂を転がるように落ちていくのは、アテンションの実装に問題があるからで、インデックス付きアテンションの実装が壊れていて、必要以上に計算してしまっている、といった具合だ。これは、扱うのが非常に複雑で、変化が速く、推論グラフが少しずつ違うモデルが毎日のようにリリースされる分野だからこその結果だ。開発者にとってはあまりに不公平なゲームだ。そこでAIが大いに役立つ。手でGPUカーネルを書く（あるいは読む）よりも、設計面での厳密なエンジニアリングとテストの方がはるかに優れている領域がたくさんある。ならば、その抵抗の多くはイデオロギー的なものではないと、本当に言い切れるだろうか。

昨日、Matteo Collinaが私のツイートに返信してこう尋ねてきた。「でも、RedisではAIが生成したコードを全部チェックしているって言ってなかったか？」これは確かにいい質問だ。そう、チェックしている。だが、正直に言えば、今となってはやらざるを得ないからやっているだけで、ほとんど無意味だと思っている。部分的にはGPT 5.5が出た時点でそうだったが、FableやGPT 5.6 Solが出たいまはなおさらだ。たしかに、気に入らない書き方を見つけることはある。だが、他のRedisコントリビューターが書いたRedisのファイルを別に開いてみれば、そこにははるかにひどいものがある。彼らが優れたコーダーでないからではなく、単に好みの問題だからだ。私は読みやすさを重視するので、とてもクリーンなコードを書く。だからRedis Arraysの実装時には手を入れた。今また、Redisのソート済みセットでメモリを50%削減する最適化でも同じことをしている。近々PRを出す予定だ。だが、もうこれは有用だとは感じていない。誰も、もはやこのコードを眺めるべきではない。見るべきは、コードが含んでいるアイデアだけだ。私がそれでも続けているのは、ユーザーへの敬意からだ。Redisは今や広く使われるものになり、多くのプログラマがファイルを開いて手で修正するだろう。だが、もし私が自由にやれるなら、代わりに何をするかわかるだろうか。レビューに費やしている時間をすべて、QAを増やすこと、次の最適化のアイデアを考えて適用すること、そしてLLMを使って各データ構造を人間の言葉で説明したDESIGN.mdを書くことに使うだろう。そこには、そのデータ構造が含むアイデア、実装上のトリック、設計が書かれている。将来、それはずっと役に立つ。ソート済みセットを修正したいのか。ファイルを開き、設計を読めば、アイデアを自分のものにできる。正しいメンタルモデルを持ったまま、エージェントを開いて何をすべきか尋ねればいい。コードをレビューするより、ずっと有用だ。

FableやGPT 5.6によるソート済みセットのメモリ削減へのレビューは、私のレビューが見つけるよりはるかに多くのエラーや微妙な競合状態を見つけるだろう。それでも私はやる。だが、大半のソフトウェアプロジェクトでは、もはやそんなことは意味をなさない。代わりにアイデアの制御に集中すべきだ。品質とテスト、そして自分が出荷したいソフトウェアの明確なイメージに集中するんだ。世界は変わった。それは苦しいことだが、すでに完全に腐り切っていたソフトウェアの世界を改善する機会にも満ちている。

一つだけ引っかかっているのは、経験が足りず、まだメンタルモデルを築けていない若いプログラマのことだ。彼らがあるコードがどう動くのかを深く理解する必要があるのかどうか、まだわからない。だが、プログラムの書き方は学ぶべきだと思っている。とはいえ、LLMの出力をチェックすることが、彼らがすべきことだとは思えない。あるプログラミング言語を学んで、小さなインタプリタや小さなデータベース、ハッシュテーブルなどを実装する方が、ずっと有用かもしれない。顧客のウェブサイト用のちょっとしたJavaScriptをレビューすること？とんでもない、そんなクソみたいなことに時間を無駄にするな。