SQLiteのWALバグを15分で発見、Antithesisが実証

長年ROMっていて普段はAntithesisの投稿を楽しんでいる者ですが、これはかなり実存的に悲しい読後感でした。ここの企業ブログの投稿は常に根底には広告があることを私たちは皆知っていますが、歴史的に見て、Antithesisは「私たちが売っているものは本当に優れている」というのを付け合わせに留め、「（著者が）面白い深い思考や、かっこいいことを成し遂げるための大変な作業をした」という主菜を提供するという線をうまく守ってきたと思います。

今回の投稿はその点で非常に精彩を欠いています。「Antithesisが稀なバグを見つける」というのが実際のコンテンツの圧倒的大部分を占めており、一方でいつものブログの主菜である、大変な作業や深い思考は、本当に「これをClaude Mobileに打ち込んで、あれをClaude Mobileに打ち込んだ」にまで蒸留されてしまっています。確かに、このバグを見つけるのにそれだけで十分だというのは、今日のテクノロジーの力への声明ではありますが、B2Bの営業トークではなく魅力的な技術記事を求めている私たちにとっては、悲しいシグナルです。

著者がSQLiteのバグを捕まえる機会を逃したと感じているのは理解できますが、それでもこれは後知恵で何かを捕まえたように感じられます。SQLiteの並行処理エンジンにバグがあると知っているだけでも大きな勝利です。

しかし、Tailscaleのブログ記事を読んでも、「本番で見ているこの問題」から「これをAntithesisに読み込ませる」へとどう結びつければよいのか、私にはわかりません。バグがSQLiteにあるのか、Tailscaleにあるのか、Linuxにあるのかを特定するのが戦いの半分だったように思えます。そのような状況で、Antithesisにすべてのコンテキストを与えたとしても、それが確実にバグを見つけられるのでしょうか？

問題を特定してテストスイートを書くためにAIに与えたプロンプトを見つけようとクリックして回りました。

見つけられなかったので、プロンプトが完全に「テストスイートを作って」というものだったのか、それとも最初からバグ発見へと導くものだったのかは不明で、それでは公平なテストにはなりません。

私が見つけたプロンプトへの言及で最も近いものはこれでした：

> それから、WALの挿入とチェックポイントのコードを実行する単純なワークロードを書くように頼みました。これは完全に一般的なワークロードです。

懐疑的な目で見ると、不明瞭です。

私たちは奇妙なP=NP時代にいるように感じます。誰かが問題を見つけた後、誰かが同じ問題を見つけるより安価な方法を指摘しますが、それは必然的に、問題がそこにあることとそのおおよその位置を知っていることを前提としています。