PostgreSQL 19's Delay, curl's Open Reporting of Minor Flaws and Edge's Review Automation: Where Three Projects Say AI-Assisted Work Lands

Background

Three pieces of project infrastructure that sit between a contribution and a release are the subject of this analysis: a database project’s stabilisation period, a library’s vulnerability-report intake and a browser vendor’s extension review. Each has been described in October or September reporting as absorbing more work as AI tools enter the process.

The Herald has covered the individual developments. It reported on PostgreSQL 19’s release candidate and the November 19 general-availability date, on Microsoft’s Edge team automating extension reviews, on a Linux Foundation survey of maintainers and on changing disclosure rules for AI-found bugs. This piece compares what the sources say about where the added work lands and where they disagree about its cause.

Current situation

PostgreSQL 19

According to The Register, PostgreSQL 19 was once slated for late September or early October and is now expected to reach general availability around November 19, with between eight and 10 significant features dropped. The Register reports that Peter Eisentraut, described there as a “veep” at EDB and a leading PostgreSQL committer, said in a blog post that the reason could be at least in part attributed to LLM code reviews used by developers. In the words The Register quotes from him, LLM-assisted review finds issues faster, “and then you’re staring at a list of forty defect reports”, and even a three-line fix carries “a fixed overhead”, after which “you run out of time”. The Register also reports that he said some reverted features had significant architectural defects that would have been hard to fix quickly during beta, and that the reverts were not down to “vibe coding”, because that technique was not available when most of the features were written.

LWN reported on the project’s mailing-list discussion on September 10. It describes an August 25 email from contributor Robert Haas, titled “scary patch contest”, about patches that had needed an unusually large number of fixes after the April 8 feature freeze, and notes that Haas said he had asked Claude to evaluate which patches were the scariest. LWN reports that release-management team member Melanie Plageman wondered “if the ease with which LLMs allow people to pressure test features means we are finding more bugs sooner than we have in the past”, while fellow team member Nathan Bossart had expected LLM use to make new features more stable by feature freeze, “but it seems that that hasn’t turned out to be the case”. LWN also reports that Daniel Gustafsson said most of the large features in PostgreSQL 19 “were written, reviewed and tested, before AI tools were either available or even remotely as good as they are now”. Haas, according to LWN, was not convinced the problem was as simple as finding more bugs with LLMs, and observed that the features with many post-freeze fixes had all been committed close to feature freeze in April. LWN also reports that contributor Paul A. Jungwirth said Noah Misch had found additional bugs in his patch “with some LLM investigation”.

On October 30, Phoronix reported that Haas had published a blog post attributing the delay to AI. Phoronix describes a surge of bug reports from AI/LLM agents plus security and bug back-ports to prior PostgreSQL versions. It quotes Haas as naming two factors: more bugs being found takes more time to fix, and “LLMs can draft fixes, but those fixes aren’t always correct or compliant with PostgreSQL standards”, so humans must still review and commit them; and review time “got diverted into addressing security issues and other bugs in the back-branches”.

curl

On its own blog, the curl project announced in a blog post that from October 26, 2026, vulnerability reports it deems LOW or MEDIUM severity must be submitted as issues in its GitHub repository, while only HIGH or CRITICAL ones stay private in the HackerOne tracker. The post, which The Register attributes to project maintainer Daniel Stenberg, says the change is “entirely triggered by the current avalanche of vulnerability reports”, that over the last few years over 90% of submissions could quickly be assessed to be less than HIGH, and that “all key maintainers feel strained, overloaded and brought to the brink of what we can muster”. It describes “an army of AI-using researchers” who feed new CVEs and fixes to their models to look for similar mistakes, and it says many newly reported vulnerabilities are figured out by AI models that create “crazy sequences or option combinations”. The post also states a cost: the policy “will give bad people a slightly longer window of opportunity to exploit weaknesses”. The Register’s October 21 report on a Linux Foundation survey also covered the change, quoting Stenberg.

QEMU and the wider survey

Phoronix reported in August that Red Hat engineer Daniel Berrangé said QEMU had been hit by a single reporter filing over 125 separate bug reports in under 10 minutes, all for UBSan output, and called it “effectively a denial of service attack on the project maintainers”. Phoronix framed the episode within criticism of AI/LLM-driven burden on maintainers; the Berrangé statement it quotes does not itself say the reports were AI-generated. Berrangé suggested GitLab rate-limit reports from non-members.

In the Linux Foundation survey as reported by The Register, respondents estimated that AI cut code-authoring time by 52 percent on average and that a quarter of incoming pull requests were low-quality “AI slop”, rising to 31 percent among large projects; 21 percent reported that highly complex tasks took longer.

Edge extension review

The Register reported that the Edge team said “submission volumes have continued to increase” and that its review pipeline had experienced strain, lengthening review turnaround. The team said it had introduced automation for repeatable validation checks, and that this “doesn’t change our review standards or reduce the checks an extension must pass”. The Register adds that Microsoft has fewer people to do the vetting because of regular rounds of redundancies, and notes that the team did not say whether the automation uses AI.

Automation on the review side

Phoronix reported on October 8 on a status update, given at that week’s Linux Plumbers Conference, from Google engineer Roman Gushchin on Sashiko, an agentic review tool for Linux kernel changes built by Google engineers. According to that report, it has completed more than 191k patch reviews across 99 mailing lists, and 463 Linux kernel CVEs this year cite it. These are figures from the tool’s developers as relayed by Phoronix, not an independent measurement.

Implications

What follows is drawn from the sources above rather than from independent measurement.

The sources describe the bottleneck as human review and fixing time rather than detection. Eisentraut’s description, as quoted by The Register, is that each additional defect carries fixed overhead regardless of fix size. Haas, as quoted by Phoronix, says LLM-drafted fixes still need human review. The curl post describes the same shape: reports arrive at a pace the maintainers say they cannot sustain, and the work per report does not shrink by moving it into public view, a point the post concedes directly. The Edge team’s account, as relayed by The Register, is of rising submission volume and a strained review pipeline.

The sources disagree on how much of the PostgreSQL delay is attributable to AI. The Register reports Eisentraut as saying the reason could be at least in part attributed to LLM code reviews; Haas’s blog, per Phoronix, says the delay is AI’s fault; on LWN, Haas questioned a simple LLM explanation and pointed to the timing of commits, and Gustafsson noted that the features predate capable AI tools. None of the cited reports quantifies the share of delay attributable to LLM-found bugs. The Register quotes Eisentraut as saying “Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles”; that is his expectation, not an established result.

Responses so far change process rather than standards, and each carries a stated trade-off. curl moves minor reports into the open and states the exploit-window cost. Edge automates repeatable checks and says standards are unchanged. QEMU’s Berrangé proposed rate limiting. Google’s Sashiko applies automated review to patches. The Linux Foundation survey figures add that, as reported by The Register, only 35 percent of projects have a formal policy permitting GenAI use, and 32 percent have no policy and no plans for one.

Evidence is uneven. Most of the PostgreSQL account rests on contributors’ statements in blog posts and mailing-list messages; the curl account rests on the maintainer’s own post; the Edge account rests on a vendor blog as relayed by The Register, which adds staffing reductions as a further factor; the Sashiko figures come from its developers. The Herald’s own count is three projects or organisations in the sources, which is too few to describe a general pattern.

What we don’t know

No cited source measures how much of the added workload comes from AI-found genuine defects versus low-quality reports, or how long the strain will continue. The PostgreSQL 19 date of around November 19 is The Register’s reported expectation as of October 16.