NCSC vibe coding spectrum: reviewing AI-assisted code

A growing share of the pull requests we review were written, at least in part, by an AI assistant. Sometimes the author tells us. Often they don’t need to. The question we’re asked most is whether that should change how code is reviewed. The short answer is yes, and the NCSC has just given us a useful way to explain why.

The NCSC’s position

In March 2026, the NCSC’s chief executive Richard Horne used his keynote at the RSA Conference to argue that “vibe coding” is an opportunity as well as a risk:

The attractions of vibe coding are clear, and disrupting the status quo of manually produced software that is consistently vulnerable is a huge opportunity, but not without risk of its own.

In June, the NCSC followed up with a blog post describing a vibe coding spectrum. At one end, you write the code and your editor offers AI-powered autocomplete. At the other, you give a high-level prompt and the AI has autonomy over the architecture, code, modules and tests. Most real work sits somewhere in between.

The NCSC’s advice is to decide where to sit based on what’s at stake. Slide towards writing it yourself for authentication and authorisation logic, sensitive personal data, secrets and credentials, and safety-critical systems. Slide towards the AI for prototypes, demos and internal tools with no sensitive data. And for security-critical code, the NCSC is explicit that you must review what the AI produces, understand the code, check for vulnerabilities and verify it does what you expect.

The risk, in other words, isn’t using AI. It’s using it without safeguards where the stakes are high.

How we review AI-assisted code

Here’s what that looks like in practice for us:

• The author must understand every line. If the person opening the pull request can’t explain why the code works, it isn’t ready for review, whoever or whatever wrote it. “The AI did that part” is not an answer.
• Smaller pull requests. AI makes it easy to produce a thousand lines in an afternoon. Nobody reviews a thousand lines well. We ask for changes to be split so each can be read properly.
• Check every new dependency exists and is the one you meant. AI assistants sometimes suggest packages that don’t exist, or names that are close to a real one. Attackers know this, and register those names. A new line in a manifest or lockfile gets the same scrutiny as new code.
• Tests written by the same tool prove less. If the AI wrote the code and the tests together, they can share the same misunderstanding. For anything that matters, a human decides what should be tested, especially the failure cases.
• Look for secrets and shortcuts. Hard-coded keys, disabled certificate checks, overly broad permissions and “temporary” debug endpoints are all things generated code is happy to include to make something work.
• Match the review to where the code sits on the spectrum. A throwaway prototype gets a quick look. A login flow gets two reviewers and a threat model, regardless of how it was written.

The NCSC notes that you could use another AI agent to help with that oversight, and we do. Automated review catches a lot. But a person stays accountable for what gets merged, and for code on the left of the spectrum, that person needs to have actually read it.

Designing for mistakes

The NCSC makes one more point that’s easy to miss: architect the wider system around your code to minimise the impact if it is exploited. That was good advice before AI, too. Least-privilege access, separated environments, secrets kept out of code, and logging you’d notice something in all limit how far one bad line can reach, whoever wrote it.

Sources

• NCSC, The “vibe coding spectrum” approach to AI-assisted software development (June 2026)
• NCSC, NCSC CEO: seize “disruptive” vibe coding opportunity to make software more secure (March 2026)
• NCSC, Secure development and deployment guidance