ハクソク

世界を動かす技術を、日本語で。

アイデアを制御せよ、コードではなく

2026年7月13日原文(antirez.com)

概要

  • AI時代のプログラミング に関するantirezの考察
  • コードそのものより 設計やアイデア への注力の重要性
  • AI生成コードのレビュー の意義と限界
  • ソフトウェア開発の変化 とその痛み・可能性
  • 若手プログラマーの学び方 への提言

AI時代のプログラミング観

  • AIによるプログラミング が主流となりつつある現状認識
  • Redis再参加 や 新しいLLM推論ソフトウェア 開発など、現役エンジニアとしての活動継続
  • 未来のプログラミング像を発信する理由は、「変化に備えられていない人々」への支援意識
  • 2022年の著書 でChatGPT登場前に多くの変化を予見した実績
  • AIの進化 によるプログラミング手法の根本的変化の共有

コードレビューの意味と限界

  • AIによる大量コード生成 時代、従来型のコードレビューの非効率性
    • 毎日数千行のコードを人がレビューするのは現実的でない
  • LLMは局所最適なコード 生成に長けるが、全体設計は苦手
    • コード行単位のチェックより設計レベルでの評価が重要
  • 作業時間の使い方 として、コード閲覧よりも設計・QA・新機能検討への集中が有益
  • The Mythical Man Month など過去の知見が現代にも有効

AI時代のソフトウェア品質と設計

  • DwarfStar でのLLM推論実装経験により、現場の複雑さとエラー多発を実感
    • Attention実装の細かなバグや性能劣化など、AIが有効な領域の広がり
  • 設計とテスト重視 のエンジニアリングが、手作業のコード記述を凌駕する時代
  • AIへの抵抗 は多くがイデオロギー的なものと指摘

Redis開発でのAI活用と課題

  • RedisのAI生成コードのレビュー は必要性を感じつつも、効果には疑問
    • GPT 5.5以降の進化で、AIの方が多くのバグやレースコンディションを発見可能
  • 自分のコードスタイル へのこだわりはあるが、全体としては設計文書（DESIGN.md）作成の方が有用
    • 各データ構造の設計・実装トリック・アイデアを人間言語で記述
  • 今後は設計ドキュメント重視、コードレビューよりもアイデアのコントロール・品質・テストに注力

若手プログラマーへの提言

  • 経験の浅い若手 がAI時代にどう学ぶべきかは未知数
    • LLM出力のレビューよりも、言語を学び 小さなインタープリタやデータベース実装 などの体験が有益
  • 表面的なコードレビュー に時間を費やすより、本質的なプログラム作成経験を重視
  • ウェブサイトのJavascriptレビュー などは時間の無駄と断言

まとめ：AI時代の開発者の在り方

  • コードそのものではなく、設計・アイデア・品質管理 へのシフト
  • AI活用による効率化 と、変化を受け入れる柔軟性の重要性
  • 若手は基礎的なプログラミング体験 を通じて本質を学ぶべきという提案

Hackerたちの意見

すごく頑張ってみたけど、モデルは自分のアイデアには興味がないみたいで、トレーニングデータの中で人気のあることをやりたがるんだよね。だから、何かを無理に押し付けようとしても、特にコンテキストの長さが増えたり、圧縮に入ると、すぐに無視されちゃう。モデルをうまく活用するには、馴染みのある道を進ませて、一般的なパターンやフレームワークを言及したり、オンラインで質の高い人気のパッケージや言語を使うのがいいよ。プロジェクトはシンプルなインターフェース定義と短いデザイン/アーキテクチャのドキュメントから始めたんだけど、AGENTS.mdファイルに含めても、どんなに頑張ってもモデルはそれを無視して、同じようなものの新しいバリエーションをコードベースに散りばめていくんだ。新しいセッションが増えるたびに新しい枝が生えてくる。

└

