Security in vibe-coded apps is a leadership problem, not a code-review problem

I have already written the checklist: the specific, repeatable holes generated code ships with, and what I look for when reviewing an app a model mostly wrote. That essay answers "what is wrong with the code." It does not answer the question that actually keeps me up at night, which is organisational, not technical: when a vibe-coded app gets breached, who was accountable for the decision to ship it, and did anyone actually hold that role?

That is the question a checklist cannot answer, and it is the one leadership gets paid to.

The part that changed, and the part that didn't

What changed is who can now produce a working application. A founder with no engineering background can describe a feature to a model and ship it. That is genuinely new, and mostly good — it is more product built per unit of capital, which is the entire economic case for the tools.

What did not change is who is accountable when that application handles a customer's payment details, health data or credentials and fails to protect them. Not the model. Not the tutorial the model's training data resembled. The organisation that shipped it, and specifically whoever was supposed to be the check on that decision. A model cannot be named in a breach disclosure, cannot be deposed, and cannot be fired. A person can, and in a portfolio this size, that person is usually me.

Why "the AI wrote it" isn't a defence, and never was

There is a version of this conversation that treats AI-generated vulnerabilities as a special, more forgivable category — as if a hardcoded key or a missing authorisation check is less serious because a model typed it rather than a person. Regulators, customers and attackers do not grade on that curve. A breach costs the same in incident response, notification obligations, and trust, regardless of who or what wrote the vulnerable line. If anything the AI-generated version is worse, because it arrives wrapped in confident, well-formatted code that discourages the scrutiny a hand-written first draft would have invited on sight.

"The model wrote it" is not an explanation for how the vulnerability got there. It is a description of how the accountability got skipped.

What this actually costs, concretely

Not in the abstract — in the categories that show up on an incident report. Response time, because nobody owns triage when nobody signed off on the change. Regulatory exposure, because a payment or health-data breach triggers disclosure obligations regardless of whether a human or a model introduced the flaw. Client trust, which is the actual asset on a portfolio built on client engagements — a security incident on one product is a conversation about every other product the same organisation runs. Rework, because the fix for "we didn't have a process" is a process, built under worse conditions than it would have been built under before the incident.

None of that shows up in a code review. All of it shows up on a leadership desk.

The governance answer, not the technical one

The technical checklist is necessary and I stand by every item in it. But a checklist only works if someone with the authority to block a merge is required to run it, on every change, with no exception for "it's just an MVP" or "the founder is in a hurry." That is not a code-review policy. It is a governance decision about where authority sits in the organisation, made before the first vulnerable line ever gets generated.

Concretely, that means: a merge gate that applies regardless of who authored the pull request, including the founder. Production-freeze governance on anything touching payment or health data, with no self-certification path. A named owner for the security posture of every product in the portfolio, not a shared assumption that "someone" is checking. And an incident response plan written before the first incident, not drafted in the hours after one, when the people who should be calm are not.

Where the accountability actually lands

Strip away the tooling question and this was never really about whether AI writes better or worse code than people do on their first attempt — it writes both better-formatted and less examined code, which is its own problem. The real question a portfolio-scale organisation has to answer is who is accountable when the fast path ships something it shouldn't have, and whether that person had the authority, the process and the mandate to have stopped it. If the answer to that is "no one, really," the technical checklist was never going to save you. That gap is not a code problem. It is a leadership problem, and it is mine to close before it is anyone else's to explain.

---

Related: the security risks nobody checks in vibe-coded apps — the technical checklist this argument assumes.