How I'd Run Bug Triage on 40 Defect Reports Before a Release: Lessons From Postgres 19

TL;DR

• On October 9th, Peter Eisentraut, a PostgreSQL core team member and committer, wrote that about 8 to 10 significant features had been reverted from Postgres 19.
• Part of the reason for the Postgres 19 reverts was bug triage math: LLM-assisted review found a long tail of real edge-case defects, and each one carried fixed overhead.
• The twist: most of the reverted Postgres 19 code was written before AI review got this good, so the quality bar went up after the code was committed.
• On October 10th, the PostgreSQL release team moved Postgres 19 general availability (GA) to November 19. Tomas Vondra, a PostgreSQL major contributor, argues that most reverts came from human review that happened late.
• My plan for 40 real defect reports and a release date: cluster them, score blast radius, split must-fix from follow-up, do the hours math, then move review earlier.

What Happened to Postgres 19, and Where AI Code Review Fits

When Peter Eisentraut, a PostgreSQL core team member, posted about the Postgres 19 reverts on Friday, October 9th, I read it twice and then opened a notes file. I wasn't thinking about Postgres internals. I was thinking about every release meeting I've sat in where a list of bugs landed two weeks before ship.

The release decision is the part of the Postgres 19 story I care about. A mature project with excellent reviewers got a pile of real defect reports late in the cycle, and had to decide what ships. Your team will face the same decision, probably sooner than you'd like.

Why the Postgres 19 Reverts Happened

Peter Eisentraut, a PostgreSQL core team member who committed some of the reverted features, laid out several causes in his October 9th post. Four of them matter for bug triage:

• Architectural defects. Some Postgres 19 features had "significant architectural defects that would have been hard to fix quickly and during beta."
• A long tail of edge cases. Other Postgres 19 features had "a long tail of relatively harmless issues" in edge cases. Peter Eisentraut wrote that with LLM-assisted code review, "you're staring at a list of like forty defect reports. And even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time."
• A raised quality bar. Peter Eisentraut wrote that the reverted features "were written a long time ago when LLM-assisted code review was not as useful as it is now, meaning that the effective quality bar has been raised after the time the feature was written and committed." He was clear that this "is not due to 'vibe coding'."
• Security load. In Peter Eisentraut's account, many senior PostgreSQL developers spent April to August on security fixes, so beta-period review and testing dropped and only picked up again in August. The gap pushed a lot of discoveries late.

The Counterpoint: Most Reverts Came From Human Review

Tomas Vondra, a PostgreSQL major contributor, published a revert-by-revert analysis on October 1st, Are we reverting patches because of bugs found by AI?. His analysis has three findings that matter for bug triage:

• Count. Of the 12 Postgres 19 reverts Tomas Vondra looked at, "only 4 came out at 'probably AI' or 'AI'." The rest came from regular human review.
• Timing, the finding that matters most for bug triage. The number of Postgres 19 reverts looked normal compared with earlier releases, but the timing didn't. PostgreSQL reverts usually cluster right after feature freeze. For Postgres 19 they flatlined, then spiked in early September.
• Cause. Tomas Vondra links the late spike to security load. He counts about 5 PostgreSQL CVEs (Common Vulnerabilities and Exposures) last year and 44 so far this year, some reported with AI help. The same senior developers handle both security fixes and feature review.

I won't tell you "AI delayed Postgres 19." The fair version: AI-assisted review added real defects to a Postgres 19 review cycle that was already running late, and every report cost time to process.

The New Postgres 19 Release Date

On October 10th, Jonathan Katz, a PostgreSQL core team member, posted for the release team that Postgres 19 GA would move to November 19. He gave the reason as "the volume of fixes that have been added to the back branches," which the team wanted in a second release candidate on November 12.

The Postgres 19 release timeline at a glance:

• October 9th: Peter Eisentraut posts about the reverts.
• October 10th: the PostgreSQL release team moves GA to November 19.
• October 15th: Postgres 19 Release Candidate 1 (RC1) ships.
• October 16th: The Register's write-up by reporter Lindsay Clark says Postgres 19 was once slated for late September or early October, and that the reverted features will likely land in Postgres 20.
• November 12th: planned second release candidate (RC2).
• November 19th: planned GA.

Why 40 Small Defect Reports Turn Into a Bug Triage Problem

AI code review changes when defects arrive and how many arrive at once. The table compares defects users find over years of releases with defects AI review finds right before one.

Peter Eisentraut, a PostgreSQL core team member, wrote that edge-case defects used to surface after release, and the project "would have fixed them bit by bit over the subsequent five years." With AI-assisted review, many of those findings now land in the weeks before a release.

The defect timeline shows one set of defect reports drawn twice. On the top row, defects found by users trickle in across years of minor releases. On the bottom row, defects found by AI review bunch up right before general availability (GA), where the fixed overhead per report starts to hurt.

