The best way to handle a flood of AI-found bugs is to run the same bug hunt on your own pull requests before merge, with a human reviewing every fix. Triage and feature freezes help, but they only react to reports that already exist.
In Postgres 19 is late, and it’s AI’s fault, Robert Haas explains why the release slipped past its usual window. Here are three levels for handling the same problem in your codebase, and what each costs.
Table of Contents
- What happened to Postgres 19
- Good: triage reports with a cut-off
- Better: pause feature work until the backlog shrinks
- Best: hunt bugs before merge
- Which level fits your team
- The case for slowing down
- FAQ
- Sources
What happened to Postgres 19
Postgres major releases usually ship between mid-September and mid-October. Haas says version 19 likely won’t ship until November, and could slip further.
His numbers, comparing April 8 to September 25 in 2025 and 2026:
| Branch | 2025 | 2026 | Change |
|---|---|---|---|
| Release branch (18, then 19) | 724 commits | 1169 commits | +61% |
| Previous release (17, then 18) | 248 commits | 433 commits | +74% |
Those are back-patched fixes. Haas attributes the jump to people reporting bugs they found with LLMs. Three large features were also reverted between August 27 and September 15, including SQL/PGQ.
Finding bugs got much easier. Fixing them didn’t. Haas notes that LLM-drafted fixes “aren’t always correct or compliant with PostgreSQL standards”, so humans still review and commit each one.
The scale is real. One developer in the discussion spent part of a summer bug-hunting Postgres with AI help. They found serialization anomalies, foreign key integrity issues and planner bugs, and could only report a dozen or two out of hundreds of candidates.
Good: triage reports with a cut-off
Rank every report by severity and set a line. Fix what’s above it and park the rest. One developer in the discussion called this what the average product company would do.
- Costs: little. You already have a bug tracker.
- Misses: niche bugs stay open forever. A reply pointed out that databases have traditionally kept a “zero bugs” mindset, so this doesn’t fit every product.
Better: pause feature work until the backlog shrinks
Stop shipping features and put the whole team on the backlog. One developer said their company did exactly that, because the security tasks had become “staggering and urgent”.
This is step 5 of the old Joel Test, another commenter noted: fix bugs before writing new code.
- Costs: the roadmap stalls while you catch up.
- Misses: it doesn’t slow the inflow. New reports keep arriving while you fix the old ones.
Best: hunt bugs before merge
Run the AI bug hunt on every pull request, before it merges, so fewer bugs reach a release at all. Pair it with stricter tooling. The top comment described a 1.5M-line system where the team fixed thousands of bugs in a year and set the compiler to treat warnings as errors.
Haas makes the same point from the other side: every feature written from now on “will be scrutinized by AI”. Better it’s your AI, before the release, than a stranger’s after it.
- Costs: CI time and reviewer hours. One developer argued that discovery is no longer the bottleneck; verification is.
- Misses: old code. A pre-merge check only sees new changes, so run a one-off hunt on your riskiest modules too.
Tools that fit here: static analysis like CodeQL or Semgrep in CI, plus an AI reviewer on each pull request. For the human side, see this checklist for reviewing AI-generated pull requests.
Which level fits your team
| Situation | Level | Why |
|---|---|---|
| Small backlog, low-risk product | Good | Triage is enough |
| Security reports piling up | Better | Urgent fixes come first |
| Active codebase with regular releases | Best | Stops bugs at the source |
| Old codebase, few maintainers | Best plus a one-off audit | Pre-merge checks miss old code |
The case for slowing down
Not everyone thinks the delay is a problem. Haas himself calls it not “particularly concerning”, since it comes from the project’s concern for quality.
A pushback in the discussion asked how many of these bugs only became risky because attackers have LLMs too. The answer from another developer: that’s exactly why they can’t be dismissed as too hard to exploit anymore. Others suggested shorter release cycles; a reply doubted Postgres could feature-flag its way to continuous delivery. My take: a late release that ships fewer bugs is the right trade for a database.
FAQ
Why is PostgreSQL 19 late?
Robert Haas says LLM-assisted bug reports flooded the project. Back-patched commits rose 61% year over year, and reviewing fixes took time away from release work. Three large features were reverted late in beta.
Are AI-found bugs real bugs?
Many are. One developer found serialization anomalies, foreign key issues and planner bugs in Postgres. Reports still need triage, since AI tools also produce false candidates.
Can AI fix the bugs it finds?
It can draft fixes. Haas notes those drafts aren’t always correct or up to project standards, so a human still reviews each one.
How do I keep up with AI-generated bug reports?
Triage by severity first. If security work piles up, pause features. Long term, run the same AI bug hunt on pull requests before merge.
Should I run AI bug hunting on my own code?
Yes, before someone else does. Start with your riskiest modules and add a check to every pull request.
Does this only affect open source projects?
No. One commenter asked what this means for the average product, and another answered that it’s usually worse.
Sources
- Article: Postgres 19 is late, and it’s AI’s fault by Robert Haas, also published on the Neon blog.
- Discussion: https://news.ycombinator.com/item?id=50312408, for the bug-hunting results, the triage and feature-freeze approaches, the verification bottleneck and the release-cadence debate.
- Related: Reviewing AI-generated pull requests: a staff engineer’s checklist.