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.
This is the final article in a three-part series about the findings from my master's dissertation on the security of LLM-generated code.
For my Master's research dissertation, I chose a subject that sits directly between my studies and my work in engineering leadership: what happens to software security when more of the code is generated by AI? I later turned the research into a talk, The Complexity Paradox, which I presented at the Northern DevOps & Platform Conference in Leeds back in May.
The first article in this series covered an unexpected finding that gave the talk its name: the simplest tasks carried up to 9x the vulnerability density of the most complex ones. The second argued that security expertise is still important, because when I simulated a developer spelling out security requirements, vulnerability density fell by 60%.
The strongest security controls are those nobody has to remember to apply.
However, that depends on the developer knowing what to ask for, and remembering to ask on every single change. As any engineering leader will attest, that is hard to guarantee. So the final part of my research tested whether that knowledge could be taken out of the individual's head and built into the workflow instead. I am a firm believer that the strongest security controls are those nobody has to remember to apply.
Building the reviewer into the workflow
The third condition used the same model and the same 100 tasks, and built the same 18 products as the other two. The prompts were the plain, functional vibe-coding prompts from the baseline, with no security guidance added - mirroring either a non-programmer or a developer who had forgotten their secure-coding training. The only difference was what happened to the code after the LLM first wrote it.
In this condition, three AI agents did the work behind the prompt: a supervisor, a coder and a security reviewer. The supervisor handed the task to the coder. The reviewer then checked the result against the OWASP Top 10 and the CWE Top 25 - the same sources I drew on for the security-aware prompts in part two. If it found problems, the supervisor passed them back to the coder to fix. I capped that loop at two rounds of fixes to keep time and cost under control, after which the task was marked complete.
In part two, a developer had to supply the security knowledge with every prompt. Here it was written once, into the reviewer agent's instructions, and applied to every change.
The impact of an automated reviewer
The proportion of applications containing at least one critical or high-severity vulnerability fell from 78% to 28%.
Against baseline, vulnerability density fell by 77%, and the proportion of applications containing at least one critical or high-severity vulnerability fell from 78% to 28%.
Two classes of flaw disappeared altogether. Cross-site scripting and code injection, both on MITRE's list of the 25 most dangerous software weaknesses, turned up in the vibe-coded applications. Neither appeared once in the agentic ones.
The automated agentic workflow also produced the fewest vulnerabilities per application, and the most consistent results from one application to the next.
It flattened the complexity paradox too. The 9x gap between simple and complex products under vibe coding all but closed under the agentic workflow.
In part one I offered one possible explanation for the paradox: that humans may slow down for work that looks difficult and wave through work that looks routine. An automated reviewer has no such instinct. Nothing in its instructions told it that a small change deserved less attention, so it did not give it less. It applied its protection to every change, however simple it looked.
It would be easy to read this study as "agents beat experts", but I do not think the study supports that. It does not replace human judgement, runtime testing or independent assurance. What it shows is that automated agentic review gives strong protection against the naive baseline, and adds strength in depth alongside a security-aware developer.
It also shows that LLMs are strong at reasoning about code security, rather than looking purely at heuristics - something I wrote about in Agentic AI Security is a new product category - and we have heard a lot about advances in this space in the year since my study concluded, with the Fable model, for example.
What this means for engineering leaders
People know security is important. They also work under deadlines, switch context and make reasonable decisions about where to spend limited attention. Telling developers to be more vigilant does not change those constraints. But a strong architecture can be designed around them.
Platform teams already encode engineering decisions into CI pipelines, deployment controls, dependency policies and service templates. AI security review belongs alongside them. It can look at the routine changes nobody else examines closely, send insecure code back for revision, and apply a consistent minimum level of scrutiny before a human reviewer ever opens the pull request.
That still needs careful implementation. You will have to decide what the agent is allowed to change, how its findings are validated, where human approval stays mandatory and how generated fixes are tested. There is also a risk of false confidence in an automated reviewer whose decisions are opaque and who is treated as infallible. I explored the psychology of trust separately in Do developers know their AI code is insecure?, and it is a fascinating subject.
I reiterate that none of this replaces the findings in the previous article. Security-aware developers still write better prompts, and they are the people who should be writing the reviewer's instructions in the first place. Responsibility for what goes into production must stay with the team.
But if I can leave you with one takeaway, it is this: if security depends on somebody remembering to ask, then it is not part of the system controls - and architecture beats vigilance.
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.
- How much of your security assurance currently depends on a person remembering to apply it?
- If you put an AI security reviewer on every pull request tomorrow, what would you let it change, and where would human approval stay mandatory?
- Who in your organisation would write that reviewer's instructions, and do they have the secure-development knowledge to do it well?
Please reach out if you'd like to continue the discussion.
This concludes my three-part series on the headline findings from my research, drawn from my MSc dissertation at the University of Wolverhampton, submitted in January 2026.