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.

This is the second 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?

AI coding assistants are having a dramatic effect on how developers produce working software. What is less clear is whether the developer's own experience and knowledge - in this case their security expertise - still matters now that an LLM is writing the code. That is what I set out to test, and the answer was a clear yes: a developer who spells out the security requirements gets back noticeably safer code.

Comparing functional and security-aware prompts

Two of the three conditions in my study speak to this directly. Both used the same LLM and the same baseline prompts, and both worked through the same set of 100 tasks, building the same 18 products and end-user applications drawn from public tutorials and videos.

The baseline simulated naive "vibe coding". Its prompts focused on functionality, in the style of those public tutorials aimed at non-programmers building applications with AI - and, just like the tutorials being replicated, they did not mention security or vulnerabilities once.

The security-aware condition kept the same tasks, model and baseline prompts, but appended guidance drawn from the OWASP Top 10 and the MITRE CWE categories relevant to each task. This simulated a developer who understood the likely risks and made those expectations explicit to the LLM.

After producing the applications I scanned the generated code, then reviewed and suppressed false positives before analysing and classifying the vulnerabilities. The difference was significant.

The baseline vibe-coding condition produced 13 vulnerabilities per thousand lines of code. When the developer provided the additional security context, vulnerability density fell by 60%.

The proportion of applications containing at least one critical or high-severity vulnerability fell from 78% to 44%.

And that was not the only significant finding. The proportion of applications containing at least one critical or high-severity vulnerability also fell, from 78% to 44%. For organisations that prioritise remediating critical and high findings - and many do - that is a significant difference.

At this point you may be concerned that your models are writing insecure code at all. I agree, it is quite alarming, isn't it? I did not set out to test or prove that, because it has been heavily researched already - and sadly, yes, it is well established that even the latest frontier models generate insecure code. But without doubt, it is now clear that setting out clear security expectations has a demonstrable positive impact on the code a model produces.

Getting the context right matters

It is tempting to treat prompting as a conversational skill: ask clearly, provide context, refine the answer. For code generation, my study confirmed that the context needs to include the qualities the software must adhere to.

A functional prompt might specify that users can upload a file. A security-aware prompt also constrains file type, size, storage location and filename handling. A request for authentication needs to cover password storage, session behaviour and rate limiting. That extra context comes from secure-development knowledge - just as you would explain it to a junior developer.

A better prompt cannot guarantee secure code, but it can materially improve the odds.

The 60% reduction is encouraging. But while security-aware prompting improved the output, it does not make scanning, testing or code review unnecessary.

It is worth noting that the research community continues to look at this. A twin-prompt study of six web applications found much the same thing - every serious flaw it confirmed sat in the version built from the plain specification, which I covered in Nobody asked for secure code, so nobody got it. A more recent journal paper similarly found that effective prompt engineering reduces vulnerabilities. Yet there is also evidence from another study that adding security guidance to the prompt changed which kinds of flaw appeared without reducing how many there were. What I found in my own research is what I have set out here, but that does not mean the story ends with it.

AI assistance has created another point at which security knowledge affects software. We can leave that knowledge in an individual's head, or we can make it part of the tools and defaults used by the whole team.

The final article in this series examines the next step: moving security review out of prompt guidance and into the architecture of the development workflow itself. If you have not read it yet, the first article covers the finding that gave the series its name.

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.

• Does anyone on your team write security requirements into their prompts today, or is it left to whoever happens to know?
• If you reviewed last week's prompts, how many described behaviour only, and how many described the qualities the code had to hold to?
• Where does that knowledge live in your organisation - in people's heads, in a wiki nobody opens, or in the tooling itself?

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

This is the first 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 title came from the finding I least expected when I began the study, and one I called out in my paper as demanding further research: simple tasks produced the least secure code.

Testing three ways of working with AI

The research compared three simulated development conditions. Each used the same LLM and the same baseline prompts, and each worked through the same set of 100 tasks. Those tasks built 18 products and end-user applications, drawn from scouring public tutorials and videos on product ideas, apps and the like.

The first condition represented naive "vibe coding": simple baseline prompts that described the desired functionality in plain English, and no more.

The second built on each baseline prompt by appending context-relevant, security-aware requirements following OWASP Top 10 and MITRE CWE guidance.

The third fed the original baseline English prompt - with no appended security or technical guidance - into an agentic workflow with separate supervisor, coder and security-reviewer roles.

Eighteen applications in each condition produced 54 applications overall. I scanned the resulting code with Bandit, Bearer, SonarQube and Grype, then reviewed and suppressed false positives before analysing and classifying the vulnerabilities.

There were several useful results, but the relationship between complexity and security stood out. I expected simpler work to generate fewer vulnerabilities. I was mistaken.

Under naive vibe coding, the simple products carried just over nine times the vulnerability density of the complex ones.

Under the naive vibe-coding condition, simple products contained 19.22 vulnerabilities per thousand lines of code. Complex products contained 2.13. The vulnerability density of the simple work was just over nine times higher.

The pattern held under security-aware prompting, where simple work carried 6.3 times the vulnerability density of complex work.

Interestingly, it disappeared in the agentic condition - more on that later in the series.

Why might simple work be less secure?

The study established the pattern, not its cause. The possible explanations are questions for further research, so treat what follows as hypotheses rather than findings.

The simplest answer may be that it is just statistics: complex codebases contain more lines of code, which in turn drives down the density of vulnerabilities. Plausible, but not one I subscribe to on its own. Here are a few more candidates, and how they might translate into the real world.

Attention is one. Difficult work announces itself. Developers slow down, supply more context and examine the results more carefully. A task that sounds routine may receive a short prompt and a quick approval.

Prompt detail may create a similar effect. A request for a complex feature tends to describe its data, behaviour and constraints. "Build a login form" sounds self-contained, yet leaves important decisions about authentication, validation, sessions and error handling unstated.

Training data could also matter. Complex implementation examples may be accompanied by fuller discussion of design and security trade-offs, giving the model a stronger signal than a short example of an apparently basic feature. Those trivial implementations may have been lifted from demo apps and getting-started guides that never went through hardening.

These are plausible mechanisms, not conclusions. The study used one model, one programming language and a moderate sample of products. Replication across models and languages is needed before treating the size of the effect as general.

The practical lesson

Engineering teams naturally concentrate review effort around visibly difficult changes. We bring senior people into complicated designs, write detailed acceptance criteria and expect several rounds of review.

Small changes often travel through a faster path. AI coding tools make that path faster still.

My findings suggest that task simplicity is a poor proxy for security risk. A change can be easy to describe while still touching authentication, data handling or access control. The smallest prompt may contain the largest set of unstated assumptions.

That has implications for code review, for platform defaults and for the way we introduce AI-assisted development. Security checks should follow the risk of the behaviour being implemented, rather than our impression of how difficult the implementation appears.

The tasks we trust most may be the ones we inspect least.

In the second article in this series I explore what happened when security knowledge was added to the prompt. The third examines whether automated reviewer agents can apply that knowledge more consistently.

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.

• Where does your path to production treat "small" as a synonym for "low risk"?
• If a change touches authentication or data handling, does your review process notice, or does it only notice how large the diff is?
• What would it take to route review effort by the behaviour being changed rather than by how difficult the work looked?

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