How I'd Run Bug Triage on 40 Defect Reports Before a Release Date

Say it's my feature, and AI review just handed me 40 defect reports. They're real defects, not noise, and I have a few weeks before the release date. Here's how I'd spend the first afternoon of bug triage.

1. Cluster the Reports by Feature and Root Cause

I'd start by merging duplicates and grouping by root cause. Forty reports rarely mean forty problems. Ten of them might be one missing check that shows up in ten code paths.

Clustering defect reports is how you pay the fixed per-report overhead (reproduce, test, review, commit) fewer times. One owner, one branch, one round of tests and one commit series per cluster beats 40 separate threads.

2. Score Each Cluster by Blast Radius

Blast radius is how far a defect reaches if it ships. I'd rank clusters by what they can damage, not by how many reports they contain or how big the fix looks.

Blast Radius Signals for a Database Feature

• Wrong query results with no error
• Data loss or corruption on disk
• Security and permission checks skipped
• Crashes or hangs in the server
• Behavior you can't change after release without breaking users
• Odd combinations of features, such as Peter Eisentraut's example of a domain over a composite type inside a partition inside a view

Odd feature combinations are where LLM-assisted review shines. Writing about cases like a domain over a composite type inside a partition inside a view, Peter Eisentraut, a PostgreSQL core team member, said "no one can manually test this or even enumerate these test cases," but LLM-assisted fuzzing "can find problems with this really quickly."

Qodo's code quality report shows edge cases are a real pain point in review too. In the August 2026 survey of 500 U.S. developers at organizations already using AI meaningfully in the software development lifecycle, 21.8% named hidden bugs or edge cases as their greatest challenge when reviewing AI-generated code. Edge cases are hard for people, so reports about them deserve a real look.

3. Separate Severity vs Priority

Severity is how bad a defect is. Priority is how soon you fix it. Keep them as two separate fields, because a deadline changes priority without changing severity.

A severe bug in a feature you can revert might get low priority for this release, because the fix is "revert." A mild bug in an on-disk format gets high priority, because you can't patch it later without pain.

Tom Lane, a PostgreSQL core team member, captured the priority question in a remark The Register quoted about SQL Property Graph Queries (SQL/PGQ):

"At this point I'd be willing to bet dinner that if we ship it in v19 there will be post-release bug discoveries that are unfixable until v20."

Whether you can fix a defect after release is what decides its priority.

4. Split Must-Fix From Follow-Up

My bug triage table sorts defect reports into five buckets: must-fix, fix if cheap, follow-up, design call and close. The Postgres 19 examples come from the PostgreSQL 19 Open Items wiki page and Tomas Vondra's analysis. The buckets are my own call, not the project's.

Design-call defects, the ones that point at a design flaw, are where Postgres 19 had no good option. Peter Eisentraut, a PostgreSQL core team member, wrote that the PostgreSQL community has discussed committing features with an "experimental" status, but hasn't "figured out a way to do this" yet. If your project has feature flags or preview labels, design-call defects are what they're for.

The bug triage decision tree turns the five buckets into four questions in order: can it corrupt or leak data, can we fix it after release, is the fix small, and does it point at the design? The "long tail of relatively harmless issues" Peter Eisentraut described would mostly exit at the third question.

5. Do the Hours Math Before Anyone Starts Fixing

Once every cluster of defect reports has a bucket, I'd do the hours math out loud in the triage meeting. My rough numbers per report:

• The fix: about 20 minutes for a three-line change.
• The overhead: about two more hours to reproduce it, write a test, get review and commit.
• The total: at about two hours and 20 minutes per report, 40 defect reports cost about 90 hours.

If two people have three weeks of part-time attention, 90 hours is tight but doable for must-fix and fix-if-cheap. If the must-fix list includes a design flaw, the math says revert. Better to say it in week one than in week three.

6. Move Review Earlier So the List Doesn't Land at the End

The real fix for a late pile of defect reports is upstream. The revert chart from Tomas Vondra, a PostgreSQL major contributor, shows the Postgres 19 problem was timing: the review happened, it just happened late. One defect costs very different amounts at two points in the cycle:

• Found before commit: one person, a few minutes.
• Found in beta: a thread, a reviewer and a release slot.

Catching defects before commit is the whole argument for shift-left code review: run review on the diff while the author still has context. Peter Eisentraut, a PostgreSQL core team member, reached a similar conclusion for Postgres, writing that LLM-assisted fuzzing "probably needs to be part of feature development in the future."

Liz Fong-Jones, Technical Fellow at Honeycomb, described moving review earlier on The Agentic Review podcast in September. Her team is doing "peer reviews sooner, doing peer reviews more often at the design stage." People review the design. Machines catch the off-by-one.

