> ## Content Index > Fetch the complete content index at: https://varops.com/llms.txt > Use this file to discover other available public pages before exploring further. # How to plan a software release when AI-found bugs multiply the fix work on older versions - URL: https://varops.com/how-to-plan-a-software-release-when-ai-found-bugs-multiply-the-fix-work-on-older-versions/ - Published: 2026-11-03T16:12:07.000Z - Updated: 2026-11-03T16:12:07.000Z - Description: PostgreSQL 19 is late because LLMs found more bugs than its committers could fix in time, on every older version still supported. North on the three numbers to write down and the two rules to set before the wave reaches your release. - Author: North Wayne - Tags: First Opinion *Most of* [*what this magazine has run on AI bug-finding*](https://varops.com/how-to-size-the-patching-work-ai-found-flaws-create-from-bank-of-americas-1-000-extra-contractors/) *has been about the finding: how many flaws, how fast, how cheap. Today* [***North Wayne***](https://varops.com/columnist/north/) *looks at the other end of the pipe. PostgreSQL will ship its next release late, and one of its committers, who counts it among the cleanest codebases he has worked on, says LLMs found more than the humans could fix in time. North's interest is not the delay. It is that the bill arrived once for every old version still supported, and that is a number any company shipping software can look up this week. —* [*Muximus*](https://varops.com/columnist/muximus/) --- PostgreSQL 19 will most likely ship in November, later than any of the project's recent major releases, and a long-time committer on the project says the reason is AI. People are finding bugs in Postgres with LLMs. The work did not land on them. It landed on the committers who fix the bugs, on every older version the project still supports, using hours that would otherwise have gone into the new release. That is a decision most software companies have not noticed they are making. The number of versions still supported has become a cost line for AI-found bugs, and the cost is paid out of the next release. ## What happened at Postgres Robert Haas, a PostgreSQL committer and major contributor and a senior staff engineer at Databricks, laid out the numbers on October 30\. Postgres freezes features on April 8 each year and has shipped its major versions between mid-September and mid-October for about a decade. This year it "most likely won't be released until November", and he does not rule out a later date. He compared the same window in two years, April 8 to September 25: - Back-patched commits to the branch being prepared for release went from 724 in 2025 to 1,169 in 2026, up about 61%. - Commits back-patched to at least one prior release, as well as to the release in progress, went from 248 to 433, which Haas describes as a jump of more than 74% in a single year. - Commits that went only into the development branch, by his account, "actually declined slightly". The growth was in fixes carried backward, not in new work. His explanation is that committers were probably about as careful as in earlier years, and LLMs caught more of their mistakes: "a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs, and the PostgreSQL committers have been very, very busy fixing them." [LLMs can draft fixes as well](https://varops.com/fixing-a-bug-and-breaking-nothing-are-two-separate-tests-for-ai-written-patches/), but those fixes "aren't always correct or compliant with PostgreSQL standards", so every one still goes through a human. Three major features were pulled from the release between August 27 and September 15: UPDATE/DELETE FOR PORTION OF, SQL property graph queries (SQL/PGQ), and ALTER TABLE MERGE and SPLIT PARTITION. Haas ties the late reverts and the delay to two effects of the same cause. More bugs take more time to fix. And reviewer time "that would have been spent reviewing what went into the release got diverted into addressing security issues and other bugs in the back-branches", so it took longer to work out what had to come out. That is his reading from inside the committer group. It is a well-placed reading, not a measurement. He is not alarmed. He calls Postgres one of the cleanest codebases he has worked on and reads the slip as the project choosing quality, which is fair. His worry is the long run: a codebase whose git history spans more than 30 years holds decades of latent bugs, and the project has to work through them while still shipping new things. ## The framework: who pays, and how many times Strip out the database details and three facts are left. Each one travels. **The finder is not the bottleneck.** Finding a bug with an LLM is cheap. Confirming it, writing a correct fix, reviewing that fix and committing it is not. At Postgres, the people doing that work are the same people who [review what goes into the new release](https://varops.com/how-to-set-up-ai-code-review-so-low-risk-changes-merge-without-waiting-for-a-human/). When one queue grows, the other waits. Any operations leader has watched this happen with a shared approvals desk; it is the same desk. **The project did not choose the timing.** Many of the reports came from outside the project, from people on the Internet using LLMs. A company with open-source components, a public SDK, [a bug bounty](https://varops.com/patch-your-internet-facing-systems-now-heres-how-to-set-them-in-hours-and-keep-30-days-for-the-rest/), or simply customers who use AI tools can end up in the same position without having decided anything. A company that turns AI bug-finding on internally at least picks the start date. **Every fix is multiplied by the number of supported versions.** Postgres supports each major version for five years. As of early November 2026 that is versions 14 through 18, plus 19 in preparation. A bug in code that has existed for years may need a fix on several of those branches, each one tested and reviewed separately. Haas's numbers count only one older branch. The load on the other four is not in the post, and it is the number a reader would most want to see. ## Who this lands on The case is open source. The arithmetic is not. It applies to any company whose customers run software it cannot upgrade for them: on-premises and self-hosted products, SDKs and client libraries, enterprise editions with long-term-support branches. Each supported version is one more place an AI-found bug has to be fixed. It also applies, more mildly, to a single product with one version, wherever the people who review fixes are the people who review new work. ## What to decide before the reports arrive Start with three numbers. Before reading on, it is worth asking how many of them anyone in your company could give today: 1. How many versions are still patched. 2. How many fixes a month land on each of them, and whether that number is moving. 3. How many reviewer hours a month go into the next release. Then set two rules now, while nobody is under pressure to bend them. - **A ceiling on old-version work.** Decide what share of reviewer time fixes to older versions may take before the release date moves. Past that line, the date moves on purpose, not by drift. - **A feature cutoff date.** Decide the day an unfinished feature gets pulled. Postgres pulled its three features between August 27 and September 15, in the weeks just before its usual release window. A cutoff agreed in advance makes that call earlier, and earlier is cheaper. If the fix count on older versions is rising, the support window is the cheapest lever available. Every version retired early removes a branch from future fixes. Postgres retires version 14 on November 12, 2026, on schedule; most companies have never written down their own equivalent date. ## What the post does not tell us Haas names no AI tool or model, gives no total count of bugs found, and does not split fixes by whether an LLM found them. We could not verify how much of the jump traces to LLM-found reports. It rests on his judgment, and nothing outside the committer group measures it. Postgres is also unusual: very old, very widely used, and fully public, which likely makes it an easier target than most for anyone pointing an LLM at old C code. A younger, private codebase may see a smaller wave. ## The Verdict Go: treat the support window as a budget decision this quarter, not an engineering default. Write down the three numbers, set the ceiling and the cutoff before the next release cycle starts, and if old-version fixes are climbing, retire a version sooner than planned. The wave may be smaller elsewhere than it was at Postgres. It will still be reviewed by the same people who build the next release. From thinking to doing. [![CTA Image](https://cdn.varops.com/content/images/2026/10/logo-black.jpeg)](https://varops.com/transformation/) ****From hard decisions to real execution.** The right technology decision isn't always to build, buy, or automate. It’s knowing what your business actually needs. VarOps brings the technical judgment and execution to make those decisions count. [Make the Right Move → ](https://varops.com/transformation/) ## Sources - Robert Haas, "Postgres 19 is late, and it's AI's fault", October 30, 2026: [http://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html](http://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html?ref=varops.com) (also published on the Neon blog) - PostgreSQL versioning policy and supported versions: [https://www.postgresql.org/support/versioning/](https://www.postgresql.org/support/versioning/?ref=varops.com)