A financial services company adopted Cursor recently and almost immediately found itself facing a number that should give any engineering leader pause: it went from producing 25,000 lines of code per month to 250,000. A 10x productivity gain. On paper, that sounds exactly like what the promise of AI-powered programming should deliver.
The reality was a backlog of a million unreviewed lines of code.
That story — reported this week by The New York Times — captures something I’ve been watching develop for months. The coding AI boom didn’t eliminate the hard work of software development. It relocated it. The bottleneck didn’t disappear; it shifted downstream, from writing code to reviewing and securing that code. And most engineering organizations aren’t prepared for what arrived at all.
The Bottleneck Moved — And Nobody Was Ready
For decades, the constraint in software development was writing speed. Engineers were expensive, careful, and slow by necessity. Maybe you produced a few dozen bulletproof lines of code per day. The review process scaled to keep pace with that rhythm.
AI agents changed the fundamental equation. Tools like Cursor, Claude Code, and OpenAI’s Codex — especially after significant capability improvements in late 2025 — can now generate entire features, refactor entire codebases, and produce production-ready implementations in hours. The result is that teams can ship dramatically more code than they ever could before.
But the code being written still needs to be reviewed. It needs to be tested. It needs to be audited for security vulnerabilities. And those steps haven’t been automated anywhere near the same rate as code generation.
Joni Klippert, CEO of StackHawk, described the financial firm’s situation bluntly: the sheer volume of code delivered, and the corresponding surge in vulnerabilities, is something the team simply can’t keep pace with. And the downstream effect extends beyond engineering — when software development accelerates this dramatically, it creates pressure on sales, marketing, and customer support teams to match that pace. The stress ripples across the entire organization.
The AppSec Talent Crisis Is Now Acute
The security dimension of this problem is what concerns me most. The role responsible for catching defects in AI-generated code — the application security engineer (AppSec) — is already in desperate shortage. Joe Sullivan, advisor at Costanoa Ventures, put it plainly to the Times: there simply aren’t enough application security engineers on the planet to meet what just American companies need right now.
StackHawk’s own survey of AppSec stakeholders found that 87% of organizations have already adopted coding AI tools to some degree, and more than half — 53% — consider them a moderate or significant security risk. When asked about their biggest challenges for 2026, “keeping pace with development velocity and AI-generated code” was the most cited concern.
This is the tension that defines where we are: the same tools driving productivity are creating a security surface that expands faster than organizations can instrument it. Meanwhile, AI is also introducing entirely new classes of vulnerabilities — prompt injection, context poisoning, guardrail bypasses — that traditional AppSec tools weren’t designed to detect.
“Now Everyone Inside Your Company Becomes a Developer”
There’s another dimension to this that gets less attention: the democratization of code production. Michele Catasta, CEO of Replit, framed it well: with AI tools, anyone in the organization — not just engineers — can build a software idea in a matter of hours.
That’s genuinely interesting. It unlocks creativity and autonomy across all teams. It accelerates prototyping. It means a product manager or financial analyst can build a functional tool without waiting months for engineering resources.
It also means code is being created by people who may have no training in security, reliability, or systems design. Open source projects, which depend on voluntary contribution and community review, have been flooded with AI-enabled submissions. The curation burden became overwhelming.
Andrew Bosworth, CTO of Meta, noted in an internal memo that projects that once required hundreds of engineers can now be done with dozens, and work that took months can now take days. He’s right. But shrinking the engineering team while simultaneously scaling code production is a formula that puts enormous pressure on whoever’s left to do the review.
What the Industry Is Building in Response
The market is beginning to react. Cursor launched Automations in early March — a system of always-on agents that fire automatically when new code is committed, running security audits and bug reviews without an engineer needing to kick them off. It’s an acknowledgment, from one of the leading coding AI platforms, that the review problem is real and needs systematic solutions.
AI code review tools — CodeRabbit, Greptile, Qodo, Snyk Code — are seeing accelerated adoption. Repositories using AI-assisted review show faster merge times and fewer post-merge defects. These tools are becoming a necessary layer between AI-accelerated code generation and production deployment.
But these tools are force multipliers, not replacements for human judgment. They handle repetitive patterns and flag non-obvious risks. They don’t own intent, trade-offs, or systems design. And even the best AI reviewers have hard limits: they become overconfident when context is incomplete, and they generate noise that erodes trust when miscalibrated.
What Engineering Leaders Need to Be Thinking About
The code overload problem isn’t an argument against coding AI tools. They’re too productive, too transformative, and too widely adopted to treat as optional. But it is an argument that the adoption conversation has been incomplete.
Most coding AI deployments have been evaluated on a single metric: how fast can we ship? That’s the wrong frame. The right frame is: what does it do to our review capacity, our security posture, and our ability to maintain what we build over time to ship 10 times more code?
Senior engineers with the experience to catch bugs and monitor systemic risks are more valuable now, not less. Investment in AppSec needs to scale alongside coding velocity, not lag behind. And organizations need to be honest about the fact that when you give everyone in the company the ability to produce code, you’re also extending your attack surface to every team that decides to use that capability.
The software factory didn’t break because coding AI tools failed. It broke because the rest of the factory wasn’t ready for what those tools were going to produce.
Is your team already feeling the pressure of code overload? How are you handling review and security at this pace? Let us know in the comments. 