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

人間のコーダーは依然としてLLMより優れている

2025年5月30日原文(antirez.com)

概要

人間の創造性と柔軟な発想が、現在のLLM(大規模言語モデル)を大きく上回っていることを実感した体験談。 Redisのベクターセット機能のバグ修正で、AIの提案を参考にしつつも最終的には人間独自の工夫が決め手となった事例。 AIは有用だが、決定的なブレイクスルーや「枠外」の発想はまだ人間の領域。 AIとの対話を通じてアイデアを検証・発展させるプロセスの重要性。 AI活用の現状と限界を、実体験を通じて再認識。

人間の創造性とLLMの限界

  • LLM (大規模言語モデル)は日常的に活用、コードレビューやアイデア検証に利用
  • AI の能力は実用的で優れているが、 人間の知能 にはまだ大きな隔たり
  • Redisの ベクターセット 機能で複雑なバグ修正作業に直面
  • RDB/RESTORE の耐障害性強化機能の導入による新たな課題発生
  • HNSW (Hierarchical Navigable Small World)グラフの高速保存のため、ノード間リンクを整数で直列化
  • 双方向リンク の破損時に発生する「use-after-free」バグの検出が必要
  • 全リンクの 相互性チェック はO(N^2)の計算量で大規模データでは非現実的

LLMとのやりとりと人間のひらめき

  • まずは 素朴な実装 でバグ検出に成功するも、読み込み時間が2倍に増加
  • Gemini 2.5 PROに 効率化案 を相談、隣接リストのソートとバイナリサーチを提案される
  • ハッシュテーブル によるリンク管理案を自ら発案、LLMは妥当性を認めるもパフォーマンス面を指摘
  • snprintf() 不要でmemcpy()利用の簡素化も自力で気付く
  • XORアキュムレータ による高速な検出法を考案、LLMは衝突リスクを指摘
  • 良質なハッシュ関数 (murmur-128等)と乱数シードの導入で安全性・実用性を両立
  • 最終的に 人間の創造性 がAIの発想を上回る結果となる

AI活用の価値と限界

  • LLM はアイデアの検証・整理に非常に役立つツール
  • 「枠外」発想やあいまいな解決策 は、現時点では人間の独壇場
  • AIとの対話 が思考プロセスを刺激し、新たな発想の呼び水となる
  • 実際の運用では、 パフォーマンスと安全性のバランス を考慮した最適解が求められる
  • 今後も AIと人間の協働 が重要、だが「決定的なひらめき」は依然として人間の強み

Hackerたちの意見

それ、私の経験と合ってるわ。実際、LLMアシスタントから得られる価値のかなりの部分は、そこそこ賢いラバーダックと話せることだと思う。たまにそのダックが反対したり、改善してくれたりもするしね。 https://en.m.wikipedia.org/wiki/Rubber_duck_debugging みんながこの会話を飛ばしたいと思ってる大きな疑問は、2年後もこれが真実であり続けるのかってことだよね。どう答えたらいいか分からないな。

10年後もLLMはこんな感じだと思う。でも、誰かがもっと良いものを作るかもしれないけどね。今のAIをプログラミングを解決するものに extrapolate する理由は全くないよ。新しいものが持つ制約は、今のものとは全然関係ないだろうし。

私にとっては、ペアプログラミングみたいな感じだね。アイデアを話し合える相手がいるし、コードをレビューしてもらったり、別のアプローチを提案してもらったりする。自分とは違う機能を使っている人から学べるのもいいよね。

チェスみたいなもんだね。今は人間の方が優れているけど、永遠にそうとは限らない。でも、人間とソフトウェアの組み合わせは、どちらか単独よりも長い間優れていると思う。

これは、能力に対して完全に不釣り合いな、強気なアヒルだね。これと話して道を誤った人をたくさん見てきたよ。

実際、LLMアシスタントから得られる価値のかなりの部分は、そこそこ賢いラバーダックと話せることだと思うんだ。「ラバーダックデバッグ」っていう言葉が未来でもまだ使われるのかな。

一緒に働いている何人かは、ソフトウェアエンジニアリングをあまり理解していないみたい。彼らと働くのは悪くないし、実際にコラボレーションやドキュメント作成は得意なんだけど、コードをしっかり追って論理的に理解する能力がないみたい。LLMが出る前は、そういう仕事をしていなかったからまあ大丈夫だったけど、今は微妙なカオスモンキーが解き放たれた感じ。PRで「なんでこうなってるの?何をしてるの?」って聞くと、「わからない、ChatGPTがこうしろって言った」って返ってくる。これが問題で、彼らのコードはほぼすべて疑わしくなっちゃう。動くものもあれば、意味不明なものも、実際に害を及ぼすものもある。LLMが信じられる出力を出すから、コードをチラッと見ただけじゃそれがナンセンスだとわからないんだ。もしクレッドアプリみたいなものであれば、何が動いていて何が壊れているかすぐにわかるけど、私たちは科学ソフトウェアを扱ってるから、コードを理解していないと研究結果を完全に台無しにすることもあるんだよね。

みんながこの会話を飛ばしたいと思ってる大きな質問は、2年後もこれが真実であり続けるのかってことだよね。どう答えたらいいかわからないけど、数年前のトム・スコットの「AIカーブの今どこにいる?」っていう動画を思い出す。

私にとっては、APIに詳しいジュニア開発者が下で働いてる感じなんだけど、アーキテクチャに関する常識が全然ないんだよね。彼らにタスクを任せられるのはいいけど、私の頭は他の問題に使えるから、レビューが以前よりもずっと多くなっちゃった。チームにレビューを頼む前に、毎回3〜4回のレビューサイクルを通してるよ。

同じく。今日、特定のエッジケースでREST APIがどう振る舞うべきかを探るために使ったんだけど、いろんな選択肢について自信満々の意見をくれたんだ。でも、それらは矛盾だらけで、存在しない段落への言及もあった(実現しなかった選択肢3とか)。でも、読んでるだけで解決策が見えてきたよ。それは、提案されたものとは全然違ったけどね。

アヒルは時々意見が合わないこともある それは私の経験とは違うな。LLMは確かに役立ってるけど、一般的には正しい答えをくれるか、信じられそうなけど間違ったことを作り出すかのどっちかだよ。自分が何をしているかを伝えると、いつも息を切らしたような称賛が返ってくるけど、「それは違うと思う、こっちを試してみて」なんてことは一度もない。

「より良い」というのは常にタスクに依存するよね。LLMは、CSSの文法を正しく取得したり、人気のライブラリ(例えばfetch)を呼び出す方法を覚えたりするような、単純作業ではもう僕よりずっと優れてると思う。こういうちょっとしたサイドクエストは昔はかなりの時間を食ってたから、ほぼ瞬時にできるツールがあるのは嬉しいよ。

Hacker Newsで議論の続きを見る