Software engineering leaders have invested heavily in generative AI coding assistants for over two years—and for good reason. For many teams, the productivity gains appear significant. I hear the same story in conversations with leadership at dozens of enterprises: thanks to AI, developers complete tasks faster, write more code, and spend less time on boilerplate activities.
But I am also seeing a potentially dangerous paradox emerging; perhaps a new kind of technical debt, and a danger that you will experience at an accelerated pace (acceleration being the true hallmark of everything AI). While individual productivity is soaring, overall throughput, meaning the rate at which secure, stable, production-ready code is deployed, is stagnating or even declining in many cases.
The reason is a simple but costly equation: a significant percentage of AI-generated code contains vulnerabilities. AI-assisted code always looks correct on the surface (a hallmark of generative AI, which is trained first and foremost to appear correct, whether or not it is correct). But hard-to-detect vulnerabilities in AI-assisted code create bottlenecks in the CI/CD pipeline where the time saved in writing the code is lost or even outweighed by the ensuing security-driven regressions, failed builds, and remediation cycles.
This is a high-friction environment for application development where security teams, already stretched thin, can drown in a firehose of new alerts triggered by AI-generated vulnerabilities. Developers, in turn, grow frustrated as their velocity is throttled by a security model that feels punitive, rather than collaborative.
A “Shadow AI” Problem
In some organizations, the initial reaction has been to restrict or tightly control AI tool usage. The benefits are too compelling for developers to ignore, and they will simply use AI on their own, regardless of whatever policy their organization sets.
This is the worst of all possible worlds. Not only is insecure code still being introduced, but leadership now has zero visibility or control over which tools are being used. This complete loss of governance is a compliance and security risk that far outweighs any perceived benefit of a ban.
A Solution: Security Enters the IDE
For years, the industry mantra has been “shift left,” the move of security testing from production into the CI/CD pipeline. But the AI boom might make that model insufficient (at an accelerated pace, of course), because a post-commit scan is already too late if the code is unnoticeably compromised from the start. The productivity gain was already lost at the point of creation.
A better code security paradigm might be “shift all the way left”: move security validation from the repository into the developer’s integrated development environment (IDE) itself. Let’s get security collaborating with the AI assistant and the developer in real time.
This is more than just a workflow tweak; it’s a fundamental change in cognitive load. A post-commit scan that finds a flaw forces a developer to stop, context-switch back to a task they thought was “done,” and try to fix a problem they no longer have top of mind. An in-IDE validation agent, by contrast, provides an immediate, in-context suggestion, often before the vulnerability is even in production. It also turns security from the classic Department of No into a pretty seamless development partner. In this model, validation doesn’t happen after the work is done; it happens as the code is being generated.
Intercept insecure code at its point of origin, and you should transform raw developer productivity into secure and effective business throughput.
Five Questions Engineering Leaders Can Ask
As you navigate the use of AI coding tools, consider your approach within an in-IDE paradigm. Ask yourself and your teams:
1. How will we validate AI-generated code before it’s committed?
If your only guardrail is a post-commit scan, you’re risking starting behind. Real-time, pre-commit validation is more than just a feature; it’s a newly achievable requirement for securing an AI-powered software development lifecycle. Catch flaws at the point of creation and reject the risk of the higher costs of finding and fixing them later.
2. Can we see and control which generative AI tools our developers are using?
Obviously, a policy that only covers your officially sanctioned AI assistant is blind to the reality of shadow AI. Visibility across all tools, official or not, is important because you can’t secure what you can’t see. This visibility is the prerequisite for any meaningful governance, allowing you to set guardrails that apply equally to all tools.
3. Do our security policies extend into the AI assistant itself?
Traditional static policy checks are easily bypassed by AI tools. From data handling to open-source licenses, make sure you know how your policies will be enforced at the moment of code generation, not just at scan time. You want your policies to actively guide the AI in generating code that is compliant from the start.
4. What’s our plan for unsafe package recommendations and refactors that have a wide blast radius?
AI assistants are notoriously proficient at suggesting outdated or vulnerable packages. A seemingly small, helpful suggestion can have a massive ultimate effect with the potential to break security at scale. This is one of the most insidious AI risks, given the AI model training point of outputs that look correct and trustworthy. To prevent any one AI-fueled commit from breaking an entire application, you should know the potential size of the blast radius and enable safe refactoring.
5. How will we measure developer adoption and ROI?
The inevitable, classic question in IT applies here as well. Security that slows developers down is highly likely to be bypassed or ignored. Developer adoption rates, reduction in mean time to resolution, SLA adherence, and, most importantly, developer throughput—not code commits but code in production—are good success metrics. In “shift all the way left,” the security tools that work are the ones developers are using, and they will only use them if they add value to their work without adding friction.
The era of reactive code security is probably beginning to end. At the very least, the challenge is no longer if we use AI but how we will govern its use. The most successful organizations will retreat from the game of policing their developers and into the business of empowering them with the tools to code securely and rapidly from the very first line.
