The bug queue needs provenance

SQLite 3.53.4 has one of the stranger patch notes I have read this year: its fixes came mostly from AIs. A little earlier, Richard Hipp had moved machine-generated bug reports out of SQLite's user forum because the flood was making that forum miserable to use. The same project was fixing the reports and asking them to leave the room.

If your agent can spend all night inventing queries, following branches, generating inputs, and poking every extension, you have changed the economics of bug finding. Suspected defects can scale with compute. Reproduction, classification, discussion, and the decision about whether anybody should care still land on maintainers, whose day stubbornly remains twenty-four hours long.

The avalanche shipped patches#

SQLite's public record keeps both sides of this story visible. The useful sequence is short, and it happened fast enough that the project changed its community plumbing before the patch series was over.

The sequence blocks the easy dismissal. Machine reports were useful enough to keep changing shipped code, then SQLite's own news log started describing diminishing returns. Both effects happened in the same patch series: fixes landed while the community space around them needed protection.

SQLite's Bug Forum about page says the separate forum exists so ordinary users do not have to wade through a stream of insignificant and corner-case reports. Good grief: the testing tool worked well enough that the inbox needed a new architecture. The second queue records that success without forcing every user to watch it scroll by.

A reproducer has an origin#

The cleanest example of why provenance matters came from the human forum on May 4. Josh Leahy reported a query-optimizer failure from real-world use and disclosed that an LLM helped minimize the issue and bisect the regression. The model did useful reduction work after the application had already supplied the reason to care.

A tidy SQL fixture can still carry a bad diagnosis. In another report later that month, Dan Kennedy concluded that the supposedly inconsistent query was ambiguous and that SQLite's different results were all permitted. Both reports can look impressively reduced by the time a maintainer opens them. Only one arrived with a real workload behind it.

So I want a bug report to carry more than the final reproducer. Tell the tracker how the issue was discovered, whether a supported application actually hit it, and which parts were produced or reduced by a machine. An issue form can make this boring with fields such as discovered_by, affected_surface, reproducer, and impact. Those fields give a high-volume queue something useful to sort on.

Route by discovery mode#

SQLite's split is wonderfully blunt. Its user-forum rules send AI agents, fuzzers, static analyzers, and similar machine-assisted discovery to the Bug Forum, while problems encountered during actual use can stay in the conversational forum. The classification describes where the report came from before anyone argues about severity.

I would copy that distinction even if I kept one tracker. A machine-discovered label can have different subscription defaults, stronger duplicate checks, automatic clustering, and a bulk-triage view without making the report second-class. Calling the second queue a trash can misses the evidence in SQLite's own release history: maintainers were clearly reading it and fixing things from it.

There is also a social boundary worth protecting. A user forum teaches people how the software behaves through explanations and examples drawn from ordinary programs. Flood it with synthetic edge cases and the archive changes character, even when every individual post is technically legitimate. The machine queue can remain valuable without making every subscriber watch it scroll by.

Make the cheap side do the reduction#

Once a model found the suspected bug, let it spend more of the cheap tokens before a person spends attention. Have it rerun current trunk, shrink the reproducer, search existing reports, identify the supported surface it touches, and state expected versus actual behavior. SQLite's forum FAQ already says reproducible reports tend to get prompt attention while vague ones rarely do. An automated reporter has even less excuse to arrive vague.

I cannot tell from the public pages how much machine triage still arrives through Richard Hipp's private email, which the project explicitly continues to accept. The public architecture is visible, though. It treats discovery as provenance that changes routing, then lets the reproducer and impact determine what happens next.

The July 24 news log wondered whether the AI-bug avalanche might be ending. Maybe it is. The site still has two public inboxes where one used to be: sqlite.org/forum and sqlite.org/bugs. The bugs did not disappear when the queue split; they got an address that no longer had to be everybody else's inbox.