Simon Willison noted this week that SQLite continues to maintain a policy that is unusual in modern open source: the project does not accept code contributions generated by AI agents. The policy has been in place quietly for some time, and it is worth examining carefully rather than reacting to. Whether or not you agree with it, the reasoning behind it is one of the clearest articulations of a quality-engineering position in current open source, and it raises questions that every project that takes contributions will eventually have to answer.
To understand the policy, it helps to understand what SQLite is and how it is tested, because the standards involved are not typical.
SQLite is the most widely deployed database engine in the world. It ships inside every iPhone, every Android device, every major web browser, most aircraft avionics systems, and a large number of medical devices. Its test suite is one of the most thorough in software. The project maintains 100 percent branch coverage and 100 percent MC/DC (Modified Condition/Decision Coverage), the latter being the level of test rigor required by DO-178B for safety-critical aviation software. SQLite is fuzzed continuously across multiple harnesses, and its release process includes manual review steps that most projects abandoned a decade ago.
This context matters because it determines what kinds of code-quality risks the project is willing to take on. A project with weaker test discipline can absorb a wider variety of contributions, because regressions will surface in production and can be patched. SQLite operates closer to the safety-critical end of the spectrum, where regressions can be expensive in human as well as engineering terms, and where the cost of reviewing a subtle bug late is much higher than the cost of preventing it from entering the tree.
The specific concern with AI-generated contributions, as articulated by the SQLite maintainers, is the failure mode of being almost right. An agent can produce code that compiles, passes the test suite that ships with the patch, and looks reasonable to a reviewer, while still containing a defect that requires deep familiarity with the project to spot. For most software, the cost of catching such a defect later is small. For SQLite, the cost of catching it later may mean a silent data corruption bug in a database that holds patient records or flight telemetry. The maintainers have decided that the throughput gain from AI contributions does not justify the additional review burden required to maintain their quality bar in the presence of those contributions.
It is worth being precise about what the policy is and is not. It is not a statement that AI-generated code is always bad, or that the maintainers think the technology lacks value. It is a project-level decision that, given the specific quality standards SQLite enforces, the cost-benefit calculation does not work out in favor of accepting agent-written patches. Other projects will reach different conclusions because they operate under different constraints.
The broader observation is that as more development tooling integrates AI assistance, the question of how to handle agent provenance in a code-review workflow is going to come up in every project that takes contributions. Different projects will land in different places. Some will require explicit labeling of AI-assisted patches. Some will require human attestation. Some, like SQLite, will declare a complete ban. Some will treat the distinction as irrelevant. The interesting work for the open-source community in the next year or two will be in articulating these positions clearly enough that contributors know what to expect when they file a pull request.
For people building tools that produce code contributions — IDE assistants, agent frameworks, autonomous PR bots — the SQLite policy is useful information regardless of whether your code will ever try to contribute to SQLite. It tells you that the strictest projects in open source are starting to ask explicit questions about provenance, and that tools which make provenance easy to track and easy to attest will be more useful to a broader range of contributors than tools that obscure it. Project metadata, commit trailers, and signed attestations of human review are likely to become more important as more projects adopt explicit policies in this area.
The right way to read the SQLite policy is not as a verdict on AI-assisted software development, but as an honest articulation of one set of trade-offs at one quality tier. The maintainers are doing the open-source community a favor by being explicit about their reasoning. It is the kind of position paper that other projects can use as a reference point when they think through their own.