AI tools are helping developers discover software problems faster than before. The experiences of curl and PostgreSQL 19 show why the next challenge is deciding which findings matter, fixing them safely and finding enough time for thorough code review.
When finding bugs becomes easier than handling them
For years, curl rewarded security researchers who discovered genuine weaknesses in its software. The programme helped uncover 87 vulnerabilities and paid more than $100,000 in rewards.
Then the quality of incoming reports changed.
Before 2025, more than 15 percent of submissions were confirmed as real security vulnerabilities. During 2025, that figure fell below five percent. Many reports looked convincing but described problems that maintainers could not reproduce or confirm.
Daniel Stenberg, curl’s maintainer, said the project was receiving a growing volume of poor-quality submissions, many created with AI assistance. Investigating them consumed time that could have been spent improving the software.
On January 26, 2026, Stenberg announced that curl’s paid bug bounty would close. The programme officially ended on January 31.
The decision was unusual because finding more security problems should, in principle, help make software safer. Yet the experience showed how easier discovery could also make maintenance harder.
AI tools can examine code and suggest where something might be wrong. They cannot make every suggestion correct. A developer still has to determine whether the reported problem can actually happen and whether it puts users at risk.
That work becomes difficult when reports arrive faster than a project can investigate them.
curl’s experience was particularly revealing because the problem did not end when the quality of reports improved.
curl’s problem changed, but the workload remained
By April 2026, Stenberg was reporting a very different situation.
The proportion of submissions confirmed as vulnerabilities had recovered to around 15 to 16 percent. More reports were identifying genuine bugs, even when those problems did not qualify as security vulnerabilities.
The quality had improved, but the number of reports had also increased. They were arriving at about twice the rate seen during 2025.
For curl, the problem had shifted from investigating too many unreliable claims to handling a growing number of useful discoveries.
A confirmed vulnerability requires more than acknowledging that a problem exists. The maintainers need to understand its cause, decide how serious it is, develop a correction and ensure the fix does not create another problem.
A small open-source project may have only a few experienced people available for this work. Those same contributors also maintain existing features, review changes and prepare releases.
Better discoveries therefore create real benefits, but they can also expose more work than the maintainers can complete quickly.
This is why report quality and review capacity should be treated separately. Stronger submission standards can reduce wasted investigation. They cannot remove the engineering work created by genuine defects.
GitHub took a related step in May 2026 when it strengthened the requirements for its bug bounty programme. Researchers using AI must check their findings before submission and provide a working demonstration of the reported problem.
The policy does not discourage AI-assisted research. It asks the reporter to establish that a claim is credible before passing it to maintainers.
That reduces avoidable work at the beginning of the process. PostgreSQL 19 shows what can happen when difficult problems remain close to a release deadline.
What really delayed PostgreSQL 19
PostgreSQL is one of the most widely used open-source database systems. Its version 19 release was originally expected in the fall of 2026.
The release schedule changed, and several planned features were removed from version 19.
Peter Eisentraut, a leading PostgreSQL developer, wrote in October that approximately eight to ten significant features had been reverted. A revert means removing a previously accepted code change, usually because it is not ready to remain in the release.
Some reports linked these removals to AI-assisted code review. The explanation was that AI tools had discovered too many bugs for developers to fix before the release.
AI did contribute to finding problems, but that was only part of the situation.
Eisentraut described several factors. Some features had serious design problems that would have required extensive changes. Others contained smaller defects that became easier to find through LLM-assisted code review.
At the same time, experienced PostgreSQL contributors had spent much of the release cycle dealing with security issues. This reduced the time available for reviewing new features. Review therefore came later in the cycle, and developers discovered problems with little time left to resolve them.
The complexity of PostgreSQL made some fixes particularly difficult. Features must work correctly across many combinations of database settings, data types and operations. A change that works in an ordinary case may fail when several less common features are used together.
AI-assisted testing can help discover these unusual combinations. But a problem found near the end of development may still require more time than the release schedule allows.
PostgreSQL contributor Tomas Vondra examined the discussions behind twelve reverted changes. He classified one as AI-related and another as possibly AI-related. He did not find clear support for attributing most of the remaining reversions to AI.
Vondra presented this as his assessment of the available development discussions, not an official count of every AI-discovered bug.
Christophe Pettus offered a related explanation. He argued that an important problem was when review occurred. Security work had occupied experienced contributors, so some feature reviews happened later than they normally would.
These accounts do not establish one cause for every removed feature. They do show why the familiar claim that AI found more bugs than developers could fix is incomplete.
Some problems were difficult by design. Some became visible through better testing. Others were discovered late because the people needed for review had been occupied elsewhere.
| Source | What it examined | What it says | What it does not show |
|---|---|---|---|
| Peter Eisentraut, 9 October 2026 | Why about eight to ten significant features were reverted | Several factors: serious design problems, smaller defects that became easier to find through LLM-assisted code review, and security work that occupied experienced contributors. | A count of bugs found by AI, or one cause for every removed feature. |
| Tomas Vondra | The discussions behind twelve reverted changes | One classified as AI-related, one as possibly AI-related, and no clear support for attributing most of the rest to AI. | An official count. It is his assessment of the available discussions. |
| Christophe Pettus | When review took place | Security work occupied experienced contributors, so some feature reviews happened later than they normally would. | That timing alone explains every removed feature. |
| PostgreSQL project, 15 October 2026 | The release schedule | A second release candidate on 12 November and general availability on 19 November 2026, to include fixes from the scheduled November update. | A fixed date. The schedule can still change before general availability. |
| Snowflake Engineering, 16 September 2026 | An additional account of AI-assisted testing and release decisions | Listed as further reading. | Anything published after 16 September, including the October accounts above. |
The PostgreSQL project’s October 15 announcement scheduled a second release candidate for November 12 and general availability for November 19, 2026. The project said it wanted to incorporate fixes from its scheduled November update before making version 19 generally available.
PostgreSQL’s experience is therefore not proof that AI caused the release delay. It shows how more effective testing, complex software and the timing of code review can influence release decisions.
What happens after a tool finds a problem
The work involved becomes clearer through a simple example.
Suppose an AI tool reviews a web application and warns that an unexpected input could cause the service to crash.
The warning may be useful, but a developer needs to check whether the input can actually reach the affected code. The application might already reject it, or the tool might have misunderstood an earlier check.
If the problem is real, the team must decide how serious it is. A failure that occurs only in a test environment is different from a weakness that an attacker can exploit remotely.
Only then can developers decide on an appropriate correction.
The fix needs testing, and the corrected software must reach users through a release or update.
AI can help at several stages. It can suggest tests, explain code and propose changes. Still, the team remains responsible for checking the results.
This distinction matters when software teams evaluate AI tools.
A report showing that a tool discovered a hundred possible defects says little about the actual improvement in software quality. The team also needs to know how many findings were genuine, how serious they were and whether they were resolved.
That is the practical connection between curl and PostgreSQL.
curl faced pressure from the number and quality of incoming reports. PostgreSQL faced difficult decisions about software readiness when reviews and fixes occurred late.
Both experiences make the work surrounding a discovery visible.
What development teams should change
The same problem can appear in a company using automated security scanners, AI code-review tools or software testing platforms.
A team may receive hundreds of warnings without knowing which ones require attention. If developers spend most of their time rejecting incorrect reports, the reporting process needs improvement.
GitHub’s approach offers a useful starting point. Require enough evidence to investigate a finding, including a clear explanation of the affected behaviour and a reproducible example where practical.
But teams should also examine what happens after a problem is confirmed.
If valid findings remain open because developers are occupied with other work, the issue is no longer report quality. The organization must decide how to allocate engineering time.
If fixes are completed but wait for testing or release approval, that stage needs attention instead.
A useful exercise is to follow a small sample of recent findings from submission to resolution. Record how long each took to validate, fix, test and release.
| Stage | How long it took | Who did the work | What it waited for |
|---|---|---|---|
| Validate | fill in | fill in | fill in |
| Fix | fill in | fill in | fill in |
| Test | fill in | fill in | fill in |
| Release | fill in | fill in | fill in |
A TechiesJournal worksheet, not data. Copy it for each finding in a small sample of recent findings.
The results may show that the team needs better automated checks before accepting reports. They may reveal that a few experienced engineers carry most of the review work. Or they may show that important fixes are waiting too long to reach production.
These are decisions that can be made using the team’s own evidence rather than assuming another AI tool will solve the problem.
The aim is not to slow down vulnerability discovery. It is to ensure the organization can act on what it discovers.
Faster discovery is only part of better software
AI-assisted analysis is making it possible to examine more code and uncover problems that might previously have remained hidden.
That is useful progress.
The experience of curl shows why the quality of incoming findings matters and what happens when valid reports increase. PostgreSQL 19 shows why the timing of review, the complexity of a change and the availability of experienced developers remain important.
For software teams, the lesson is practical. Measure what happens to findings after they arrive, not only how many the tools discover.
The value of AI-assisted bug detection comes from turning credible findings into reliable fixes that reach users.
References and further reading
curl and vulnerability reporting
- Daniel Stenberg, The end of the curl bug-bounty, January 26, 2026. The confirmed-report decline, programme history and January 31 closure.
- Daniel Stenberg, High-Quality Chaos, April 22, 2026. The subsequent improvement in report quality and rise in volume.
- GitHub, Raising the bar for its bug bounty programme, May 15, 2026. Expectations for verified AI-assisted security reports.
PostgreSQL 19 and code review
- Peter Eisentraut, The reverts will continue until morale improves, October 9, 2026. Developer account of release pressure, architecture, security work and LLM-assisted code review.
- Tomas Vondra, Are we reverting patches because of bugs found by AI?. Case-by-case examination of twelve reverted changes.
- Christophe Pettus, The patch is coming from inside the house. Analysis of review timing.
- PostgreSQL 19 Release Candidate 1 announcement, October 15, 2026. Official revised release schedule.
- Snowflake Engineering, PostgreSQL 19 release delay and feature reverts, September 16, 2026. An additional account of AI-assisted testing and release decisions.
Related TechiesJournal reading
- Node.js Brotli Vulnerability: How Applications Become Exposed and What Developers Should Check. Explains how teams determine whether a reported security weakness affects their applications.
Source review date: October 30, 2026. The PostgreSQL release schedule remains subject to change before general availability.