When Developers Ship 50x More Code, Security Becomes the Traffic Jam
AI coding assistants are pumping out software at a pace human security teams were never built to match. Nobody's quite sure what got shipped.
Key points
- AI coding tools are letting development teams produce 10 to 50 times more code than before.
- Security teams still review that code at human speed, creating a growing backlog of unchecked software.
- The risk isn't only missed bugs but losing track of what has actually been released.
- Vulnerability triage, dependency scanning, and fix prioritisation are the specific tasks under strain.
- Firms that don't rethink their security workflow risk shipping insecure code by default.
Something odd is happening in software teams right now, and it isn't the kind of story that comes with a flashy zero-day.
Developers using AI assistants are producing code at 10 to 50 times their previous pace. That's not a figure from a vendor deck. It's what teams are quietly reporting once the tools bed in. The security side of the house hasn't sped up at all.
Why does this matter to anyone outside a dev team?
Because the software you use every day, your banking app, your GP's booking system, the shop till at your local cafe, is written by these teams. If the people checking that code for flaws can't keep up with the people writing it, insecure software ships.
When one side of a process runs 50 times faster than the other, the slow side stops being a check and starts being a bottleneck. Or it gets bypassed entirely because waiting for it would kill the release schedule.
What exactly are security teams trying to do?
Four unglamorous jobs. They review new code for vulnerabilities, meaning weaknesses a criminal could exploit. Dependency management, the tracking of third-party building blocks a piece of software pulls in from elsewhere, is another. Then there's fix prioritisation, deciding what to patch first when bugs outnumber hours, and controlling what actually gets released.
Each of those tasks was already stretched before AI coding assistants arrived. Our 21 July story found an average of 15 security flaws per project across 16 major AI coding assistants, and that was before the throughput question got this sharp.
The familiar comparison from web security is useful here. This is the same shape of problem as the shift from waterfall releases to continuous deployment a decade ago, when weekly releases became hourly ones and manual security review broke. The industry responded with automated scanning in the pipeline. That response took years. AI-assisted development didn't give anyone years.
So is this a new class of attack?
No, and that's worth being clear about. The vulnerabilities being introduced are the same categories we've known about for twenty years: injection flaws, broken access control, leaky dependencies, hardcoded secrets. What's changed is how fast they enter the codebase and how little of that code any single human has read.
There's a second, quieter risk. When AI writes a lot of the code, the humans who nominally own it may not fully understand what it does. That's a governance problem before it's a security one. You can't patch what nobody remembers writing.
Should you worry about the tools meant to catch the bugs?
Yes, a little. Our 21 July report found that more than 60% of flagged security flaws are noise, and AI-assisted scanning makes that worse by lacking the context to tell a real threat from a ghost. Pile that on top of a 50x volume increase and the triage burden becomes genuinely unmanageable without structural change.
What should ordinary users take from this?
Not panic. Just realism. Expect more security updates from the apps you use, and install them promptly. If a company you deal with suffers a breach and blames "a vulnerability introduced during rapid development", that phrase now has a specific meaning.
For teams inside these companies, the fix isn't to slow developers down. It's to raise the security side to something closer to the same speed: automated review in the pipeline, dependency scanning on every commit, and a clear human check on what actually leaves the building.
Otherwise the bottleneck wins, and it's not on the side you want winning.