私はAIを使って、かなり変わったプロジェクトをやってるんだ。例えば、LuaJITで完全に書かれたゲームエンジンで、ほとんどのデータ構造をCFFIを使って割り当ててる、すごく珍しいカスタムオブジェクト指向DSLを自分で設計したんだ。それに、SDL3のSDL_gpuライブラリを使って全てのレンダリングを行い、GLSL 4.6のコンピュートシェーダーをSPIR-VとMetalにクロスコンパイルしてる。タイル指向と3Dのハイブリッドエンジンなんだよ。もう一つの例は、Emacsのようなライブで変更可能な画像ベースのエディタで、これもLuaJIT+CFFIで作ってる。kqueue+アトミックロックフリーのリングバッファ+pthreadベースのアクターモデルを使って、それぞれが別のLuaJITインタープリターを動かしてる。カスタムアドバイジングシステム、イベントバス、イベントバスに乗ったasync/awaitの実装、カスタムプロセスマネジメントとIOライブラリ、Tmuxを使ったテストもある。DeepSeek V4 Flashも、メモリシステムにいくつかのメモリを構築した後は、ほとんど問題なく動くよ。DSv4-ProやGLM 5.2なんて言うまでもない。要するに、スキルの問題だね。

└

そうだね、モデルは約32kのコンテキストには耳を傾けてくれる。その半分は、コーディングアシスタントとしての「下り坂」の道に入れるためだけど。心のままに何でも投げ込めるし、単純な修正なら聞いてくれるかもしれない。でも、スマートIDEのように扱うと、基本的にトレーニングデータにある支配的なパターンに従うことになる。もしスマートな資本主義があったら（同じ問題）、フレームワークやOSごとのモデルが必要だと気づくはずで、それは80%が英語の使い方で、20%が特定のプロジェクトに必要なツールなんだ。でも、そこにはお金がないんだよね。

└

重要なのは、エージェントから自由度を取り除くことだと思う。私見だけど、これがエージェント工学の本当に難しい部分だ。エージェントが最初に何をできるかを強く制約して、特定の領域に押し込む必要がある。もちろん、モデルが分布外になる危険もあるから、実験が必要だよね。今、Rubyプロジェクトに取り組んでて、意図的に標準のRuby以外のフレームワークを使わないようにしてる。RailsやSinatraはなしで、Webrickのウェブサーバーだけを使ってる。最初はモデルをうまく進めるのが難しかったけど、学ぶにつれて楽になってきた。ただ、モデルがコードを書くときに非常に強く馴染みのある方向に引っ張られるのは明らかで、私の学習プロジェクトがそれを使ってないのに、書かれるコードの多くは「Railsっぽい」感じになってしまう。

└

みんなが平均的で同じようになっちゃう。良い平均だけど、悪いよりはマシだけど、誰かがそれが個人の表現の力を倍増させるって主張してるのを見るたびに、ちょっと引いちゃう。クソだね。

ちょっと背景を説明すると、以下の意見のためのコンテキストとして： - 銀行やヘッジファンドでほぼ20年間SRE/DevOpsをやってきた - 現在はL1の暗号通貨に関わってる - 12歳からコーディングを始めて、過去1年間はフロンティアモデルを使ってきた（同時に複数のエージェントを動かすことも含めて）。私の考え：モデルは本当に素晴らしい。大規模なコードベースを読み取って、バグを見つけたり、部分的なログから問題の根本原因を推測したりできる。ただ、まだハルシネートすることがある。以前よりはずっと少なくなったけど、ゼロではない。これが逆に厄介で、モデルが複雑なソフトウェアを生成して「はい、間違いなし。テストも書いたし、全部通ったよ！」って言うこともある。あなたは「ふぅ、素晴らしい！」と思うかもしれないけど、賢い人が書いた本番コードにバグがあるのと同じように、ここにもバグがあるはずだ。これを言うのは、全てのコードを読む必要があるとは言ってない。ただ、大規模で複雑なシステムにおいては、「絶対に正しくなければならない部分のユニットテストを書く」というのが、今でも重要だということを強調したいだけ。例えば、 - 取引システムのオーダーと実行ハンドラー - 航空機のフライトコントロール - 医療関連のデバイス - などなど。例えば、私は複雑なシステムに取り組んでいたんだけど、LLMのコードが本当に正しいかどうか自信がなかったから、確認するために簡単なスクリプトを書いて、1行ずつチェックして100%確実に動くか確認した。その後、そのスクリプトを使ってLLMをダブルチェックしたんだ。LLMが生成したコードを全部読むわけじゃなかったけど、「ああ、これで動くんだ」という感覚は驚くべきものだった。私が一緒に働いている多くの開発者も、LLMにコードとテストを書かせた後、再確認する「ハイブリッド」なアプローチを取っている。最後に、これらの大規模なリライトがLLMのおかげで可能なのは、開発者がユニット/インテグレーションテストが正しいと確信しているからだと思う。LLMに全てのコードとユニットテストを書かせて、100%正しいと確信できるとは思えないな。（これは常に難しいことで、LLM以前の時代でも全てのコードが正しい保証はなかったけど）

