“Vibe coding” is a useful label for a real shift in software work: describe an outcome, let an AI system produce much of the implementation and review what comes back. The National Cyber Security Centre’s advice is more useful than either enthusiasm or alarm. It says the level of oversight should change with the consequence of failure.
That is the right principle. A disposable demonstration and an authentication service are not the same job, even when the same model can write both. Treating them alike either wastes effort on low-risk exploration or takes unacceptable shortcuts where security matters.
Speed is not the same as assurance
AI can shorten the gap between an idea and working code. It can also introduce plausible-looking flaws, insecure dependencies, confused access controls and assumptions that nobody has tested. The risk is not that generated code is automatically bad. It is that velocity can make review feel optional.
For a prototype with no sensitive data, no public exposure and no consequential decisions, rapid iteration may be reasonable. For code that handles credentials, personal data, payments, safety functions or production infrastructure, the NCSC recommends moving toward stronger human control and established engineering practice.
Classify the work before choosing the workflow
Before a team starts, it should decide what category the work falls into. Consider the data involved, who can reach the system, what permissions the code will have, how hard an error is to reverse and whether a failure could harm someone or expose a protected asset. This is a short risk assessment, not a demand for a heavyweight committee.
The result should change the workflow. Low-risk work may use AI to generate a scaffold, test idea or internal utility. Higher-risk work should require human-authored or closely reviewed design decisions, protected branches, independent testing, threat modelling and a named accountable engineer.
Keep the context boundary tight
Developers should not casually paste secrets, customer data, proprietary source or security-sensitive architecture into an external AI tool. Use approved environments, sanitised examples and clear rules for what may leave the organisation. The same principle applies to tools that can act on a repository: give them narrowly scoped access and keep meaningful changes reviewable.
Version control is valuable here. It preserves the change history, supports review and makes it possible to revert a bad implementation. That is true whether the initial code came from a person, a template or an AI assistant.
Test the behaviour that matters
Generated code should be tested against the risks it introduces, not simply whether it runs. Authentication logic needs abuse cases. Data handling needs privacy and access tests. A public-facing service needs dependency checks, logging, error handling and an incident path. In higher-risk cases, independent review is not a bureaucratic extra; it is how a team discovers what its first pass failed to notice.
AI can also help with testing, but it cannot certify its own output. Evidence should show what was reviewed, which tests were run, what findings were fixed and who accepted the remaining risk.
A spectrum is more honest than a ban
Organisations do not need to choose between “AI writes nothing” and “AI writes everything.” They need a calibrated policy that lets teams move quickly where the blast radius is small and slows them down where the stakes are high. The useful standard is not whether code was generated; it is whether the level of control matched the consequence of being wrong.
Continue the AI governance series
- Human Oversight Is a Workflow, Not a Name on a Register
- From AI Pilot to Production: The Governance Handover That Matters
- View the complete AI Governance in Practice collection