I am pretty sure we have always been able to add holes faster than we can find them and fill them, and that this has not changed with the advent of faster hole finding tools that are also faster hole producing tools.
SQLite has gone into a frenzy of bug fixing this past year, changing long stable processes to ease things up: opening a specific report channel just for these kinds of bugs, adding features to Fossil to help manage things on their end (and that's just the visible stuff).
And with all that, the latest release has unfortunately been the buggiest I've experienced so far.
I skipped the .0 because of a crash, and only released .1 after giving up waiting for a .2 that never came, with a patch to fix a serious performance regression.
I spent a month supposedly shipping old bugs no one had a problem with, rather than shipping new bugs that instantly crashed things or caused measurable regressions.
That's on a software with stellar testing, and a good engineering team known to favour stability over the new shiny.
That era is over, compilers are used for almost all software, eliminating entire categories of bugs.
(Operating systems, by the way, are the exception to the rule for assembly: the Linux kernel today has an x86/x64 assembly source component around the same size as MSDOS 5.0: ~250kloc of it. Windows is smaller, based on the NT4 kernel leak at around 70kloc. As a percent of total they're much less, of course, but they also do much more. And have correspondingly more bugs, too.)
Entire classes of 'safety' bugs that just don't exist in modern compilers.
E.g.: forgetting to "POP" something you "PUSH"-ed, especially when it was a conditional allocation for a temporary.
Similarly, type errors were much more common, especially signed/unsigned, or accidentally overwriting things in scenarios that just don't occur even with ordinary C code. Function args were easy to push "correctly enough" that it "worked", but not really.
I'm tempted to say "no, it isn't". But I don't have numbers to back that up
(And hope performance stays in the same ballpark as the old code.)
I suspect both old codebases and new ones that have a very intentional architecture are both dangerous to let loose.
The agent doing the fixing must have not only an incredible map of the project and how it is put together, but the ability to reach into annotated examples in the past and refer to them as it goes about a fix.
I’m seeing that frontier models will not follow intended patterns or know when to deviate if their primary charge is “fix this bug.”
It is perhaps a better idea to have agents’ primary job be “maintain this codebase” and one way that they do it is to fix bugs, and “oh by the way here is a bug.”
(Performance can be part of 'correct', and can be just as hard to actually get right in specification!)
So the amount of new code added is limited by processes and product management. Add to that that newly added code can get a lot more checks on it now, and new code will be more secure too.
I also don't think your main premise (adding holes faster than we can find them) holds up, but that's another matter. TL;DR I think we're in a high intensity period right now, but this time next year it'll be quiet in comparison - possibly quieter than before AI code scanners were a thing.