Key Takeaways

  • Fewer than 100 people contribute directly to core Postgres development, and closer to 50 hold an actual commit bit.
  • LLMs generate plausible C code that easily masks race conditions, memory safety bugs, and data corruption risks.
  • Web models ingest massive corpora of Python and JavaScript, while clean, public, production-grade C code remains rare in training sets.
  • Reviewing low-effort AI contributions costs senior maintainers hours of triage for code that took seconds to generate.

The Asymmetric Cost of Fifty Committers

Postgres runs a massive share of production applications, but the team maintaining its engine is small. Craig Kerstiens points out that fewer than 100 people contribute core code, with “closer to actually 50 people of committers that have a commit bit to Postgres.” Those fifty engineers manage the patch pipeline, review memory allocations, and guarantee that writes hit disk safely.

When automated tools lower the friction of creating code to zero, pull request volumes spike. The math breaks quickly. An inexperienced contributor can prompt an LLM to generate ten patches across ten repositories in five minutes. Vetting those patches falls on a handful of maintainers who must read every diff line by line. As Kerstiens observed, “Now, they're overwhelmed with PRs they've got to kind of sort through, right?” Triage becomes an unpaid defense job against automated noise.

Why Hallucinated C Code Corrupts Data

Generating database internals is entirely different from building web frontends. If a model generates a React component with a bad CSS class, the interface looks slightly off. If an LLM hallucinates pointer math or mismanages a transaction boundary in Postgres, silent data corruption follows.

Kerstiens highlights the stark divide in risk: “Cuz, you know, on a UI, on a button misplace, it's one thing. Very different than uh-oh, I corrupted my data, right?”

The technical problem traces back to model training data. Large language models train on vast amounts of public JavaScript, HTML, and Python. High-integrity, low-level systems code written in C is scarce by comparison. As Kerstiens noted, “I don't think it's the same for C code, right? Because the models aren't trained on so the amount of code out there, right? That the more code they can learn from, the better. Like, there's not a lot of, like, open source, public C code that exists as a great model, right?” Because the underlying models lack adequate high-grade C training data, they produce code that compiles cleanly but fails catastrophically under concurrent database loads. Senior maintainers cannot skim these pull requests; they must audit them with extreme scrutiny.

Defending Maintainers from Cheap Submissions

Open source projects were built around an implicit trust assumption: human effort was required to write code, which acted as a natural spam filter. AI removes that filter entirely. Maintainers now face dozens of polite, cleanly formatted submissions that deliver broken logic underneath. Kerstiens stated: “I have sympathy for the maintainers, though, of the influx of, like, new PRs coming in that they've got to manage and diffuse.”

When software guards user records, financial ledgers, and audit logs, a maintainer cannot gamble on plausible-looking diffs. A single bad merge damages decades of reliability. If open source communities fail to establish strict boundaries against unverified AI patches, the small pool of engineers keeping core infrastructure alive will simply stop reviewing outside work.

What to Do With This

Add a mandatory reproduction requirement to your repository this week. Require every contributor submitting a pull request to include a failing test case that passes with their patch, plus a written explanation of how they verified memory behavior locally. If a submission appears machine-generated without local test evidence, close it immediately without debate.