"Zero bugs" is the kind of phrase that usually makes engineers roll their eyes. It sounds like executive wallpaper, or worse, a slogan pasted over a backlog.

That is why Daniel Stenberg's latest post about curl is more interesting than its headline suggests. He is not claiming curl is close to perfect. He is asking a harder question: if modern bug-finding tools really are getting better that fast, what would progress toward zero bugs even look like in public?

His answer is refreshingly concrete. Look at bug age. Look at fix volume. If automated analysis, fuzzing, and AI-assisted review are genuinely draining the swamp, then newly discovered vulnerabilities should be getting younger. Eventually, the overall stock of fixes should start falling too. If that does not happen, the tools may be surfacing more issues, but they are not yet changing the underlying economics of maintenance.

That framing matters far beyond curl. Right now the industry has no shortage of triumphant demos showing models finding bugs, generating patches, or reviewing pull requests at machine speed. The missing part is whether any of that leaves a visible fingerprint on a mature codebase over time.

What Stenberg actually says

In his April 30 post, Stenberg starts from a simple observation: better tools do not create bugs, they expose bugs that were already sitting in the source tree. That sounds obvious, but it matters because it shifts the discussion away from AI spectacle and back to inventory management. If detection gets faster while the codebase keeps accumulating defects, maintainers still lose.

He proposes two rough signals for whether a project is moving closer to "zero bugs":

1. the age of vulnerabilities when they are finally found and reported 2. the rate of bug fixes over time

The first signal is the sharper one. If tooling is catching almost everything quickly, then the bugs it finds should increasingly be fresh bugs, not decade-old landmines. The second is slower but still useful. A project that has already flushed out most of its defect stock should eventually have fewer real fixes left to make.

Then comes the important part: Stenberg looks at curl's own data and says the curves do not show that trend yet. His conclusion is blunt. "We are not close."

That sentence is the whole value of the post. It turns a fuzzy industry mood into a falsifiable claim.

The primary-source evidence behind the post

This is not just a maintainer vibe check. curl already publishes a detailed vulnerability table for recent releases, along with machine-readable vuln.csv and vuln.json data and per-CVE JSON records. The project also keeps a long public record of disclosed security issues and affected versions.

That matters because it gives the "zero bugs" conversation a real measurement surface. Stenberg is not inventing a metric after the fact to decorate a keynote. He is pointing at an existing public dataset and asking what it does, or does not, say.

The same security page makes another point that is easy to miss in the current "AI will find everything" climate. curl still classifies many historical issues as classic C mistakes: overflows, overreads, double frees, use-after-free, bad frees, and similar memory-safety failures. Better scanners help. Better fuzzing helps. But old bug classes do not disappear because the tooling got smarter.

The real issue is not perfection, it is signal

The best way to read this post is not as a prediction that curl is headed to a bug-free future. It is as an argument that maintainers need better public signals than raw bug counts.

Raw counts are messy. Improved tooling can make a project look worse before it looks better. More reports can mean the code is crumbling, or that the searchlights finally got brighter. Without a time-based metric, those two stories blur together.

That is why vulnerability age is the more interesting lens. It asks whether a project is discovering defects earlier in their life cycle, before they spend years hiding in stable code. If the answer stays no, then the tooling story is less impressive than the demos make it sound.

Why the Reddit reaction was useful

The Reddit thread on r/programming immediately pushed back on the headline, and in this case the pushback sharpened the point instead of diluting it. One commenter said the title was misleading because Stenberg was not arguing that curl is near zero bugs, but describing a process that treats each bug as real work instead of inevitable noise. That is a fair read.

Another useful thread in the discussion was scope. curl is not a frozen utility in a museum case. Commenters pointed out that HTTP/2, HTTP/3, QUIC, and related protocol work keep expanding what the project has to support. That means the target keeps moving. In a codebase like this, "fewer bugs" is partly a security question and partly a systems-growth question.

That is exactly why curl is a better case study than some polished startup benchmark. It is old, exposed, heavily used, and still changing. If any project can tell us whether modern bug-finding actually bends the maintenance curve, it is something like this.

What remains uncertain

There are limits here.

First, Stenberg is reasoning from one project's history. curl is unusually visible, unusually portable, and unusually battle-tested. Its graphs are useful, but they are not an industry-wide dataset.

Second, the post is qualitative. The blog entry shows the direction he wants to watch, not a formal causal analysis proving that any one class of tooling improved or failed.

Third, bug counts are socially messy. Some Reddit replies made the obvious point that "bug" can mean anything from a remote code execution flaw to a behavior mismatch a product manager dislikes. Stenberg narrows the most serious part of the analysis to vulnerabilities, which helps, but the broader bug-fix discussion still has that ambiguity.

What developers should take from this

The practical takeaway is not "trust AI bug hunters" or "ignore AI bug hunters." It is simpler.

If your team claims automated review is changing software quality, you should be able to show it somewhere other than a demo. Are serious bugs being found sooner? Is the age of newly discovered vulnerabilities dropping? Is the stockpile of fixes starting to shrink, even slowly?

If you cannot answer those questions, then "we found more bugs this quarter" is not yet proof of progress. It may just mean your flashlight got brighter.

That is what makes Stenberg's post worth reading. The headline flirts with utopia. The substance is about measurement discipline.

Sources

  • Daniel Stenberg, "Approaching zero bugs?" (Apr. 30, 2026): https://daniel.haxx.se/blog/2026/04/30/approaching-zero-bugs/
  • curl security documentation and machine-readable vulnerability data: https://curl.se/docs/security.html
  • curl vulnerability table: https://curl.se/docs/vulnerabilities.html
  • Reddit discussion on r/programming: https://old.reddit.com/r/programming/comments/1t1uplj/approaching_zero_bugs_daniel_stenberg/