It seems that there is no group of people more divided by the rise of LLMs than developers. Debates on whether LLMs are going to help us work, improve our lives, replace us outright or kill us all are certainly not new, but they rarely end with a consensus. One thing that’s becoming evident, however, is that AI is becoming unavoidable, especially within the open source industry. LLMs have advanced significantly in 2026 alone, with Claude Code, Codex and others now showing a surprising ability not just to write simple boilerplate but to also understand and work on complex interactions and nuances in substantial codebases.
It is becoming increasingly common for open source projects to receive AI-generated pull requests or issue reports, much to the confusion of maintainers who often don’t know how to (or whether they even want to) handle them. The quality of these contributions varies significantly, not surprising given that the quality of the output is usually proportional to the quality of the model, prompt and context, but even as a self-professed skeptic, I have found myself more regularly surprised by the latest frontier models. It’s difficult to let go of control entirely; I still prefer to be the “human in the loop”, as I have seen more than enough cases where LLM-written code can be functional on the surface but be wildly unsafe or perform horribly.
However, there’s no doubt in my mind at all that we have passed an inflection point in recent months where such models have improved to the point that they are now more often useful than not, as surreal as it is to admit.
But something else has also started to happen which I didn’t anticipate. As one of the primary maintainers of the NATS Server project, recent weeks have seen a sharp and sudden increase in the number of security reports that we have received. If you follow along with our project, then you may have noticed that the last couple of releases have been somewhat heavy on the number of fixed CVEs. We are far from alone in this, we have seen the same happening with many other open source projects.
Aside from writing code, LLMs are now proving themselves to be surprisingly good at combing through codebases, looking for common vulnerability patterns and even generating reliable reproductions of how to exploit them. This shouldn’t really be surprising, given the training data likely includes plenty of material on what all of the different classifications of vulnerabilities look like, but in the past limited context windows have made it difficult for LLMs to bring in enough code to make wider sense out of. This now no longer seems to be an issue, and with that, OpenAI have productised this exact use-case with Codex Security, which examines commits on an on-going basis, looking for security issues as they appear. Anthropic also appears to be building something similar with their upcoming Claude Code Security product. Others will no doubt follow.
The end result is that it no longer takes a team of expert security researchers to search a project for exploits. This process is now becoming commoditised. Anyone and everyone can ask an LLM to do it for them and they can watch it happen in real time. An increasing number of people have been doing exactly that. At times I wonder about their motives, whether this is about improving the software of the world or merely collecting as many credits on disclosure notices as possible, or if it’s both, or even neither. I don’t suppose it even matters. Either way, we have been left trying to figure out how best to deal with the increased volume of incoming reports.
I lead a small team of extremely talented and initially-AI-skeptic developers, but as with all small teams, time is a precious commodity amongst us. Pure development time is often already scarce amongst an on-going support load. On top of that, every new security vulnerability report that we receive effectively arrives with its own ticking clock, counting down until a deadline where the reporter believes a sufficient amount of time has passed to make their own public disclosure. We are finding ourselves continuously triaging and reprioritising, all the while continuously trying to stay ahead of what comes next. We have had no choice but to delay feature work and releases to stay on top of verifying and fixing exploitable issues in dark corners of the codebase that, in many cases, have not been touched or even looked at in years.
This leaves us with a problem. Anything that we don’t spend the time to find is now almost certainly going to be discovered by an LLM in the near future. We have also been fortunate to have received reports from responsible disclosers, but that ultimately tells us nothing about who else may be using LLMs to stockpile vulnerabilities for more nefarious purposes. We have been forced to set our opinions on AI aside and to choose to turn to the exact same tools and methods that others are using to perform our own security audits of our own code before others have the chance to do the same.
In recent weeks we have done exactly that, harnessing different models and tools and trying to fix everything that they discover. This exercise has so far resulted in dozens of issues of various severities, thankfully more of them requiring very specific configurations than not. But these are things that we have missed day-to-day, things that external human security audits of the codebase have missed, things that static analysers have missed and continue to miss. We are still finding and fixing more. I have no doubt that this will continue for some time.
One of the most interesting (and arguably frustrating) parts of this process is that Claude Code, Codex, Detail.dev and others have occasionally stumbled across the same issues, but in more cases than not, the issues found by one model were not at all noticed by others, at least not until prompted with specifics. In other cases, fixing one issue suddenly caused a given LLM to start examining different code paths, uncovering something else completely unrelated but sometimes equally or more severe. This admittedly makes the process feel like somewhat of a lottery and leaves me feeling deeply uncertain about what they could be missing, or if some prompt variations or subtle wording change would completely change the outcomes. I don’t think I have ever really appreciated determinism as much as I do now that we have been forced to gamble so much with tools that are notoriously and unavoidably non-deterministic. This is a real question for which I have no good answer right now: will the tools continue to find the same issues tomorrow that they found today?
That said, I do think that the process has been a necessary one. NATS will come out of this as a better and more robust project. On the other hand, I can’t say that this isn’t stressful and draining, because it is. It now feels like the pressure on us as maintainers has increased dramatically in a relatively short space of time, and that our time and posture can be much more readily disrupted at a moment’s notice by anyone with a Claude subscription.
I don’t believe that we, collectively in the open source world, are at all prepared for the avalanche that is about to come crashing down on us. The barriers to entry are shifting downwards considerably, not just for understanding or contributing to a project, but also to find new and creative ways to exploit or attack one. This exercise leaves me feeling as though I have seen a glimpse of the future of open source maintenance and stewardship. The fact that the open source world is going to change is now without a doubt a certainty, but the question I cannot stop asking myself is whether or not the toll will be too great on the very maintainers that make open source viable to begin with.