Hi, itâs Carl again. You may remember me as the guy who taught Claude to use Antithesis.

Earlier this year, SQLite released (3.51.3), which fixed a longstanding bug in their Write-Ahead Logging (WAL) subsystem called the WAL-Reset bug. The bug had been hanging around since 2010, but the SQLite team had apparently been unaware of its existence until earlier this year (more on this below). As they wrote at the time:

âThe bug is a data race with tight timing constraints. It is unlikely to occur in common use. The developers have never been able to reproduce the bug organically and had to add special testing logic to SQLite that deliberately triggers the circumstances of the bug in order to verify that the issue has been fixed.â

I was actually on a road trip with my girlfriend when I read about this, but Iâm also a giant database nerd, so I was immediately nerd-sniped, hard. Bugs in SQLite, after all, are legendarily rare. Moreover, this sounded like just a perfect brown M&M: a known, challenging bug that we could track down with Antithesis (weâve done this a lot in our POCs). On top of that, Iâd recently shipped our skills for Claude.

So, sitting on a hillside on the Sunshine Coast, I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 â still buggy â set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see the instrumented version here.

Shoutout here to my incomparably beautiful home province of British Columbia.

Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently â things youâd expect to actually happen in production, all the time. The assertions are also generic to the bug, theyâre all standard assertions youâd add to any database, things like âno lost committed writesâ and âdatabase is not corruptâ (called integrity check in sqlite).

On my first run, Antithesis caught the bug in 15 mins. Hereâs the report. The part youâre looking for is:

Then I repeated the exercise with 3.51.3, with the same workload and Antithesis instrumentation. Sure enough, the run came back green.

I thought about this today because Tailscale just wrote an excellent blog post about resolving the uptime issues theyâd experienced in 2025. Those issues were how the SQLite team discovered the WAL-Reset bug. Tailscale suffered 6 months of shaky uptime, then they and the SQLite team spent weeks hunting the bug, rolled out and rolled back a fix that broke something else, then had to wait two more months to see if the ârealâ fix (3.51.3) worked.

To root cause the issue, they had to write a new transaction logging pipeline in Tailscale, then shim in a new debugging tool for the virtual filesystem layer in SQLite. In Antithesis, this process isnât quite down to a single click, but one click will give you a causality analysis that pinpoints the issue to within a fraction of a second, and deterministic, time-travel debugging that allows you to do what-ifs and destructive analysis.

As the Tailscale team wrote, ânobody wanted us to spend six months looking for bugs in SQLite. This was an immensely frustrating experience for both our customers and staffâ.

Finding bugs like the WAL-Reset bug is excruciatingly difficult (perhaps even like crawling over broken glass) â but with rare and difficult bugs, the real torture can come when youâre waiting to see if your fix actually worked. Iâve worked on enough databases, and have experienced this myself many, many times.

So it was both sobering and uplifting to realize just how painful this bug had been in the wild. By giving agents the skills to use Antithesis, Iâd just found and verified it in like an hour, from my phone, sitting under spruce trees in the sunshine. I knew our agent skills worked, but I had no idea they worked this well. If you have a gnarly database issue, call me.