Vijay Raina stands at the forefront of enterprise SaaS technology, bringing a wealth of expertise in software design and architectural integrity to the table. As an expert who has watched the rapid evolution of development tools, he offers a unique perspective on the intersection of productivity and security. In this discussion, we explore the sobering reality of AI-generated code—specifically why nearly half of it fails security benchmarks. We delve into the psychological “trust gap” that leads developers to overlook critical flaws, the statistical plateau in model safety despite rising intelligence, and the actionable strategies teams must adopt to ensure that the speed of AI doesn’t come at the cost of catastrophic vulnerabilities.
Many developers are finding that AI-generated code looks incredibly professional and runs perfectly, yet it often hides serious security flaws. Based on your observations, why is there such a massive gap between the appearance of the code and its actual safety?
It is a deceptive phenomenon that I like to call the “aesthetic trap.” I recently saw this play out with a junior developer who was thrilled that Copilot helped her finish an entire admin dashboard in just one afternoon—a task her lead had originally budgeted for three full days. The code was formatted beautifully, it passed every functional QA test, and it read like something a seasoned professional would write. However, six weeks later, a pentester discovered that anyone logged into the system could view every customer’s full billing history just by changing a single digit in the URL. This happened because the model didn’t understand the nuance of role-based access control; it just provided code that “worked.” We are currently seeing a reality where approximately 45% of AI-generated code includes at least one known security vulnerability, such as SQL injection or weak cryptography. The model isn’t trying to be insecure; it’s simply predicting the most probable next token based on its training data, which often includes “quick and dirty” solutions from public repositories where the primary goal was just to get the feature running.
Looking at the data from the last couple of years, why have AI models improved so much in their ability to solve complex programming problems while their security pass rates remain essentially stagnant?
That is the most counterintuitive part of the recent research, particularly the extensive testing done by Veracode. They tested over 100 LLMs across 80 different programming tasks in four languages and found that while the models got much smarter at solving the logic of a problem, the security pass rate has hovered around 55% since 2025. It’s a startling plateau that suggests model intelligence and security awareness are not on the same trajectory. When a model generates code, it isn’t asking itself, “Is this secure?” It is looking at the probability of what comes next based on GitHub repositories, tutorials, and old Stack Overflow threads. Because much of that training data was written by developers who were just trying to meet a deadline, the AI merely adopts our own historical bad habits. It hasn’t learned to innovate new flaws; it is just incredibly efficient at replicating our existing ones. We’ve reached a point where the model typically knows the “what” of a task—with about 61% of generated code being functional—but it fails to understand the “how” of preventing exploitation, leaving about 10.5% of its output wide open to attackers.
There seems to be a significant psychological shift occurring in engineering teams where trust in AI is actually decreasing the quality of the final product. How do you address the fact that developers using AI feel more confident while producing less secure work?
This is a profound issue of misplaced trust that transcends technical specifications. A study comparing developers coding with and without AI assistance found that the AI-aided group actually wrote less secure code, yet they felt their work was significantly more secure than the control group. This happens because the tool provides something clean and well-formatted, which tricks the human brain into assuming the logic is equally polished. When you combine this false confidence with the sheer speed of modern development, you get a dangerous cocktail. Teams using AI assistants are now shipping commits three to four times faster than they were previously, but the data shows that security findings are increasing at about 10 times the rate of those commits. We are essentially burying our security teams under a mountain of code that has been reviewed with the same level of scrutiny as before, even though the volume and risk have exploded. The “it works” sentiment has become a shield that prevents us from asking the much more important question: “Can this be broken?”
Since AI tools are clearly here to stay, what practical changes should teams make to their workflows to catch these vulnerabilities before they reach production?
The most immediate “needle-mover” is surprisingly simple: you have to explicitly ask for security in your prompts. In one specific test, a model produced only 6 out of 10 secure outputs when given a plain prompt, but it hit a perfect 10 out of 10 when specifically instructed to produce secure code. The capability is often there, but it’s dormant because we usually prioritize “make this work” over “make this hard to break.” Beyond prompting, we are seeing better results from reasoning models that work through problems step-by-step; these show a pass rate of about 70–72% compared to the 55% baseline. However, even with these better models, a 30% defect rate is still far too high for a production environment. This is why a second pair of eyes is mandatory. Whether it’s a human peer or a static analysis tool, the reviewer must be independent of the model that wrote the code. A model is structurally incapable of detecting its own blind spots because those flaws are baked into its training data. We must treat AI code as a high-speed drafting tool, but never as the final word on safety—especially in sensitive areas like authentication, payments, and user permissions.
What is your forecast for how the relationship between AI and application security will evolve over the next few years?
I believe we are heading toward a period of necessary friction where the industry will have to reconcile its obsession with speed with the cold reality of these 45% failure rates. We won’t stop using AI—the productivity boost is simply too massive to ignore, and a huge percentage of the code on GitHub is already being shaped by these tools. However, the distinction between “it compiles” and “it is safe for customers” will become much more formalized in our pipelines. I expect to see the rise of “security-first” AI agents that are specifically trained to act as adversarial reviewers, essentially playing a permanent game of cat-and-mouse with the generation models. My advice for readers is to maintain a healthy skepticism: just because the code arrived in an afternoon and looks professional doesn’t mean it won’t leave your front door wide open. We have to stop trusting the “cleanliness” of the syntax and start auditing the “safety” of the logic with ten times the intensity we used in the manual coding era.
