HNで再確認: LLMコーディングはacceptance criteriaを先に置くほど強くなる

なぜHNで広がったのか

2026年3月7日時点で、Hacker Newsのスレッドは、「AI code quality」を感覚論ではなく計測可能な失敗として示した点で注目を集めた。元記事の Your LLM Doesn't Write Correct Code. It Writes Plausible Code. は、LLMが生成したRust製のSQLite再実装を元のSQLiteと直接比較している。100-row primary-key lookupでは、SQLiteが0.09 ms、再実装が1,815.43 msで、20,171x遅かった。

重要なのは、このプロジェクトが見た目には壊れていなかったことだ。コードはcompileでき、testsも通り、file format compatibilityも主張していた。つまり「動いて見える」ことだけでは不十分だ。小さな確認では正しい結果を返しても、productionで必要な性能やalgorithmic invariantを破っている可能性がある、というのが記事の核心である。

どこで失敗したのか

技術的な診断はかなり具体的だ。SQLiteでは INTEGER PRIMARY KEY が内部の rowid のaliasとして扱われるため、WHERE id = 5 のような検索は直接のB-tree searchに乗るべきだ。Katana Quantは、このRust再実装のplannerが rowid、_rowid_、oid のようなliteral nameしか認識していなかったと指摘した。その結果、named primary key lookupは期待されるlogarithmic pathではなく、full table scanに落ちていた。

記事はさらに、schema reload、再compile、page copy、batched transaction外での高コストなsyncが積み重なっていたことも説明している。個別に見れば極端ではない判断でも、組み合わさると、もっともらしい再実装がユーザーの期待するデータベースの中核動作を外してしまう。

HNの議論が加えた文脈

HNのコメントは、この問題をデータベースの外側にも広げた。複数の読者は、frontier coding modelが特にspecificationの甘い課題や未経験の課題で脆いと指摘した。これは元記事の中心的な勧告と一致する。生成の前にacceptance criteriaを定義せよ、ということだ。実務では、latency budget、algorithmic expectation、correctness check、regression test、そしてそれを検証するverifier toolingを先に書くことを意味する。

coding agentを導入するチームにとっての教訓も同じだ。promptの書き方よりもverification designの方が重要である。開発者が、なぜquery plannerがfull scanではなくB-tree seekを選ぶべきかを説明できないなら、モデルの自信に満ちた出力はその差を埋めてくれない。HNでこの話題が伸びたのは、関心が「うまく生成されるか」から「明示的なtestsを通るか」へ移っているからだ。

原文: Your LLM Doesn't Write Correct Code. It Writes Plausible Code.