Artificial intelligence is helping developers write code, find bugs, generate tests, and build complex systems faster than ever. At the same time, it can help attackers discover weaknesses, automate attacks, and operate at a scale that was previously difficult to achieve.

The European Commission highlighted this dual role in its July 2026 Action Plan on Cybersecurity and Artificial Intelligence. AI can help detect vulnerabilities and protect critical infrastructure, but malicious actors can also use it to identify weaknesses and conduct cyber operations at unprecedented speed and scale. European Commission

AI, then, is neither inherently a defender nor inherently a threat. The outcome depends on who is using it, how it is being used, and whether anyone is taking responsibility for the result.

The Website That Changed How I Think About AI-Generated Software

Not long ago, I was searching online for a product I wanted to buy. One particular website kept appearing in my Google results. After seeing it several times, I decided to open it.

Something about the site felt familiar. Its colors, component layout, and overall visual style resembled many products built quickly with AI tools. That alone proved nothing, of course. You cannot reliably determine how a website was built just by looking at its design. But it was the first signal that caught my attention.

As I scrolled through the page, the website unexpectedly returned a 500 Internal Server Error. A normal browsing action appeared to have triggered a server-side failure.

That made me wonder: had this product been shipped through a rushed vibe-coding process?

I began looking into the company and its technical team through publicly available information. A large company appeared to be behind the platform, yet the public profiles I found suggested that some members of the development team were still relatively early in their careers.

The problem here is not junior developers. Every senior engineer was once a junior. The real problem is placing a less-experienced team in charge of a sensitive system without sufficient technical supervision, code review, and security controls.

“It Works” Does Not Mean “It Is Secure”

As a developer, I reviewed some of the website’s publicly accessible behavior from a security perspective. I paid particular attention to areas such as file uploads, input validation, and the way requests appeared to be handled.

During that limited review, I identified three critical security issues and two medium-severity issues. If abused, the critical weaknesses could have caused serious disruption and potentially taken the service offline.

What made the situation more concerning was that the platform also handled payment-related and sensitive customer information. In a system like that, a seemingly small mistake can create a much larger risk for real people.

I did not attempt to exploit the issues further. I documented what I had observed and reported it to the website administrators. The purpose of responsible security research is not to cause damage. It is to give the affected organization a fair opportunity to understand and fix the problem.

That experience left me with a lasting conclusion: a new website is not automatically trustworthy just because it looks polished, ranks well on Google, or belongs to a large company.

When Does Vibe Coding Become Dangerous?

Vibe coding is a way of building software by describing the desired result in natural language and letting AI generate much of the implementation. It can be excellent for prototypes, personal projects, and testing new ideas.

The danger begins when developers deploy generated code they do not fully understand or verify.

Suppose someone asks an AI assistant to build a file-upload feature. The model may generate code that appears to work. But unless the request and the review process address file types, size limits, storage location, authorization, malicious content, and error handling, the result may be functional without being secure.

This is an important distinction. Functionality asks whether the happy path works. Security asks what happens when someone deliberately takes the wrong path.

OWASP’s guidance for AI-assisted coding recommends independently reviewing security-critical areas such as authentication, authorization, input validation, and cryptographic operations. It also warns against treating AI-generated tests as proof that AI-generated code is secure. Most importantly, every AI-assisted change should have a human owner who is responsible for its correctness, security, and maintenance. OWASP Secure Coding with AI

Put simply:

AI can write code quickly, but it cannot accept responsibility for what that code does.

How AI Can Defend Us

Used carefully, AI can become a powerful cybersecurity assistant. It can help teams:

analyze large volumes of logs;
detect unusual user or network behavior;
identify suspicious patterns in source code;
classify phishing messages and malicious files;
summarize complex incidents for security teams;
prioritize vulnerabilities and accelerate incident response.

In the hands of an experienced professional, AI reduces repetitive work and creates more time for deeper investigation. It does not replace security expertise; it amplifies it.

How AI Creates New Risks

The same capabilities are available to attackers. AI can help them:

scan large numbers of websites for common weaknesses;
personalize phishing messages at scale;
generate and modify malicious code more quickly;
build profiles from publicly available company and employee data;
automate parts of an attack that once required more time and expertise.

AI does not necessarily invent an entirely new form of attack. Its more immediate effect is lowering the cost and increasing the speed of techniques that already exist. A single method can now be tested against thousands of systems much faster than before.

This is especially dangerous when the software being targeted was also produced quickly, with little review and weak security fundamentals.

The Real Problem Is the Process, Not the Tool

I do not believe vibe coding is inherently bad. The problem is not using AI to write code. The problem is accepting its output without understanding it.

An AI-assisted production project should, at minimum, include the following safeguards:

A human review for every meaningful code change.
Dedicated checks for authentication, authorization, and input validation.
Security testing for file uploads, APIs, and payment-related functionality.
Automated dependency, secret, and static security scanning in CI/CD.
Error handling that does not expose internal system details.
A separate security review or penetration test before sensitive releases.
A clearly identified developer who owns every AI-generated change.

NIST approaches AI risk management as a continuous lifecycle rather than a one-time checklist. Its framework organizes that work around four functions: govern, map, measure, and manage. Trustworthiness and security must be considered during design, development, deployment, use, testing, and evaluation—not added after the product is already live. NIST AI Risk Management Framework

A Large Company Is Not a Security Guarantee

Users often rely on signals such as branding, search ranking, visual polish, or company size when deciding whether to trust a website. Those signals may tell us something about marketing and visibility, but very little about how securely the software was built.

The questions that matter are less visible:

Was the code reviewed by someone who understood it?
Were security requirements included from the beginning?
Are sensitive functions tested independently?
Does the company have a responsible disclosure process?
Who is accountable when AI-generated code fails?

Strong security is rarely visible in a screenshot. It exists in the engineering process behind the interface.

Conclusion

AI is an extraordinarily capable tool, but its impact depends on the hands guiding it. An experienced developer can use AI to build faster while preserving quality and security. Someone without the necessary fundamentals can use the same tool to create a polished application that is dangerously fragile underneath.

My experience with that website taught me not to confuse presentation with trust. A professional-looking interface, a high Google ranking, and a well-known company name do not guarantee secure engineering.

The most important question is no longer:

Was this code written by AI?

The question we should be asking is:

Who reviewed this code, and who is responsible for its security?

AI can accelerate development, but security still requires ownership. Join the Vexlint waitlist to learn how we are helping developers review AI-generated code before vulnerabilities reach production.