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

だから僕のやり方はある種のトリックなのだ。多くの人が、プログラミングはAIによって完全に変えられつつあると感じながら、何をすべきか分からずにいる。本当にまったく違うやり方で、主要な成果物であるコードをそれほど見ずにコーディングを始めてしまっていいのか。まるで自分の専門分野を裏切っているように感じている。だから僕がやりたいのは、前に出てこう言うことだ。「ほら、僕はコードが書けるんだ。知っているだろう、AIの陰に隠れているわけじゃない。でも、状況は変わった。これは君の弱さじゃない。君がAIに毒されたわけでもない。ただ、僕らの分野が信じられないほど、そして苦痛を伴う（しかし同時に喜びも伴う）方向へ進化しているだけなんだ」と。

だから昨日Xで、多くのプログラマがこの時点で本来発揮できるはずの影響力を、コードを見ることに囚われるあまり発揮できていないと思う、と投稿した。本気でそう信じている。誤解しないでほしいが、これは最終成果物をただ頼んでバイブコーディングしろという意味ではない。要点はこうだ。もしソフトウェアのアイデアをコントロールできているなら、コード自体を眺めることは最適とは言えず、しばしば無意味ですらある。その理由は次の通りだ。

1. 今や膨大な量のコードを生成できる。LLM特有の冗長さ（それも大半はうまく指示できていないことの結果だが）を差し引いてさえそうだ。毎日5千行ものコードをどうやってレビューしろというのか。
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 Arraysの実装時にも手を入れた。今、Redisのソート済みセットで50%のメモリ削減を実現する最適化でも同じことをしている。近くPRを出す予定だ。だが、もはやこれは有用だとは感じていない。誰ももうこのコード自体を見るべきではない。見るべきは、コードに含まれるアイデアだけだ。それでも僕がレビューを続けているのは、ユーザーへの敬意からだ。Redisは今や広く使われる存在であり、多くのプログラマがファイルを開いて手作業で修正するだろうからだ。だが、もし自由にやれるなら、僕は何をするか分かるか？レビューに費やしている時間をすべて、より徹底したQAや、次の最適化アイデアを考えて適用することに充て、そしてLLMを使ってDESIGN.mdファイルを書く。各データ構造を人間の言葉で、そのアイデア、実装のトリック、設計とともに記述するのだ。それは将来、はるかに役に立つ。ソート済みセットを修正したいのか？ファイルを開いて設計を読めば、アイデアはあなたのものになる。正しいメンタルモデルを持った上でエージェントを開き、何をすべきかを尋ねればいい。これはコードをレビューするよりもはるかに有用だ。

FableやGPT 5.6によるソート済みセットのメモリ削減に対するレビューは、僕のレビューが見つけるよりもはるかに多くのエラーや微妙なレースコンディションを見つけるだろう。それでも僕はやる。だが、大多数のソフトウェアプロジェクトにとって、もはやこうしたことは意味をなさない。むしろアイデアをコントロールすることに集中すべきだ。品質、テスト、そして自分が届けたいソフトウェアの明確なビジョンに集中するのだ。世界は変わった。それは苦痛だが、すでに完全に腐敗していたソフトウェアの世界を改善する機会にも満ちている。

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