[AIマイナーニュース速報] AIが書いた57万行のコード、実は2万倍遅かった？

📰 ニュース概要

• LLM生成コードの驚愕の遅さ: SQLiteをRustでゼロから再実装したLLMプロジェクトをベンチマークした結果、プライマリキーによる検索が本家SQLite（C言語）より20,171倍遅いことが判明した。
• 57万行の『それっぽい』コード: 生成されたコードは576,000行に及び、パーサーやB-tree、WALなどデータベースの構成要素をすべて備え、テストもパスしていたが、性能面で致命的な欠陥があった。
• 最適化ロジックの欠落: 原因は、クエリプランナーが特定のカラムをインデックスとして認識できず、O(log n)の検索ではなく、全行を探索するフルテーブルスキャンを実行していたためである。

💡 重要なポイント

• 「もっともらしさ」の追求: LLMは出力が「正しく見えるか（Plausibility）」を最適化するが、「真に正しいか（Correctness）」を保証するわけではない。今回の事例では、コード構造はプロフェッショナルに見えても、アルゴリズムの選択が完全に誤っていた。
• 受け入れ基準の重要性: 著者は、LLMを開発に組み込む際は、最初の1行を生成させる前に「ユーザーが受け入れ基準（Acceptance Criteria）を明確に定義すること」が成功の鍵であると結論づけている。

🦈 サメの眼（キュレーターの視点）

一見完璧に見える57万行のコードが、実は中身スカスカの「フルスキャン地獄」だったなんて、ゾッとする話だサメ！

特に注目すべきは、is_rowid_ref関数の実装だサメ。本家SQLiteはINTEGER PRIMARY KEYを内部的なrowidの別名として賢く処理するのに、AI版は特定の文字列しか認識できず、高速なB-tree検索へのパスを自ら塞いでいたんだサメ。これは単なる「コードが動く」ことと「実用的なソフトウェアである」ことの間に、巨大な溝があることを示しているサメね。LLMに任せきりにせず、エンジニアが「性能基準」という檻をしっかり作ってから泳がせるべきだサメ！

🚀 これからどうなる？

• 検証ツールの進化: 生成されたコードが単にコンパイルを通るだけでなく、計算量やパフォーマンス基準を満たしているかを自動検証するツールの重要性が高まる。
• プロンプトエンジニアリングの変容: 「コードを書け」という指示から、「まずテストと性能要件を定義し、それを満たす実装を行え」という、より設計に重きを置いた指示へのシフトが加速する。

💬 はるサメ視点の一言

見た目だけマッチョで泳げないサメみたいなコードだサメ！中身をしっかり検品しないと、本番環境で溺れることになるサメよ！🦈🔥

📚 用語解説

• フルテーブルスキャン: データベースから特定のデータを探す際、最初から最後まで全データを1つずつ確認する非効率な方法。データ量が増えると極端に遅くなる。

• クエリプランナー: SQLなどの命令をどう実行するのが一番速いかを判断するデータベースの「頭脳」。ここが賢くないと、高速なインデックスがあっても使われない。

• B-tree: データを効率よく検索するための木構造データ。これを使うと、100万件のデータからでも数回のステップで目的の場所を見つけられる（O(log n)）。

• 情報元: LLMs work best when the user defines their acceptance criteria first