# AI is finding bugs: who reviews yours?

Source: https://somosgentedigital.com/en-us/blog/software-maintenance-ai-bugs

Date: 2026-11-03

PostgreSQL 19 is late because AI is helping people find more bugs. What it means for your business: who reviews your software and who owns the next patch.

![Astronaut cat tightening a device with a wrench in space, like the ongoing maintenance your software needs](https://images.prismic.io/somosgentedigital-alfa/B5Bi6_TJ3dM831Ql_mantenimiento-software-ia-errores-2026-11-03.png?auto=format,compress)

In short: AI is not breaking software; it is making its bugs much faster to find, including by people who want to exploit them. That is why your software needs a named person who reviews and maintains it on a fixed budget, not only when there is money left over.

On October 30, 2026, PostgreSQL developer Robert Haas published a post with a blunt title: [“Postgres 19 is late, and it’s AI’s fault.”](https://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html) PostgreSQL is an open-source database, the system where many applications, online stores and business platforms keep their data.

If your company runs a website, an online store or its own software, this story matters even if you have no idea which database you use. What Haas describes is not just a PostgreSQL problem; he says that, to some extent, it applies to every software developer. It is a shift in how bugs get found, and it goes straight to how you budget for maintaining yours.

## What happened with PostgreSQL 19

According to Haas, over the past decade PostgreSQL major releases have shipped on a very predictable schedule: no earlier than mid-September and no later than mid-October. This year is different. PostgreSQL 19 most likely won’t ship until November, and the project may even decide to push it back further.

His short explanation is that “LLMs happened,” meaning the large language models behind today’s AI tools. All software has bugs, and PostgreSQL’s code base is large, complex and decades old. What changed is that those bugs have become far easier to find. Fixing them has also gotten easier, just not by as much.

Haas backs this up with the number of changes recorded in the code between April 8 and September 25 of each year:

- **In the release being prepared:** 724 changes went into the PostgreSQL 18 branch in 2025, and 1,169 into the PostgreSQL 19 branch in 2026. That is a jump of more than 60%.
- **In the release already in use:** 248 changes went into the PostgreSQL 17 branch in 2025, and 433 into the PostgreSQL 18 branch in 2026. That is a jump of more than 74% in a single year.

Why? Haas says a huge number of people online are now reporting PostgreSQL bugs they found with AI, and the team has been very busy fixing them. Time that would have gone into reviewing the new release went into security issues and other bugs in older versions instead.

One detail every owner should notice: AI can draft fixes, but those fixes aren’t always correct or up to the project’s standards. People still have to review and apply them. Haas himself says the delay is not especially worrying, because it comes from the project’s concern for quality.

## AI is not the problem

It is easy to read this as “AI is breaking software.” That is not what is going on. The bugs were already there, some of them hidden for years. What changed is how fast they are found.

Haas puts it this way: every feature PostgreSQL developers write from now on will be scrutinized by AI, and things that would have gone unnoticed forever will now be found, perhaps within hours. He adds that this will push every PostgreSQL developer, and to some extent every software developer, to raise their game. Haas does not talk about attackers; this part is our own reading: that speed is not reserved for volunteers reporting issues in good faith. The same ease of finding a flaw helps anyone who wants to exploit it.

For a business, that changes the math. A bug that could once sit quietly for years can now surface in a report, or in an attack, much sooner. What is at stake is not technology. A bug like that can mean orders that don’t come in, customers who can’t log in and a hard conversation about trust in your brand.

## Maintenance “when there’s budget left” no longer works

In many companies, maintenance happens when something breaks or when there is money left at the end of the year. While bugs were found slowly, that model held up. Now the gap between someone finding a flaw and you fixing it is exactly where the risk lives.

Your software is also more than the code someone wrote for you. It depends on third-party parts: the database, the programming language, libraries, plugins and the services it connects to. When any of them ships a patch, someone has to notice, test it and apply it. We saw this recently with [the critical PHP patch](/en-us/blog/parche-php-quien-actualiza): the advisory went out, and the real question was who would apply it that same day.

What we have learned maintaining our clients’ websites and software is that the biggest risk is rarely technical. It is that nobody owns the job: everyone assumes someone else is watching the updates, and in the end no one is.

## Two questions worth asking as an owner

### Who reviews your software before someone else does?

If anyone can now use AI to look for flaws in a system, the question is not whether someone will examine yours, but who gets there first. You need a named person, on your team or at your vendor, who regularly reviews your software and the third-party parts it relies on, and who explains what they found in plain language.

### Who acts when a patch comes out?

A patch is a fix published by the maker of a piece of software. It does little good if nobody installs it. Ask who sees the advisory, who tests the patch before installing it, how quickly, and how they confirm it is done. If the answer is “I guess the vendor handles it,” that is your first finding.

## What maintenance looks like as a fixed budget

The answer is not to buy a tool and hope it handles everything on its own. It is to treat maintenance as a fixed cost of doing business, like accounting or insurance, with someone who stays with you month after month. In practice, that includes:

- **Regular updates:** your own software and third-party components are updated on a schedule, not only during an emergency.
- **Dependency and vendor review:** you know which libraries, plugins and services your software uses, which versions they are on and which ones no longer get fixes.
- **Testing before release:** every change, whether it comes from a person or an AI tool, is reviewed and tested before it reaches your customers. That is the same lesson PostgreSQL is teaching.
- **Someone who answers:** a name, a channel and an agreed response time for when a security advisory lands or something stops working.

A fixed budget also changes how the work gets done. A planned update can be tested calmly; an emergency one is rushed, often while the business is stalled. And if your system is custom-built, it helps when the people maintaining it know how it was built, as with [custom web development](/en-us/custom-web-development).

## Frequently asked questions

### Why is PostgreSQL 19 late?

According to Robert Haas, many people are finding and reporting bugs with AI tools, and the team has spent more time fixing them. Major releases used to ship between mid-September and mid-October; this time, November or later is most likely.

### Does AI make my software less secure?

Not by itself. The bugs were already there; what changes is that they are found faster, including by people who want to exploit them. That is why it matters who finds and fixes them first.

### Can I let AI fix the bugs it finds on its own?

AI can draft fixes, but they are not always correct. A person has to review and test them before they reach production, which is exactly what the PostgreSQL team does.

### What should a software maintenance plan include?

At a minimum: scheduled updates, a review of dependencies and third-party services, testing before every release and a named person who responds when a patch comes out or something fails.

At Somos Gente Digital, we listen, build and stay with you until your business grows. In maintenance, that means reviewing your software before someone else does, keeping the parts it depends on up to date, testing every change before it goes live and telling you what was done. We won’t promise bug-free software, because no software is, not even PostgreSQL. What we offer is people who are close by, a clear method and someone who answers when a patch comes out.

If you are not sure who is reviewing your software today, see [how we handle software maintenance](/en-us/software-maintenance) and let’s talk.

## Who is reviewing your software today? Let’s talk before someone else does.

[See our maintenance service](/en-us/software-maintenance)