- Redisの創始者 antirez は AIとLLM を頻繁に活用しているが、現時点では人間の問題解決能力 がLLMをはるかに上回っていると考えている
- Redisベクターセット で発生した複雑なバグ修正の過程で、LLMの限界を直接経験した
- LLMが提案する アルゴリズム は標準的、あるいは単純な解法にとどまる
- 人間の開発者による 創造的なアプローチ は、LLMが到達しにくい革新的な解決策の提示に有利である
- LLMは アイデア検証や対話相手 として非常に有用だが、最終的な創造性は人間にある
はじめに: 人間とLLMの比較
- 私は AIとLLM に対してまったく反感を持っていない
- 長いあいだ LLMを日常的に活用 しており、アイデアのテスト、コードレビュー、代替案の探索など、さまざまな形で使っている
- AIの現在の水準は明らかに実用的で優れている点があるが、人間の知能との隔たり が依然として大きいことを強調したい
- 最近はバランスの取れたAI議論が難しくなっていると感じ、この必要性から文章を書いた
Redisベクターセットのバグ事例
- 最近 Redis 内の Vector Sets に関するバグを修正していた
- Redisの同僚たちが不在のあいだに、ファイルデータ破損（RDB/RESTORE）に対する追加の保護機能を導入した
- これはデフォルトでは無効で、チェックサムが通っても破損を防ごうとする追加の安全策である
- 問題は HNSW 構造体のグラフ表現をRDBへシリアライズする際の速度最適化で発生した
- ノード間の接続リストを整数型で保存し、デシリアライズ時にポインタへ復元する方式である
- HNSW自前実装の特徴（相互接続を保証すること）のため、グラフ/メモリ破損時には次の問題が起こりうる
- AがBに接続されていると保存されているのに、BがAに接続されていない場合がある（番号付けの誤りなど）
- Bノード削除時に相互接続の条件が破られることで、A→Bリンクが残り、その後 B->A をたどる際に use-after-free バグが発生する
- データ読み込み後、すべてのリンクが「相互接続」を満たしているか検証する必要があった
- 純粋にアルゴリズムを適用すると O(N^2) の計算量になる。大量データ（約2千万ベクター）では、読み込み速度が45秒→90秒へと倍増することを確認した
LLMの活用と限界
- Gemini 2.5 PRO と対話しながら、より効率的な方法を尋ね、LLMの提案を検討した
- LLMの最初の提案: 隣接ノードのリストをソートして二分探索（binary search）を適用する（すでによく知られている方法）
- 大きな改善効果がないことを理由に追加のアイデアを求めたが、より良い回答は得られなかった
- 私が提案した代替案: ハッシュテーブルを使ってリンクのペア（A:B:X、ソートと双方向の区別を除去）を登録・削除する
- LLMも良いアイデアだと評価したが、キー生成性能やハッシュ性能などを欠点として挙げた
snprintf なしで固定長キーを memcpy で処理して効率を高める案も追加で示した
人間の創造性 vs LLMの限界
- 私はハッシュテーブルなしで、アキュムレータにXOR手法を適用するアイデアを提案した
- ポインタのペア（およびレベル情報）をアキュムレータにXORし、相互接続があれば相殺されて0になり、欠落があればパターンが残る
- ただし、衝突の可能性とポインタの予測可能性が問題になりうることを指摘した（LLMもこれに同意した）
- 追加改善: ランダムシード/ハッシュ化（murmur-128 と urandom シード）を組み合わせ、128ビットのアキュムレータにXORを適用
- 最後にアキュムレータの値が0かどうかで相互接続の成立可否を判定する
- LLMはこの方式について、一般的な誤りや外部攻撃者に対する堅牢性も高く、効率的だと評価した
結論
- 最終的には信頼性を判断したうえで導入するかどうかを決めるため、分析を終えた
- この事例では、人間の開発者による創造的で非標準的なアプローチ が、LLMの提供する制約のある回答より優れていることが確認できた
- LLMは アイデア検証と知的な対話相手（「スマートなアヒル」の役割） として非常に有用である
- しかし、最終的な創造的ソリューションを導き出す能力 においては、人間の優位は明らかである
7件のコメント
redis、すぐに時代遅れになりそうだね
自転車とランニングを競わせるような感じですね。
antirezは1%の人間開発者ですね。1%の人間開発者は今後もLLMより優れていると思います。ですが、99%がどうなるかは分かりません。
AIでトラブルシューティングをしようとしてことごとく失敗し、結局は自分で問題を解決したことが何度もあります。
LLMが高度で創造的に見えるのは、そのような文章を学習してきたからであり、その成果を高めるために数多くの科学者がその知識を検証し、学習データの質を高めてきたからだと思います。
しかし、時間がたつにつれてトレンドが変わったり、状況に応じて異なる創造性が必要になったりするので、結局は使う人が自分の状況に合わせて創造性を発揮しなければならないのではないでしょうか。
Hacker Newsのコメント
私の経験とまったく一致していると思う。実際、LLMアシスタントが私にもたらす大きな価値は、かなり知的な「ラバーダック」の役割を果たしてくれること。たまにこの「ダック」が私の意見に反論したり、さらには私の考えをもっと洗練させてくれることさえある。(ラバーダック・デバッグとは？) ただ、みんなが避けたがっている核心的な問いは、「こうした価値は2年後も続いているのか？」という点だと思う。私にもその答えは分からない
私にとってLLMはラバーダックではなく、「間違った回答生成機」のような存在。ネット上で答えを得る一番いい方法は間違った答えを投稿することだ、という話があるけれど、私にとってはまさにその役割。LLMに単純だが面倒な仕事をさせると、とんでもなく間違った結果を出してくるので、かえって腹が立って、その怒りの勢いで自分でやってしまう
自信過剰すぎるダック役で、実力に比べて確信が強すぎる。LLMと話していて道に迷う人をあまりにも多く見てきた
私にとってLLMは、APIには詳しいがアーキテクチャでは常識が足りないジュニア開発者が自分の下で働いているのに近い。妙なミスを心配しながら、ほとんどのPRをチームレビューに回す前に3〜4回も見直している。そのおかげで脳を別の問題に向けられるのは良い
2年後にもこの価値が維持されるか？ 私にとっては「この話題を通り越したい」という問題より、「私たちはその時まで持ちこたえられるのか？」という心配のほうが大きい。今の世界は不安定すぎて、6か月後の姿すら予測できない
私にとってLLMはペアプログラミングする相手のような感じ。アイデアを話せる相手であり、コードレビューや代替案を出してくれる存在。そして、自分が知らなかった機能を使ってみせてくれるので学べる
このコメント欄を見ていると、「人間は不可欠だ」「LLMはデバッグできない」「LLMは間違った方向に導く」といった話に、みんな少し期待を寄せている雰囲気がある。もちろん事実ではあるが、2年前には不可能だったコード自動生成がものすごく進歩し、今も速いペースを維持している。今後は「パレートの法則」のように改善速度が鈍るかもしれないが、確実に進歩は続くと思う。最近r/fpgaで、LLMで最初のバージョンのテストベンチ作成に成功した経験を話したところ、試してもいない人たちが可能性そのものを無視しているのを見て、とても驚いた
こういう態度は専門職の人たちの間ではごく普通。/r/law(法律サブレディット)にも行ったが、Dario Amodeiの法律分野のAIに関する発言を聞いて、反射的に切り捨てる雰囲気を実感した。適応機制であり現状への安住なのかもしれないが、経済・社会の変化に対応する将来への備えという点では非常に良くないことだと思う
アセンブリが基本だった時代、プログラミング言語が登場した当時に、プログラマたちが（事実とはあまり関係なく）非効率だ、柔軟性がない、単純化しすぎだと嘲笑していたのと似ている。こういう現象は、新技術の実際の価値とはあまり関係なく自然に起こる反応だ
LLMがしばらく急成長したあと、最近のモデルはむしろ後退しているようにも感じる。テストコード生成では良い結果が出るが、LLMを新機能の実装のような作業に深く使いすぎると、かえっておかしくなる。新規プロジェクトや簡単なWebアプリ開発にはよく効くが、大規模またはレガシーコードのリファクタリング、機能追加には効果が大きくない。たとえばClaudeやChatGPTがD3 API全体についてもっともらしいデタラメを並べるのをよく見かける
結局のところ、あなたは自分の代替物を自分で作っているのであって、同僚たちは慎重に動いているということだ
ChatGPT-4oはVHDL作成で驚異的な能力を発揮する。今日も低レベルコントローラのプロトタイプ作成で素晴らしい成果を体験している
本物のソフトウェアをきちんと書くために必要なコンテキストは、LLMにとってあまりにも膨大だ。ソフトウェアとは、それ自体が「ビジネスのコード化」でもある。営業チームが顧客に約束したあらゆる特別条件や、部門ごとの暗黙のルールを、LLMがどうやって知るというのか。今のLLMが解決できる範囲は、一般的で限定的なものにとどまる。クラスが2つを超えるか、ファイルが20〜30個を超えると、最上位のLLMでさえ道に迷い、焦点を失う。コンテキストを維持できないため、無駄なコードchurnが激しくなる。LLMが本当に開発者を置き換えるには、もっと多くのコンテキストを取り込み、組織全体からコンテキストを集め、長期プロジェクトでも思考の流れを保たなければならない。こうした問題が実際に解決段階に入ったら、その時こそ本当に心配し始める予定だ
LLMが開発者を置き換えるかを議論するたびに、みんなが忘れていることがある。実際のソフトウェアエンジニアリングには、コードを書く以外にも膨大な仕事がある。コードを書くことはむしろ小さな部分だ。重要なのはソーシャルスキル、要件分析、そして実際に顧客が本当に望んでいたものを見つけ出すことだが、当の顧客自身でさえ自分の望みをよく分かっておらず、エンジニアはそれを把握するのに苦労する。人間にとっても難しいことなら、LLMがそれをやれるはずがない
結局これはフィードバックループ、つまり顧客が実際に使って意見を返す即時の反復過程の問題だ。チャットUIは顧客フィードバックループとして非常に優秀で、エージェントは素早く新バージョンを作り出す。LLMは抽象化、さまざまなコンポーネントシステム、全体構造の設計、要件分析まで十分にこなせる。鍵は反復速度がどれだけ速いかだ。モデルの堅牢性とIQは改善し続けている。ソフトウェアエンジニアリング全体はすでに自動化の段階に入っている。おそらく5年後には、人間が補助なしでやると巨大なボトルネックになる。AIと深く統合しなければ、遅れを取るしかない
2000年代のオフショアリング(海外開発者へのアウトソーシング)ブームの時にもあった問題がまさにこれだ。海外チームは修正要求や問題提起がしにくく、言われたとおりに作るだけで、結果として問題が積み上がっていった。AIでも似たことが起きそうだし、結果も似たものになる気がする
LLMはそもそもソフトウェアエンジニアリングそのものをしていない。だが、それ自体は問題ではない。実際、多くの成功したプログラムは「ソフトウェアエンジニアリング」なしでもうまく動いている。クラウドコスト構造を誰も気にしない環境ではなおさらだ。むしろ今後は、ITビジネスパートナーのような技術的センスのある人が、ソフトウェアエンジニアの助けなしにアプリを丸ごと作るようになると思う。グリーンエネルギー業界では、すでにそれが日常だ。ただし問題は、保守、拡張、効率が必要になったときに噴き出す。その時になって初めて、「Pythonでリストを使うかジェネレータを使うか」のようなことが重要になり、本当のエンジニアリングが必要になる
5年後にはコード設計をほとんどしなくなる可能性がある。すでに1年前と比べてコードをタイピングする量は大幅に減った。とはいえ、これはプロセスの一部にすぎず、開発者が全員消えるわけではない
一方で、単なる「コーダー」の役割はかなり置き換えられつつある。LLMが得意なのはまさにこの部分だ。よくある「このAPIを受けてあの値を返せ」というチケットだけを見て、顧客要求の把握や分析は一切しない思考停止のコーダーが多く、そこを急速に片付けている。本格的なソフトウェアエンジニアリングはそれとはまったく別物だが、単純コーダーへの需要が非常に大きかったことは無視できない
人間だけが、プログラムの抽象概念と創造的な問題解決を行う能力を持っているというのは非常に重要なポイントだ。プログラマとは論理の建築家であり、コンピュータは人間の思考様式を命令へと変換する存在だ。ツールが人間を模倣して特定作業ごとのコード生成をうまくこなしても、根本的な抽象設計と構築の役割までは置き換えられない。モデルがコード記述だけでなく、仕様書に従ってプロジェクト全体を丸ごと作る機能を備えるようになれば、開発者の役割自体もまた変わっていくだろう
常に「何がより良いか」は作業ごとに違う、というアプローチが必要だ。LLMは反復的で定型的な仕事(CSS文法を合わせる、有名ライブラリの呼び出し方のようなもの)では、すでに私よりずっと優れている。こうした「細かい雑務」は以前は私の時間を大きく奪っていたが、今ではほぼ即座に処理されるので非常に満足している
根本的なスタイリング(基本的なCSS以上のもの)では、LLMの結果はむしろあまり良くない。効果そのものを明確に説明しにくかったり、作業が微妙になると、いちばん重要な結果を出せず、一つのやり方に行き詰まることが非常に多い
私が苦手なもの(SQL)ではLLMのほうがはるかに良いが、私がよく分かっているもの(CSS)ではむしろ劣る。基準がはっきり表れている
「大半の開発者より良い」という話と、CSSができないからLLMのほうが良く見えるという話に同意する。実際、CSSを嫌って学ばず、仕方なく使っている人が多いことから生まれる誤解だ。会社が本物のCSS専門家を雇えず、安く済ませたいなら、その時にLLMが代替になる。本当に上手い人を雇う余裕があるなら、LLMは当然比較にならない。結局、LLMの競争相手はスキルの低い開発者だという結論になる
主要言語や正確には分からない領域では、LLMの自動補完は大きな助けになる。ただし「反射的に思い出せる能力」を鍛えず、LLMだけに依存すると、このツールが勧めたものを評価する力が不足し、質の低い解決策にとどまる危険が大きい
「良いコード」を心配する人が多いのはうれしいが、実際にはそれが無意味になるのではないかと恐れている。ソフトウェア業界はもう長いことビジネスの世界に浸食されており、いつからそうなったのかすら定かではない(ビル・ゲイツが1976年に公開書簡を書いた時からだろうか？)。本当の問題は、株主や経営陣がコードのことをあまり気にせず、利益さえ上がればよいと思っていることだ。開発者やユーザーの文化的な抵抗がなければ、この構造は続いていくだろう
開発者やユーザーの文化的な抵抗がなければ終わりだ、という話については、企業の中にも良いコードを書くところは多いし、すべてがめちゃくちゃというわけではないことを言いたい。問題はコード品質ではなく、資本主義的なビジネス目標に同意するかどうかという倫理の問題だ。美しいソフトウェアと現実とのバランスこそが最も重要だ。私も開発者であり創業者として、オープンソースやエンジニアリングが好きだが、同時に十分に快適な暮らしもしたい
コードはビジネスの動力だ。悪いコードは悪いビジネスに帰結する。ホスティングチーム(物理ファイアウォール、vmware、プロキシなど)と、パブリッククラウド(QEMU、Netfilter、単純な機器など)の間には明確な違いがある。どちらがどちらを浸食したのか、未来は誰にも予測できない
昨夜はo3と格闘して時間を全部使ってしまった。一度もDockerfileを書いたことがなかったので、いっそo3にGitHubリポジトリを入力して自動で解決させようと思ったが、その出力のデバッグに何時間も無駄にした。存在しないものを付け足したり、ないものを消したり混ぜたりすることが多く、
python3とpythonの違いのような基本概念すら混同していた。結局キレてGoogle Docsを探したら、すぐ整理できた。AIも素晴らしい道具だが万能ではなく、誰かが必ず「起きて」見ていなければならないという教訓だLLM・AIで社員の業務生産性を上げる会社は繁栄し、社員を丸ごと置き換えようとする会社は失敗すると予想する。短期的にはCEOや役員が短期実績に満足し、将来の成長を削るような選択をするかもしれない
まさにそれが答えだ。プログラマのアシスタントとしてLLMを使うのが正しく、完全な代替は無理だ。技術を適度に受け入れるのが正しい道だ
社員の置き換えで短期的な価値を高め、会社に利益が戻るかもしれないというアイデアはかなり興味深い。つまり、中長期的には会社に害でも、一時的に株価が上がることはありうる
コードアシスタントは必須の共通ツールであって、人を置き換える武器ではない。競合他社も同じAIサブスクリプションを買える時代に、人を置き換えることはできない
現場経験の共有。以前は開発者で今は管理職だが、今でもコードを書く。LLMアシスタントは役に立つこともあるが、ときどき煩わしい。予想外のコード提案を次々と出してきて、意図と違う方向へ進むこともあり、レビューに時間を取られる。おそらく設定の問題なのだが、明示的にコマンドで呼び出した時だけ見えるようにデフォルトを変えたい。一つ確かなのは、LLMにコード全体や関数を書かせても、必ず自分のレビュー工程を通すということだ
Zedエディタには、こうした「控えめな提案」モードの機能がある(詳しく見る)。すべてのエディタにこういうモードがあればいいのにと思う
最近はスタートアップでいろいろやっているので、LLMが作ったUIをあまり気に入っていない。ビルディングブロックのような基礎部分は有用だが、Claudeに長いコードブロックを丸ごと任せると、自分の望む結果にたどり着くまでに何度もやり直しが必要になる
https://freederia.com AI科学者サイトのように共存関係を維持するでしょう。