Writing code has never been easier, with Large Language Models (LLMs) able to turn simple, natural language prompts into bug-free functions, but as this niche market starts to heat up, new research warns that software developers are inviting unnecessary risk into their code by using AI to do the heavy lifting.

Generating code using natural language descriptions based on ‘feel’ rather than formal planning, or ‘vibe coding’, is taking off among the programming community, something that the big developers haven’t failed to notice.

A study from one of the world’s leading AI outfits, Anthropic, showed that computer programmers, systems software developers, and application devs account for the lion’s share of tasks sent to its AI model, Claude, while OpenAI has already released Codex CLI, an open-source coding agent capable of turning natural language into working code.

However, new research from Backslash Security has found evidence that the most popular LLMs on the market produce insecure code by default, and often fail to address even the most common weaknesses.

In a study of seven current LLMs including OpenAI’s GPT, Anthropic’s Claude and Google’s Gemini, Backslash generated code for everyday scenarios before the output was measured by its resilience against ten Common Weakness Enumeration (CWE) use cases.

The results carried a common theme, with all the tested LLMs generally producing insecure code by default.

Responding to simple, ‘naive’ prompts which asked for code but without specifying security requirements, essentially just ‘make sure you are writing secure code’, the AI models all generated output vulnerable to at least 4 out of the 10 common CWEs.

Prompts that specified a need for security gave more secure code, and prompts that requested code that complied with Open Web Application Security Project (OWASP) best practices produced even better results, although both still yielded some vulnerabilities for five of the seven LLMs tested.

Only prompts that were explicitly told to address specific CWEs resulted in code that is secure and not vulnerable to the tested vulnerabilities.

For those using GPT for their vibe coding, the outcome was particularly bad. 

Backslash’s results found that OpenAI’s GPT-4o had the lowest performance across all prompts, scoring a 1/10 secure code result using ‘naive’ prompts, and even when prompted to generate secure code, it still produced insecure outputs vulnerable to 8 out of 10 issues, with GPT-4.1 not faring much better with only 10% of outputs free from vulnerabilities.

Among the genAI tools, the best performer was Claude 3.7 Sonnet, which scored 6/10 using naive prompts and a perfect 10/10 with security-focused prompts.

Recommended reading

• Could DeepSeek Topple the US’s AI Market Dominance?
• Is the UK Lagging Behind in Global AI Race?
• UK Gov Partners with Anthropic, Focuses on AI Security

Despite these results, Backslash said it was still optimistic that secure-by-design AppSec was possible even as more devs turn to vibe coding, but that this needs to be accompanied by the right system of detailed prompts and guardrails.

Getting in on the ground floor, while developers are still learning prompt engineering themselves,  could even mean embedding best practices for years to come, with vulnerability-free code becoming the norm.

“For security teams, AI-generated code – or vibe coding – can feel like a nightmare. It creates a flood of new code and brings LLM risks like hallucinations and prompt sensitivity,” said Yossi Pik, co-founder and CTO of Backslash Security. 

“But with the right controls – like org-defined rules and a context-aware MCP server plugged into a purpose-built security platform – AI can actually give AppSec teams more control from the start.”