{"slug": "three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly", "title": "Three Trends in Post-AI Code Security: The Good, the Bad and the Ugly", "summary": "LLMs have cut the cost of code changes and now find vulnerabilities as well as human reviewers, but they have also doubled the number of exploited vulnerabilities since the second half of 2023 and shortened time-to-exploit, according to VulnCheck's State of Exploitation report. The author, an application security professional, warns that vibe coding by non-programmers is expanding the attack surface, while dismissing fears of an imminent explosion of autonomous AI hackers as unfounded.", "body_md": "# Three Trends in Post-AI Code Security: The Good, the Bad and the Ugly\n\nMy day job is application security. I’ve spent a long time looking for ways to weave AI into our processes to make software more secure. Alongside that, I do a lot of security testing of “vibe-coded” projects. LLMs entered our lives so fast that we skipped the step of thinking about what they can and can’t do conceptually, going straight for practical results instead. Output that “looks good enough” has carried us this far. With this post, I wanted to note some of my observations from the past years, as a starting point for a conversation about what we could be doing better.\n\n### The Good: Falling Cost of Change + AI as a Context-Aware Vulnerability Scanner\n\nOne genuinely good change LLMs have brought is the drop in the cost of change. It used to be that rolling out an architectural change to improve security took forever, simply because of the effort involved. Now those changes are far easier to implement, which means it’s easier for us to actually propose them.\n\nThe second good change is how well LLMs spot vulnerabilities in code. Unlike traditional scanners, LLMs search in a context-aware way. They can understand an app’s business logic, compare a feature against similar ones elsewhere in the codebase and flag the deviations. Setting aside how reliable LLM output actually is, I’ve come to think LLMs are now capable of finding almost anything a human reviewer could find. At this point, skipping LLMs for code security is about as reckless as skipping a secret scanner.\n\nPut those two shifts together and you get a clear trend: vulnerabilities get found faster, and fixed faster than before. That’s a win.\n\n### The Bad: A Rapidly Growing Attack Surface + Easier Exploitation\n\nWhen people talk about the productivity gains from AI, the first thing that comes to mind is developers shipping features faster. But that’s actually a slice of the real story. The bigger productivity gain *“idea”* being sold to businesses has less to do with developers coding faster and more to do with non-programmers becoming “vibe coders.” And this isn’t just an increase in code volume. It’s an increase in the number of independent systems being built. Developers use AI to build the systems they’re already responsible for, but vibe coders are spinning up entirely new systems to automate their own workflows. That inevitably drives an expansion of the attack surface.\n\nThe second shift is in how fast and how often vulnerabilities get exploited. We tend to fixate on the growing number of discovered CVE’s. While that growth is real, the more important shift for security teams is that writing an exploit has actually gotten easier. It used to be that exploiting most vulnerabilities was expensive and out of reach for the average attacker’s skill level. Now with LLMs, attackers can find vulnerabilities beyond their own craft and get help writing the exploit code. [VulnCheck](https://www.linkedin.com/company/vulncheck/)‘s [State of Exploitation report](https://wwv.vulncheck.com/hubfs/Research/State-of-Exploitation-1H-2026.pdf) shows this clearly. The number of exploited vulnerabilities roughly doubled starting in the second half of 2023 and has held at that level ever since. The same report shows time-to-exploit narrowing significantly over the same period. In short, the number of newly exploited vulnerabilities each year has roughly doubled and the gap between a vulnerability going public and being exploited has shrunk considerably.\n\nOne AI narrative that doesn’t hold up, though, is the idea that AI is about to trigger an explosion of vulnerabilities, with swarms of autonomous AI hackers descending on us overnight. This narrative gets pumped up constantly to manufacture FUD in the industry, but VulnCheck’s own data shows it just doesn’t match reality. Yes, the raw number of published CVEs has gone up on paper. But vulnerabilities that actually threaten organizations are nowhere near growing at that same pace. That number genuinely doubled in 2023 and has roughly plateaued since. Still, even though we’re a long way from the doom-and-gloom version of this story, it would be a mistake to ignore the trend altogether.\n\n### The Ugly: Disappearing Code Ownership\n\nA huge part of the job in software security is managing trade-offs. Most of the time, developers and systems engineers already know the security vulnerabilities or best practices. Unless something’s genuinely been missed, our job as security people is usually to understand the reasoning behind a design or implementation decision, then work with developers to decide whether the risk we’ve flagged is worth fixing. That’s a trade-off conversation, and it only works if the engineer can actually explain the decision behind their design or implementation.\n\nAs LLM-assisted development has grown, ownership of those decisions has increasingly shifted to AI. That’s a real problem for security. When a trade-off can’t be justified to a developer’s satisfaction, it stops feeling like a conversation and starts feeling like security forcing a change on them. Over time, that constant push for changes erodes trust in the security team and creates friction between teams.\n\nIt gets worse in “vibe-coded” systems built by people with no underlying tech knowledge. Equipped only with the knowledge of their own business domain, vibe coders can only perform functional tests and they’re not aware of what technical decisions need to be made in the first place. AI ends up making all of those calls for them, and the result can be a project that’s nowhere close to production-ready.\n\nThere’s a related problem that hits developers and vibe coders alike. AI quietly implements features the developer never asked for and doesn’t know about. Once your AI-generated code volume gets high enough, manually reviewing all of it becomes impossible. In my pentests, I keep running into the same patterns. There are endpoints developers didn’t know existed, authentication methods that are not in the SPEC, and response data being returned that never should have been exposed. I hate to say it, but this isn’t something better specs can fix. And as code ownership keeps shifting to AI, developers are going to end up not recognizing their own codebase. I’ll leave the security implications of that to your imagination.\n\nSee you in the next one.", "url": "https://wpnews.pro/news/three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly", "canonical_source": "https://blog.predictivedefense.io/p/three-trends-in-post-ai-code-security", "published_at": "2026-08-09 14:05:40+00:00", "updated_at": "2026-08-09 14:10:27.154884+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-policy"], "entities": ["VulnCheck", "State of Exploitation report"], "alternates": {"html": "https://wpnews.pro/news/three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly", "markdown": "https://wpnews.pro/news/three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly.md", "text": "https://wpnews.pro/news/three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly.txt", "jsonld": "https://wpnews.pro/news/three-trends-in-post-ai-code-security-the-good-the-bad-and-the-ugly.jsonld"}}