Is AI-generated code less secure than human code?

We do not know, we have not measured it, and the published comparisons we have read do not agree with each other. It is also the wrong question for a decision. What we see repeatedly in this category is secrets and authorization, and both are checkable in an afternoon whatever the rate turns out to be.

Can we just have the AI review its own output?

It catches some things and it is not a substitute for a second person, because the failures that matter here are usually assumptions rather than mistakes, and it shares the assumptions. It is most useful aimed narrowly, as in asking specifically what happens if this request arrives without a session.

What about applications that are only used internally?

Internal is a description of intent rather than of reach. An application with no server-side authorization is available to everybody who can reach the network it runs on, including anything else that has been granted access to that network, which at this point usually includes several tools somebody connected.

Is vibe-coded software safe to ship?

It can be, and the checks that matter are narrower and more specific than a general code review. The two failures that recur are secrets left in the client or the repository, and authorization enforced by hiding things in the interface rather than by checking on the server who is asking. Both are common because generated code is fluent, and fluency is the proxy reviewers use for correctness. That proxy stopped working.

The two that decide it

Keys and credentials out of anything the browser receives, and out of the repository history. A key in a client bundle is not a weakness to be ranked against others; it is a published credential, and it stays published in the history after somebody removes it from the current version.

Authorization checked on the server for every path that matters. Hiding a button does not remove the request behind it, and a generated interface will readily produce the hidden button while the server-side check behind it is not something the prompt asked for. The question to ask of each sensitive path is not whether the interface prevents it but what happens if somebody sends the request anyway.

These are the two that a shipped RedHub pre-launch gate treats as fatal at any score, which is the same shape as the gate on the assessment on this site: a weighted average cannot price an absence.

Why fluency is the problem

Reviewers have always used surface signals as a proxy for underlying care: consistent naming, sensible structure, code that reads like somebody thought about it. Those signals used to correlate with the author having understood the problem.

Generated code has the signals without necessarily having the understanding, so a reviewer's instinct now returns a false pass. This is not a claim that the code is worse on average. It is a claim that the cheap way of telling stopped working, and nothing free replaced it.

The practical consequence is that review has to become reading rather than skimming, and it has to be aimed: at the paths that touch data, the places secrets could be, and the assumptions about who is calling.

The part that is organizational rather than technical

Most of this software is not written by the people the review process was designed around. It is written by somebody who needed a thing, got a working thing, and shipped it, and there was no point at which the process was consulted.

So the useful control is not a better checklist. It is that somebody who did not write it reads it before it goes out, and that this is how things go out rather than something arranged for the important ones.

It is also worth knowing where these applications are. An internal tool with no server-side check is open to everybody on the network, which is a much larger group than the handful of people it was built for, and it is usually not on any list of applications.

Common questions

Is AI-generated code less secure than human code?: We do not know, we have not measured it, and the published comparisons we have read do not agree with each other. It is also the wrong question for a decision. What we see repeatedly in this category is secrets and authorization, and both are checkable in an afternoon whatever the rate turns out to be.
Can we just have the AI review its own output?: It catches some things and it is not a substitute for a second person, because the failures that matter here are usually assumptions rather than mistakes, and it shares the assumptions. It is most useful aimed narrowly, as in asking specifically what happens if this request arrives without a session.
What about applications that are only used internally?: Internal is a description of intent rather than of reach. An application with no server-side authorization is available to everybody who can reach the network it runs on, including anything else that has been granted access to that network, which at this point usually includes several tools somebody connected.

Find out where you stand

The assessment on this site asks up to 24 questions about what the AI in use here exposes you to, and returns a score, a verdict and, where a control is short, the one thing to fix first. It never asks whether you have a list of the tools. It takes about ten minutes, and questions your organization has no surface for are dropped rather than scored against you.

It is a self-assessment of what has been arranged and practiced, not of whether it would hold against somebody actually trying. Not a penetration test, not an audit, not a certification.

Run the assessment