Architecture beats vigilance: building security review into AI-assisted development

More of the code reaching production today is written by AI, and the security question that it raises as a result is not going away any time soon. Merely telling developers to be more careful is a weak control: as attention will naturally be focused on the changes that look most difficult. In a study of the security of LLM-generated code, the strongest results came from a different approach: putting AI to work defensively, reviewing the code before a human ever looks at it.

The risks are found where you least expect them

I compared three ways of building the same 100 tasks with the same model, using the kind of public tutorials that teach non-programmers to build apps with AI. The first was naive vibe coding: simple plain-English prompts and nothing else.

I had expected this more straightforward work to be safer. In fact, it was quite the opposite: simple products carried 19 vulnerabilities per thousand lines of code as opposed to 2 for complex ones: over nine times higher. 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, and the smallest prompt often holds the largest set of unstated assumptions.

Expertise helps, but it must be present

The second condition kept the same tasks but added security requirements to each prompt, drawn from the OWASP Top 10 and the MITRE (Common Weakness Enumeration) CWE categories relevant to the task. This simulated a developer who knew the risks and made them explicit.

It worked: vulnerability density fell by 60%, and applications with a critical or high-severity vulnerability dropped from 78% to 44%. The catch: security-aware prompting depends on the right knowledge being supplied at the right moment, by someone who possesses it; change after change, under true delivery pressure.

A reviewer built into the workflow

The third condition I used removed that dependency. The same plain-English prompts went into an agentic workflow with three roles: a supervisor to coordinate, a coder to implement, and a security reviewer to assess the code and either accept it or send it back for another iteration, up to five times. The security came from the review architecture itself, not from the user supplying their expert guidance.

The results were the strongest in the study: vulnerability density fell from 13 to 3 per thousand lines of code, a 77% reduction from baseline, and applications with a high-severity vulnerability fell from 78% to 28%. The workflow eliminated the cross-site scripting and code-injection findings seen in the previous rounds and was the most consistent across its applications.

It also flattened the complexity paradox. Under vibe coding, simple products had around nine times the vulnerability density of complex ones; under the agentic workflow, that ratio was 1.25. The reviewer applied similar scrutiny whether a task looked easy or difficult: the kind of consistency organisations need if they are going to trust routine work to agentic deployments.

What this proves

It would be an overstatement of the claim to say this single-model study proved an agentic workflow always beats an expert developer. The more discreet and useful conclusion would be that an automated review gave significant, consistent protection against the naive baseline, and supports the concept of building integrated security agents into the workflow. It certainly does not remove the need for human judgement, runtime testing or independent assurance, or define how organisations maintain meaningful human oversight as more of the pipeline is routed to autonomous agents.

Consistency is an architectural property

People know security matters. They work under deadlines, switch context and make reasonable calls about where to spend their limited attention. Telling them to simply be more vigilant doesn't change those constraints. But architecture can.

Platform teams already encode engineering decisions into Continuous Integration (CI) pipelines, deployment controls, dependency policies and service templates. AI-assisted security review belongs there too: a control that checks routine changes, returns insecure code for revision, and sets a consistent minimum level of scrutiny before any human review.

It needs careful implementation though, giving thought to what the agent can change, how its findings are validated, where human approval stays mandatory, and how generated fixes will be tested. An automated reviewer treated as infallible likely introduces its own false confidence. Responsibility stays with the team, and good architecture makes the responsible action the normal path through the system.

What this means for security and engineering leaders

For teams already running agentic pipelines, or about to:

Treat AI code review as an architectural control, built into the pipeline to run on every change.

Decide the reviewer's authority in advance: what it may accept, what it must escalate, and where human sign-off is mandatory.

Validate the validator: test its findings against known vulnerability classes on an ongoing schedule so its scrutiny remains strong.

Keep runtime testing and independent assurance in place: automated reviewers reduce the problems before human review; but will not solve them all.

Build security into your systems, not simply by asking for it.