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.” 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.
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:
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.
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.
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: 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.
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.
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.
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:
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.
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.
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.
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.
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 and let’s talk.
MAINTENANCE WITH AN OWNER
Before you open your online store, connect your ERP, payments, inventory, e-invoicing and shipping. What depends on what, in which order, what breaks if you skip it, and how to check it is really connected.
If someone pitches changing all your URLs or buying a keyword domain to rank higher on Google, that's not an upgrade. It's a move. In October 2026, Google reminded everyone those keywords carry almost no weight. When changing URLs makes sense, and how to do it right.