└

ほぼ100%のテストカバレッジがあって、テストも全部グリーンでも、飛行機が墜落することだってあるし、LLMたちが「大丈夫だよ」って言ってることもあるよね。結局、テストカバレッジなんてしっかりしたコードがないと意味がないってことを、まだ学んでない気がする。

DS4リポジトリでは、すごくエキサイティングなエンジニアリング作業が行われていて、まるでスポーツの試合を見ているかのように楽しんでる。DSparkの論文が出た次の日には、みんなが実装を試みたり、協力して失敗を検証したりしてた。その結果、パフォーマンスが理想的ではないことを認めるPRにまとめられたんだ。antirezが彼の動画の中でほのめかしていたこと（推測デコーディングは素晴らしい恩恵だけど、主に多くのリクエストを一度に処理する大規模なラボ向けで、ローカル推論にはあまり効果的ではないかも）もある。最近は、audreytのおかげで「方向性の操縦」に関する作業が進んでいて、セッションごとの方向性のオーバーライドが実現している。新しいHy3モデルのサポートもaudreytのおかげだ。ivanfioravantiのおかげで、Pre-M5の最適化もキューに入っているし、彼は初期のM5最適化にも関わってくれた。こんなリポジトリを見たのは、llama.cppやwhisper.cppの初期以来だね（ただ、llama.cppは今、Intelの新しいGPU向けのSYCL改善が進んでいて、かなりエキサイティングだ）。DS4リポジトリは、エージェントを使って重いコーディングをする人たちが効果的に協力している様子を観察するのに本当に面白い場所だよ。すごく楽しんでる。

└

ありがとう！そして、まだ多くのPRをマージできていなくてごめん。今、CUDAとMetal-RDMAのフォークのためにテンソル並列性に取り組んでいるから、PRや問題に気を配る余裕がなかったんだ。

└

ステアリングベクトルを使う能力は本当に強力そうだね。自分で作ることもできるけど、事前に作られたステアリングベクトルのコレクションってあるのかな？それとも、みんなが自分用に作ってるステアリングベクトルの種類についての情報だけでもいいんだけど。

└

「推測デコーディングは大きな恩恵ですが、主に多くのリクエストを同時にホスティングして処理する大規模なラボ向けで、ローカル推論にはあまり効果的ではないかもしれません。」これはちょっとした指摘だけど、私の理解では、推測デコーディングは（1）「検証」ステップを通常のデコードと比べて速くするための実行可能な未活用の並列性がある場合、（2）モデルの完全なレイヤーを一度にメモリにロードすることが利益になる場合に価値がある。大規模なホスティング業者には（2）が当てはまることが多いけど、例えば大きな密なモデル（Mistral Mediumを考えてみて）でSSDストリーミングと単一セッション（同時バッチなし）で推論を行う場合、推測デコーディングはかなり良いことがある。これはスペクトラムでもあって、例えば、いくつかのMoEモデルはあまりスパースではなく、比較的少ない同時リクエストがほとんどのエキスパートをカバーすることがあるので、レイヤーパラメータの完全なセットをロードして推測デコーディングを行うことで計算強度を高めることが実際に価値があることもある。

読むのがすごく不快だ。自分が書いたコードを読まないという提案は、従来のワークフローや方法論に挑戦するだけでなく、プログラマーのアイデンティティそのものに挑戦している。antirezのような経験豊富で尊敬されるプログラマーにとっては、コードを読むことや書くことがアイデアの邪魔になっているのかもしれないけど、私はその視点には共感できない。細部にこそ悪魔がいる。他の人のコード（LLMが書いたコードも含む）を読むことで、アイデア自体が進化し、理解が変わる。私の見解は、読んだり書いたりするコードが自分や家族を養うことに直接関係しているため、プロセスから自分を取り除くことを提案されるのは、楽しいどころか厳しいと感じる。

Hacker Newsで議論の続きを見る