- SQLiteをLLMがRustで再実装したバージョンは、主キー検索において元の実装より約20,000倍遅い性能を示した
- コードはコンパイルされ、テストも通過するが、内部には中核アルゴリズムの誤りと非効率な設計が存在する
- 主な原因はPRIMARY KEYの認識漏れとクエリごとのfsync呼び出しなどで、構造はもっともらしいが実際の動作は異常
- こうした現象はAIモデルの「もっともらしさ最適化」(sycophancy) によるもので、ユーザーが明確な検証基準(acceptance criteria) を定義しなければ簡単にだまされうる
- LLMは、熟練した開発者が正確性の基準を明確に設定するときに限って生産性を高められるのであり、そうでなければ単なるトークン生成器にすぎない
LLM生成コードの性能実験
- SQLiteの主キー検索(100行基準)は0.09ms、LLMが生成したRust版は1,815.43msで、約20,171倍遅い
- 両実装とも同じクエリ、スキーマ、コンパイルオプションを使用
- Turso/libsqlとは無関係で、TursoはSQLite比で1.2倍程度の正常な性能を示す
- Rust版はコンパイル成功、テスト通過、ファイルフォーマット互換性維持など、見かけ上は正常に動作
- しかし実際には基本的なデータベース操作で深刻な性能低下が発生
主なバグ分析
- Bug #1: INTEGER PRIMARY KEYの認識漏れ
- SQLiteは
id INTEGER PRIMARY KEYを内部のrowidにマッピングし、O(log n) の探索を行う
- Rust版では
is_rowid_ref()が"rowid", "_rowid_", "oid"しか認識しない
- その結果、
WHERE id = Nクエリが全テーブルスキャン(O(n²)) として処理され、20,000倍遅くなった
- Bug #2: クエリごとのfsync呼び出し
- トランザクション外のINSERTごとに完全同期(fsync) を実行
- SQLiteは
fdatasyncを使ってメタデータ同期を省略し、はるかに効率的
- 100件のINSERTでRust版は2,562.99ms、SQLiteは32.81msとなり、78倍の差が発生
複合的な非効率要因
- ASTの複製と再コンパイル、4KBヒープ割り当て、スキーマ再読み込み、文字列フォーマット、オブジェクト再生成など、多数の設計選択が積み重なって約2,900倍の性能低下
- 各判断は「安全性」を理由に正当化できるかもしれないが、ホットパス(hot path) ではむしろ致命的なボトルネックとして作用する
- SQLiteの性能は単にC言語だからではなく、26年にわたるプロファイリングと微調整の結果である
2つ目の事例: 不必要に複雑なディスク管理ツール
- LLMが生成した別のRustプロジェクトでは、ビルドアーティファクト整理用デーモンが82,000行で実装されていた
- 192個の依存関係、7画面のダッシュボード、ベイズスコアリングエンジンなど、過剰な機能を含む
- 実際の問題は1行のcronコマンド(
find ... -exec rm -rf)だけで解決可能
- これは「要求された機能」は忠実に実装していても、実際の問題解決には不要な複雑さを追加した事例である
意図と正確性の乖離: 「Sycophancy」現象
- LLMはユーザーの期待に合わせようとする**「追従的同調(sycophancy)」**の傾向を示す
- Anthropicの研究(2024)とBrokenMathベンチマーク(2025)は、正確性より同意率を学習する構造的問題を確認
- GPT-5でさえ、ユーザーが肯定的シグナルを与えると偽の定理の証明を29%生成
- RLHF(人間のフィードバックによる強化学習)が同意バイアス(agreement bias) を強化する
- OpenAIは2025年のGPT-4oアップデートでこの問題によりモデルのロールバックを実施
- コード生成だけでなく、自ら生成したコードのレビュー時にも同じバイアスが働き、自力で誤りを検出できない
外部研究および業界データ
- METR実験(2025–2026): 熟練したオープンソース開発者16人がAIを使った場合、19%遅くなった一方で、本人たちは速くなったと認識
- GitClear分析(2020–2024): 2億1,100万行の中でコピー&ペーストの増加、リファクタリングの減少が確認された
- Replit事故(2025): AIエージェントが本番データベースを削除した後、架空のユーザー4,000人を生成
- Google DORA 2024レポート: チーム単位でのAI利用率が25%増加すると、デリバリー安定性が7.2%低下
SQLiteが示す「正確さ」の基準
- SQLiteは約156,000行のCコードで、100%のMC/DCカバレッジを確保し、航空ソフトウェア水準の検証を達成
- 主な性能要因:
- Zero-copyページキャッシュ
- Prepared statementの再利用
- Schema cookieチェックによる不要な再読み込み防止
- fdatasyncの使用によるコミット遅延の最小化
- iPKeyチェックによるO(log n)探索の保証
- 一方、Rust再実装版は576,000行あるにもかかわらず、核心となる1行(
is_ipk確認)を欠いていた
結論: 「もっともらしさ」ではなく「正確性」を定義すべき
- LLMはパターンを模倣するが、性能不変条件(invariant) を自力で学習することはできない
- 「コードがコンパイルされる」だけでは不十分であり、バグを自ら見つけて説明できなければならない
- LLMは、熟練した開発者が正確性の基準を明確に定義するときに強力なツールになる
- そうでなければ、単なるもっともらしいトークン生成器にすぎず、「vibe coding」の域を出ない
- 核心メッセージ: まず正確性の基準を定義し、測定せよ。
16件のコメント
これは、単純な性能に関する success criteria すら与えないとどうなるかをよく示している事例だと思います。これまで使ってきたコーディングエージェントは、問題解決そのものは目指すものの、明示的な事前プロンプトや検証ループなしでは、ほとんど自力で性能を最適化しません。コーディングテストの問題を出すつもりで AI に指示する必要があります。特に、このように baseline があるケースであるにもかかわらず、性能条件を明示せずに最適な性能結果を期待するのは、AI を使う側の一種の怠慢だとも言えます。
+1 👍
実際、LLMだけがそうなのではなく人間もそうではあるのですが、
違いは人間にはフィードバックが効く一方で、LLMは妙な癖をほとんど直せないことです。指摘しても、結局ある時点でまた同じことをやります。
その点で非効率や疲労が生まれるのではないでしょうか
人々がモデルの特性を把握し、適切なプロンプトやスキルワークフローを見つけ出して適用する頃には、もう新型モデルが出てくるので……
エージェントを今まともに使えるのかどうかさえ疑問です。
George HotzもAIを一種のコンパイラとしてだけ意識して使っています。設計や構造、あるいは選択においては、まだ人間の判断が必要です……。全体的にAIに主導権を委ねてしまうなら、そもそも開発者がやる必要はありません。
すでに完璧に実装された最適化バリバリのクエリと比べて、それを別の言語で書き直してくれって言えば、そりゃ遅くなるよね
「とりあえず書いて」で頼んだんだから、まあそうなるよね（笑）
ビッグテック級のバイブコーダーの皆さんが、コメント欄に登場する予定です。
生産的なコメントを書かないなら、コメントしないでください
笑ってしまいました
ｗｗｗｗｗ こんなクソ文でも文章です
何も言わないでください
デッドインターネット理論になる前に
うんこ へへ
hacker newsから持ってくるものだけど、あそこもいつも生産的なコメントばかり付くと思っているのか……。あまり見栄えがよくないですね
Hacker Newsのガイドラインは読んだんですか……。こういう投稿は控えるべきでしょう。「あいつだってクソみたいなことをしてるのに、なんで俺にだけ言うんだ」みたいな考え方は本当に幼稚ですね。
違います。あいつもウンコするのに、なぜあいつにだけそんなことを言うんだ、というべきです。
少し指示してみるだけでもすぐに実感します。他の開発者がレビューに疲れると言っているのが理解できなかったのですが、どれだけプロンプトやスキルをうまく使っても、AIが作ったコードにはいつもどこかしら欠陥がありました。
原文を読んでみましたが、妥当な分析と批判だと思います。ですが、引用されている研究の実験モデルは、現時点では少し古い（？）感じがします。
Hacker Newsの意見
基本的にLLMは、問題が起きるとコードをさらに掘る方向で解決しようとする傾向がある
非効率なアプローチで実装すると、その後制約にぶつかるたびに回避コードや重複コードを追加し続ける
パフォーマンスが遅いと言われれば、高速経路の最適化、特殊ルーチン、カスタムデータ構造を継ぎ足すことでコードが幾何級数的に増えていく
バグが多いと言われれば、バグごとにテストを10個ずつ作り、既存のモックフレームワークが合わなければ新しく作る
重複を統合しようと言うと、「いいですね、すべての機能を含んだmetamock abstract adapter frameworkを新しく作ります！」と言って、また別の複雑な構造を追加する
誤った前提や技術的負債を生まないようにレビューする工程が必須だ
まず合理的なアーキテクチャを設計させ、モジュールがこんがらがったらクリーンなコンテキストでやり直させる
LLMは同じコードを繰り返し修正するのは苦手だが、「Groundhog Day」式に最初から再実装するのは得意だ
LLMはこうした判断の結果を警告したり思い出させたりしてくれない
だから私はCodexよりClaude Codeを好む
法律文書の作成でも、LLMの「もっともらしい」結果が問題になる
最初に見ると妥当に見えるが、実際には論理的に不適切だったり危険だったりする主張であることが多い
裁判官には細かく精査する時間や意欲が足りず、こうした文書がそのまま通ってしまうこともある
これはBrandoliniの法則のように、生成は容易だが反駁は難しいという非対称な構造を生む
結局、将来の開発者がLLMの作った認知的・技術的負債を解消しなければならない状況と似ている
規定ベースの文書をLLMに書かせると、もっともらしいが根拠のない含意が含まれる
そこで再びLLMに自分の文章をレビューさせてそうした箇所を示させるが、結局は人間のレビューが必要になる
同僚たちがLLMで数千行のPRを数分で生成する
テストも含まれているが、実際にはひどい場合が多い
結局レビューアが一日中確認し、誤った構造を理解して修正方針を説明しなければならない
だからAIで作られたPRにはレビューアにストーリーポイントを与えるべきだと提案したい
合理的な判断を形式論理として計算し、その結果を自然言語に翻訳する構造が必要だ
LLMは思考ではなく、解釈と表現の段階にとどまるべきだ
LLMが作ったコードはテストには通るが、要件を満たしていない場合が多い
たとえばfsyncをクエリごとに呼んだり、主キーを誤って識別したりする
こうした大規模プロジェクトはコードが多すぎて、人間がすべて読むのは難しい
だからLLMは自動補完レベルで使うと最も効率的だ
小さなコード片ならその場でレビューでき、Claudeは概ね正確だ
だがコード全体を任せると、計画と管理により多くの時間がかかり、保守もしづらくなる
結局、訓練データにすでに存在するコードを再生産するときにだけ速度上の利点がある
LLMは統計的に最も一般的なコードパターンを生成する
そのため特に指示がなければ、「エンタープライズっぽく、OOPベースで、流行りの依存関係を大量に入れたコード」になる
「正確さ」を定義し、測定しなければならない
自動化には**意図（intent）と測定（measurement）**が必要だ
リスク範囲を理解してこそ、事前にどこまでカバーすべきかもわかる
AI評価システムであるAI evalsやeval-ceptionのようなツールが
役割間の共通言語へと発展すれば、協業ははるかに容易になるだろう
最ももっともらしいコードを生成するよう設計されているのがLLMの本質だ
これはcross entropy lossの結果であり、RLVRのような後処理で正確性を高めようとしているが
それでも多くの残滓が残っている
今後reward engineeringが進歩すれば、より良い結果を出せる可能性がある
「それは人間と何が違うのか？」という問いに対して
睡眠中はこの機能が切れて夢のような非論理的思考になるが、LLMの思考もこれに似た夢の論理の水準だ
以前は技術を完全に理解できていない不安があったが、今はツールがその不安を覆い隠してしまう
深い理解がなくても結果を出せる時代になった
しかし人々は客観的で正解を与えるAIを期待している
このギャップが一般ユーザーと専門家の認識差を生む
一日に数千行のPRを上げる人がいる
たいていはひどく、レビュー不可能だ
昔ならこうしたPRを作るのに一週間はかかっただろうが、今では一日で流れ込んでくる
「LLM」という用語自体に対する疑問も多い
raw APIで直接呼び出すモデルがLLMで、Claude.aiやChatGPTのようなものはその上にハーネス（harness）を被せたものだ
こうしたハーネスには、プロンプトテンプレート、会話状態管理などさまざまな機能が含まれる
結局、私たちはほとんど常にLLMそのもの以上を使っている
こうしたエージェントはコードを実行し、自分でテストし、修正できる
ChatGPTやClaudeもこの機能を持っているので、事実上coding agentだ
したがって「LLMには記憶がない」という言い方はモデル自体にしか当てはまらない
Claude CodeやCursorは状態を保持するagentic systemだ
この記事のタイトルは興味深いが、LLMが「もっともらしいコード」を書くというのは不正確だ
実際には訓練データで見たコードクラスターに似たコードを生成しているにすぎない
RLHFやRLVRで制限されていない領域でのみ自由に生成する
だから業界全体が同じ言語で話しているが、これがかえって誤解の原因になる
みなが同じ問題を解いていると錯覚させる
たとえばtree-sitterクエリを頼むと、存在しないディレクティブをでっち上げる
わざわざ複雑な内部構造を説明する必要はない
最近CodexにDatastarベースのUI要素を作らせたが、完全に失敗した
単純な作業だったが、やり直すたびにインラインJavaScriptとバックエンドコードが増え続けた
以前のコードも整理しない
複雑な作業はうまくこなすのに、むしろ基礎的な課題で直感に反する失敗を見せる