A Short Bug Triage Workflow for AI Review Findings

Here's the seven-step bug triage workflow I'd pin in the team channel. It fits in one afternoon for 40 AI review defect reports.

1. Collect. Put every finding in one tracker view with one label, for example ai-review.
2. Cluster. Merge duplicates and group by feature and root cause.
3. Score. Give each cluster a blast radius (Large, Medium, Small) and a yes or no for "fixable after release."
4. Bucket. Sort clusters into must-fix, fix if cheap, follow-up, design call or close.
5. Do the math. Hours needed for must-fix plus fix-if-cheap, against hours left. If it doesn't fit, cut or revert now.
6. Assign. One owner per cluster, one fix series per cluster.
7. Feed it back. For every must-fix, write down which earlier check would have caught it, and add that check before the next freeze.

If your AI review findings live in GitHub issues, this GitHub CLI command pulls every open ai-review issue into a file you can sort:

gh issue list --label "ai-review" --state open --limit 200 \
  --json number,title,labels,createdAt > triage.json

Step 7, feeding each must-fix back into an earlier check, is the one teams skip. It's also the only step that makes next release's list of defect reports shorter. Our code review best practices guide has more on picking where review depth goes.

The loop diagram shows the seven bug triage steps as a cycle, not a line. The arrow from "feed it back" returns to the start of the next release, which is how the list of defect reports shrinks over time.

Where Qodo Fits in Bug Triage for AI Review Findings

With AI code review, catching bugs isn't the hard part anymore. Postgres 19 had plenty of real findings. The hard part was ranking them by impact and deciding what ships, with the same few senior people doing all of it.

Ranking review findings by impact is the problem we build for at Qodo. Qodo PR Triage ranks open pull requests with priority rules that combine high-severity review findings with blast radius:

• Medium blast radius means a change reaches another repository rated Critical or High.
• Large blast radius means a change reaches several repositories or blocks other PRs.

Qodo's Software Map shows downstream dependents and tracks each finding as fixed before merge, dismissed or shipped unfixed, which matches the must-fix versus follow-up split in my bug triage table.

Itamar Friedman, co-founder and CEO of Qodo, called out blast radius estimation on the September episode of The Agentic Review with Liz Fong-Jones: "maybe estimate what is the blast radius of a change, like, try to estimate a severity. I almost feel like it's an underrated killer feature of AI."

Conclusion: Bug Triage Is the Bottleneck Now

Postgres 19 is a good release story to learn from because the defects were real and the people were excellent. AI-assisted review raised the bar on code that was written before the bar moved, and review that ran late left little time to clear the list.

When you get your own 40 reports, cluster them, rank by blast radius, split severity from priority and do the hours math early. Then move review to where the author still has context, so the next list is shorter.

How does your team triage a pile of AI review findings before a release? I'd love to hear in the comments.

FAQ About Bug Triage and AI Code Review

What is bug triage?

Bug triage is the process of deciding what happens to each defect report: fix now, fix later, redesign or close. You check that the report is real, group duplicates, rate severity and priority, and assign an owner. Qodo adds blast radius and review findings to each pull request, so triage starts from impact.

Why was Postgres 19 delayed?

Postgres 19 was delayed after 8 to 10 significant features were reverted late in beta, and on October 10th the release team moved GA to November 19 to include more back-branch fixes. Peter Eisentraut, a PostgreSQL core team member, points partly to LLM-assisted review finding a long tail of edge-case defects. Tomas Vondra, a PostgreSQL major contributor, found that most reverts came from human review, much of it late.

Could AI code review findings create another triage bottleneck?

AI code review findings can create a triage bottleneck when they arrive in bulk near a deadline, because each report has fixed processing overhead. Clustering by root cause and ranking by blast radius keeps the overhead under control. Qodo PR Triage combines high-severity findings with blast radius and SLA (service level agreement) rules, so reviewers see the risky changes first.

How do we manage human review capacity when code output grows?

Manage human review capacity by spending people on design and high blast radius changes, and letting automated review handle routine defects. Liz Fong-Jones, Technical Fellow at Honeycomb, said on The Agentic Review that treating everything as important means "nothing is important." Qodo runs review on every pull request and ranks the queue, so human attention goes where impact is highest.

What is the difference between severity vs priority in bug triage?

Severity vs priority in bug triage comes down to impact versus timing. Severity measures how bad a defect is, while priority measures how soon you'll fix it. A deadline can lower the priority of a severe bug in a feature you plan to revert. Qodo's blast radius labels give you a consistent severity signal across pull requests.

What else should we test after a change that AI review flags?

After AI review flags a change, test the downstream code that depends on it, beyond the changed component. List the services, schemas and contracts the change touches, then pick tests for each. Qodo's Software Map shows downstream dependents and service contracts across repositories, so you can scope those tests.