AI review on old code: lessons from PostgreSQL 19

PostgreSQL 19 has reverted eight to ten significant features since its beta period began. Committer Peter Eisentraut wrote on 9 October that part of the reason is AI-assisted code review, which finds bugs far faster than before, including in code written years ago. Are you about to run that kind of review on your own older code? My advice is to set aside time for the list it produces, and to sort that list before anyone starts fixing.

What happened at PostgreSQL

One revert per release cycle is normal for PostgreSQL. This time, Eisentraut counts eight to ten significant features, some of them late in the beta. He was the developer or committer of a few himself.

He names several causes. Some features had architectural defects that could not be fixed quickly during the beta. On top of that came a long tail of smaller edge-case issues. In the past, such bugs surfaced over the years after a release and got fixed one by one. With AI-assisted review they turn up in a short time, and then, as he puts it, you are staring at a list of something like forty defect reports.

Each report takes time, even when the average fix is only three lines. That overhead is what used up the schedule.

The bar went up after the code was written

Eisentraut points out that the reverted features were written when AI review was not yet this useful. He does not blame vibe coding: the code existed before that was possible. The quality bar rose after the code was written and committed.

At the same time, many senior developers spent April to August on security fixes, a wave he calls the Vulnpocalypse. The usual extra review and testing during the beta waited until August. The community chose to keep the release date rather than wait for more fixes.

That applies to any codebase that has been running for a few years. The code works, the tests pass and nobody has looked at it critically for a while. Point an AI review tool at it and you get what the PostgreSQL team got: many findings at once, most of them small.

How I would start

Treat a first AI review of old code as a project of its own, with its own time, rather than something squeezed into a sprint. A few steps:

1. Start with the parts where a bug costs the most: payments, permissions, anything that touches personal data.
2. Let the tool produce a list and fix nothing yet. Sort the findings by severity and by the part of the code they sit in.
3. Read the findings per module together. Ten findings in the same module often point to a design flaw, and ten separate fixes will not solve that.
4. Agree which findings you deliberately leave, and write down why.

The third step is the most important one. Eisentraut saw the same split: some reverts came from architectural defects, the rest was a long tail of small things. The first needs a different design, the second mostly needs time.

When legacy code moves to a new team, I would make this review one of the first jobs. The new team then learns the code through real problems. I wrote about the rest of such a handover in handing over legacy code to a new team.

Test the combinations nobody thinks of

Eisentraut gives an example that holds outside databases too. A new feature has to work with all sorts of combinations of existing features, and nobody can test or even list those cases by hand. AI-assisted fuzzing finds problems there very quickly, he says, so it should become part of feature development.

He draws one more lesson: make internal interfaces more robust, so that each combination does not open up new interactions. That is architecture work. Clear boundaries between modules limit how many combinations you have to test.

A place for half-finished features

The PostgreSQL community has been considering an experimental status for features, so they can mature in the main tree. Eisentraut says that would have helped with some of the reverts, but they have not found a way to do it yet.

In a product you have an easier option. Feature flags let you merge code without customers seeing it. My advice is to put a feature that still has a long list of open findings after review behind a flag, instead of leaving it in a branch that falls further behind every week.

People still own the review

Our developers work with AI tools such as Claude Code every day. An AI review tool finds more than before, but it does not decide what happens next. Someone has to choose what gets fixed now, what needs a different design and what can wait. I wrote about how to run review across distance in code review across distance. Milos covered the team rules for these tools in AI coding tools in a remote team.

PostgreSQL 19 is still coming. The first release candidate appeared on 15 October 2026, a second follows on 12 November and general availability is planned for 19 November. According to Eisentraut it includes REPACK CONCURRENTLY, logical replication of sequences and planner hints with pg_plan_advice, among other things. If you run Postgres, now is a good time to plan the upgrade. Why we often pick Postgres as the default is in Postgres as the default database.

Sources

• Peter Eisentraut: The reverts will continue until morale improves
• PostgreSQL: PostgreSQL 19 RC 1 Released