At risk of quoting too much of the article, it opens with this:

> A requirement for staying sane while working in public as an open source maintainer is realizing that every issue, PR, and piece of feedback is a present, not an obligation. You can accept it, ignore it, and use it partially or not at all.

> Except…

> For years, as lead of the Go Security team at the time, I’ve told new team members that it doesn’t apply to vulnerability reports. No, vulnerability reports are special. Security researchers are doing us a favor by reporting things confidentially instead of doing full disclosure, so we owe them something, which is not true of regular issues opened on the issue tracker.

[...]

> It’s 2026 and none of the premises are true anymore.

I respectfully disagree.

The premise is absolutely still true: if someone discovers a critical, exploitable vulnerability in your software, the impact and tradeoffs are exactly the same as they were before LLMs started finding bugs. There are just more of them now, so they're easier to come by.

But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report. This is just chugging through the backlog.

All of that said, I don't think finding vulnerabilities has really been the difficult security problem for most companies (or open source projects). The difficult problem is dedicating resources to fixing those vulnerabilities instead of building software, products, and/or infrastructure that people want. That problem is absolutely still here today, but I'm optimistic that agentic security developers will be able to take the burden off of development teams in the near future.

For tokens, of course.

▲

CJefferson 4 hours ago | parent | next [-]

The problem is there used to be a fairly high correlation between ‘security report’ and ‘real vulnerability’. Not perfect but good enough. Now the two are almost entirely disconnected.

▲

appplication 4 hours ago | parent | prev | next [-]

> But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report. This is just chugging through the backlog.

I think your logic is partly correct but the fact that the same LLMs are allowing an exponential increase in insecure code generated is a counterbalancing point. I do not think this phenomena will slow down.

	▲	sneak 4 hours ago \| parent [-]
		Nah, those same LLMs, if prompted correctly, will be able to do an audit pass and a fix pass on that LLM-generated code. It’s a tooling issue that will get fixed in time.

▲

shakna 3 hours ago | parent | prev | next [-]

> But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report.

That is not my experience at all. People will continue to high-volume spam intended behaviour as if it is a bug.

There will be fewer reports that matter as you fix things - but the volume of reports will either stay steady or go up. Making it harder to even notice the ones that matter.

▲

jcgrillo 3 hours ago | parent [-]

The problem always existed, but nobody amassed a sufficiently large army of trolls to exploit it until now. So it wasn't a priority to solve it before, but now it is. We're going to have to learn to differentiate reports that matter from those that don't. Classifying reports might actually be something you could productively use an LLM for..

	▲	shakna 2 hours ago \| parent [-]
		When we solved this problem for email... We just dumped everything similar to untrusted into the rubbish bin. Important things can vanish too, and that's an acceptable price.

▲

cpuguy83 4 hours ago | parent | prev [-]

It's not (just) more of them, it's the same ones reported by multiple people.

I think the point is those issues are now easily discoverable and are nearly public because of it.