This spring, open source maintainers across the internet started noticing the same strange thing at the same time: a flood of bug reports that no human had written. Not spam. Not malicious. Just confidently wrong, at a scale nobody had planned for. D. Richard Hipp, the creator of SQLite, watched it happen to his own project and lived to describe it calmly, a few months later, from his home office in Charlotte.
"This spring, late spring into summer, there was just an avalanche of bug reports that were generated by AIs," Hipp said. "And it's not just us. Every open source project I've talked to has experienced the same thing."
That's worth sitting with for a second, because SQLite isn't a side project. It's the database engine sitting inside your phone, your browser, and most of the apps on both. Hipp built it in 2000 as a Navy contractor, frustrated that he kept getting blamed for outages caused by a database administrator's server, not his code. His fix was to get rid of the server entirely. "You don't want to have to install Postgres in order to run Firefox," he said. Twenty-six years later, that decision is why SQLite runs on something like a trillion devices without anyone thinking about it.
So when the AI bug reports hit, they hit hard, and some of them were real. Most, Hipp said, landed on obscure, untested files that had been sitting in the source tree for years, never meant to ship. A few were serious. What surprised him wasn't the volume. It was how fast it stopped. "It's as if the AIs have discovered all the bugs they're able to discover, and we're through that," he said. "I'm pleasantly surprised that this went away so quickly." Compare that to the profile-guided fuzzing wave a decade ago, which took years to work through. This one burned out in a few months. Hipp isn't declaring victory for AI or against it — he compares it to security conferences like Black Hat, where the same tools that help attackers eventually help defenders more. "That's been true of what we've done for the last 100 years," he said.
Here's the part that should get developers' attention: Hipp isn't avoiding AI. He's using it, carefully, in exactly one place. "I run all the new patches through Claude now," he said. "Claude does code review — it doesn't write any code for it." It catches real logic problems and the small stuff, like a comment nobody updated. That's a meaningful admission from someone who has kept SQLite's core team at five committers — two of whom do nearly all the work — while Postgres runs on 40-plus contributors and DuckDB reportedly staffs 24 people in Amsterdam alone. Hipp says that's only possible because of SQLite's 100% branch test coverage, built by hand over roughly a year of 80-hour weeks. The rigor is what lets two people move fast without breaking things. AI review adds a second set of eyes on top of that, not instead of it.
What AI still doesn't get is a seat writing SQLite's core. "I've tried that, and what I've seen is that the AI-generated code is not up to snuff," Hipp said, then immediately qualified it: "I've noticed even just over the past year that it's getting better. My opinion could possibly change." Right now, though, the answer is no. It's all human-written.
That same restraint shows up in how Hipp treats the ecosystem building on top of him. Forks like libSQL and platforms like Turso and Cloudflare D1 add concurrent writes, replication, and edge distribution — features SQLite deliberately doesn't ship. Hipp isn't threatened by it. "I'm fine with someone else filling it," he said. "It's public domain. You can do that. Do what makes you happy." He's also seen the pattern before: "They tend to be venture capital backed, which means we've seen a lot of them come and go. Mostly gone." He built SQLite for local, embedded state in 2000 for reasons that had nothing to do with AI agents. That it turned out to be exactly what 2026's edge and agent workloads need is a convergence he didn't predict — he's on record dismissing large language models entirely back in the 1980s, for lack of data and compute. "Boy, was I wrong," he said, without much drama about it.
For developers deciding when SQLite is the right call, Hipp's rule is simpler than most decision trees: keep the database and the data on the same device. If your data lives somewhere else, or you're past roughly 17 terabytes, or you need many applications hammering writes at once, reach for a client-server database instead. And if you're already using SQLite, don't just dump JSON into it and call it a day — he sees too many developers treating it like a document store when the relational model would serve them better.
Hipp has pledged to keep maintaining SQLite through 2050. He's about halfway there. What he said about why matters more than the date: thinking in decades instead of toward a release, an IPO, or a VC's milestone "changes the way you code." He's also honest about the one thing that could end the project entirely — not a rival database, but AI good enough to rewrite SQLite from scratch, smaller and faster, with fewer bugs. "We're not there yet," he said. "But that might happen. And when that happens, fine. I'm done."
That's not resignation. It's the same stubbornness that built the thing in the first place, applied one more time to whatever comes next.
