Thank you for opening up the latest article in 'The Intelligent Commit' newsletter, my thoughts, research and analysis on Artificial Intelligence and how AI is reshaping the software development lifecycle. I hope you find it insightful, subscribe, and engage.

Whether as a consumer, a practitioner, or a simple observer, no one has escaped the rapid technological advancement of AI, especially Generative AI and code generation. At the turn of the year, I completed research for my Master's in Artificial Intelligence, and yet there was a strange feeling as I observed the industry moving faster than the ink could dry. Even earlier, as I analysed the data, considered findings, and typed up the paper, I often sat at my keyboard wondering if it was even relevant any more.

I handed in my research on AI code security in January 2026 offering my recommendations to tool vendors. By late February, Anthropic had launched Claude Code Security. Two weeks later, OpenAI followed with Codex Security. The research question I'd mulled over a year ago and then spent months investigating, coding, and testing had become a product category.

So in this article, I want to explain why that matters, what these tools actually are, and why I think framing as 'better security tooling' undersells what's going on.

Insecure code is not a new problem, and it is not exclusively an AI problem.

The headlines about vulnerabilities in AI-generated code are grim-reading. Yet insecure code is not a new problem, and it is not exclusively an AI problem.

Veracode reported back in 2020 that more than 75% of applications have at least one security flaw (rising to over 80% of applications in their most recent study that found over half of applications are carrying a critical or high vulnerability). Open source vulnerabilities survive undetected in production for more than four years on average and the 500 bugs that Anthropic's team recently found in widely-used open source projects weren't written by AI. They were human code that had outlasted decades of expert review and millions of hours of automated scanning.

We've all contributed to these stats; I know and admit I have. Developers of all experience levels have and will continue to write insecure code, whether that's through a lack of secure code training, peer reviews, or a pair to work alongside, being under pressure to deliver on time, no access to tools, or any number of other reasons. Insecure patterns get copied from documentation, tutorials, and Stackoverflow, the software developer's bible of its time; third party dependencies accumulate silently and age quickly; and data flow and integration flaws emerge between components that individually look fine.

This has always been true, and it has always been hard.

Many academic and industry studies report upward of 45% of AI-generated code contains vulnerabilities.

Fast forward to 2026, where AI code assistants are increasing the volume of code being written and the speed at which it enters production. Indeed, AI-generated code now makes up roughly a quarter of production codebases, and rising. Multiple studies have found that LLM-generated code carries a significant number of security flaws and at a higher rate than human-written code, with Aikido Security's 2026 survey reporting that one in five organisations had already experienced a serious security incident they attributed to AI-generated code.

Veracode tested over 100 large language models across 80 coding tasks and found 45% of AI-generated code introduced vulnerabilities from the OWASP Top 10, a finding confirmed by numerous other independent and academic papers, including my own empirical research. Critically, larger closed models have been found to perform no better than smaller open ones, meaning this isn't a capability problem that the next model release will likely solve. Models mostly optimise for functional correctness evals, and functional correctness and secure are not the same thing.

Security debt now affects 82% of companies, up from 74% a year ago, and more vulnerabilities are being created than are being fixed. While the problem is real, growing, and predates AI, it is clear the problem now has a new shape.

More code, more alerts, more noise, less signal.

Static analysis (SAST), the backbone of application security testing for decades, is more sophisticated than it's often given credit for. Modern tools can trace data flows, analyse control paths, and flag dangerous patterns across function boundaries. For whole classes of well-understood vulnerability, they're fast, consistent, and reliable.

But what they cannot do is reason like a security analyst or think like a red-teamer. They can identify that a pattern matches a known class of problem, but they cannot form a hypothesis, follow a chain of business logic, or ask whether a particular behaviour makes sense given everything else they've read. The consequence of context-blindness shows up in the noise. Research consistently finds that the majority of SAST alerts are false positives or irrelevant to the actual vulnerability; some studies report this may be as high as 76%. Teams soon learn to tune out the noise, burying the real findings with it.

More code, more alerts, more noise, less signal. That's the pattern the industry needs to address.

Reasoning-based security tools that validate their findings before surfacing them represent a fundamentally different working model, not just a different detection method.

In February, Anthropic launched Claude Code Security. Last week, OpenAI launched Codex Security. Both tools reason about code rather than scan it. Where a traditional tool traces a data flow and asks whether it matches a known pattern, these tools ask whether the behaviour makes sense, forming hypotheses, following chains of logic, and interrogating the relationships between components, just like a security researcher would.

Claude Code Security was built on more than a year of red team research, including competitive Capture the Flag events and work on critical infrastructure defence. They found over 500 vulnerabilities in production open source codebases, bugs that had survived decades of expert review and could not be caught with traditional techniques.

Codex Security takes a similar approach with an important structural addition. Before running a single scan, it builds a project-specific threat model, mapping what the system does, who it trusts, and where it is most exposed. Vulnerability search happens inside that context, which means findings are ranked by actual real-world impact rather than theoretical severity. In its private beta, it achieved an 84% reduction in alert noise, a 90% drop in over-reported severity, and more than a 50% reduction in false positives.

Solving the false positive problem matters more than it sounds. Engineering teams don't tend to abandon tools because they miss things; but they absolutely do when the noise becomes unmanageable. Ask anyone on call overnight dealing with tens of alerts from misconfigured, overly-sensitive thresholds in their observability toolsuite.

Reasoning-based security tools that validate their own findings before surfacing them change the working model as well as the detection method.

The structural difference between a system that reviews its own output and one that doesn't is significant.

My research found something consistent with this. An agentic workflow with automated security review reduced vulnerability density in AI-assisted code by 77%, and eliminated cross-site scripting and code injection vulnerabilities entirely, both categories that security-aware prompting alone couldn't reliably remove.

What this means for Engineering leaders

This isn't a conversation that belongs only in your security team. If AI is writing significant portions of your codebase and traditional tooling isn't equipped to evaluate what AI writes, the governance question lands squarely in your leadership.

VentureBeat interviewed more than 40 CISOs following Anthropic's launch three weeks ago. Not surprising that formal governance frameworks for reasoning-based security tools were the exception; and yet, while most CISOs said the capability arrived earlier than they expected, as technology leaders we need to be ready with our response very soon. Agentic AI security is a new product category, and the tools, workflows, governance models, and security posture organisations build around it need to reflect that.

Remember though -

  • These tools complement your existing stack, they don't replace it. SAST tools catch known patterns reliably. Reasoning-based tools catch what pattern-matching misses. Use both, and in that sequence.
  • Human approval stays in the loop. These tools are amplifiers for security teams, not replacements for them.
  • Finally, the same reasoning capability that defends your code is now readily available to attackers.

Thank you for reading my latest article. Please share your experiences and engage with the discussion. I am not always right, but I try to be insightful and thought-provoking.

  • Are you struggling with quality and security of LLM-generated code?
  • Does your experience match the studies and research?
  • What is your opinion of modern SAST tools and how do you think Agentic AI Security tools will affect your workflows in the future?

Please reach out if you'd like to continue the discussion.