In one widely shared analysis, a researcher audited 50 vibe-coded projects and found that 86% contained security vulnerabilities. Not edge cases — the basics: missing input validation, endpoints with no authorization, paths to remote code execution, and personal user data sitting in the open.
If that number feels high, it should not. It is the predictable result of how AI builds software. The surprising thing is not that 86% had holes. It is that anyone expected otherwise.
Why AI ships insecure code by default
An AI agent optimizes for one thing: code that satisfies the prompt. You asked for a login form, an upload endpoint, a way to save a profile — and it gave you exactly that, working, on the first try. What it did not do is ask the question a security-minded engineer asks reflexively: what happens when someone hostile uses this?
That question is almost never in the prompt, so it is almost never in the output. The model will happily trust user input and interpolate it straight into a query or a shell command, build an API route that returns a record by ID with no check that you are allowed to see it, accept a file upload and serve it without validating type or path, or return more of the user object than the page needs — including fields that should never leave the server.
None of this looks wrong in the chat. The feature works. The demo is clean. The vulnerability is invisible precisely because the happy path is flawless — and the happy path is the only path anyone tested. In a normal team, this is the gap a second engineer closes: someone who did not write the code looks at the auth change, the new endpoint, the data query, and asks the hostile question on your behalf. Vibe coding deletes that role. There is the AI, and there is you — and if you are not reading every diff for injection and broken access control, nobody is.
How afterclick closes the 86% gap
afterclick is a governance platform for AI-built software. Claude is the developer. afterclick is everyone else — and "everyone else" includes the security reviewer your vibe-coding setup is missing. You do not re-hire a security team; you wire the function of a reviewer into the loop, focused on the changes that can actually hurt you.
An independent second eye on security-relevant changes. When the agent touches authentication, input handling, or data access, afterclick brings an independent engine in to review that change before it lands. It reads the change for intent and looks for exactly the 86% pattern: unvalidated input flowing into a query, a missing ownership check on an endpoint, a record fetched by ID with no caller check, a secret in the diff. It then surfaces the concern in plain language — what is risky and why — instead of waving through a clean-looking demo.
Tuned to risk, not noise. A reviewer that flags everything gets ignored, and an ignored reviewer is worse than none. afterclick does not comment on every rename or copy tweak. It engages on the categories where a miss becomes a breach — auth, money, data, and production — so what you get is signal you will actually read, not a wall of warnings you learn to scroll past.
Advisory by default, with a real stop when you want one. By default the second eye surfaces its concern and you stay in control: you can look, agree or disagree, and override with a recorded reason. When a change is genuinely sensitive, you can switch on opt-in enforce so the risky change is blocked until it is addressed, not merely flagged. You decide how hard the guardrail pushes.
A ship gate so unreviewed code cannot slip out. Catching a vulnerability is only half the job; the other half is making sure the risky change does not quietly reach production anyway. afterclick puts gates on the deploy — a deploy lock and a ship queue — so a security-relevant change goes out as a deliberate, recorded release, not an accident at 2am when the heartbeat lapsed.
An audit trail for when it matters. Every change and every review is recorded on a read-only human dashboard. When a customer, a co-founder, or a future you asks "was this checked before it shipped?", there is an answer — the change, the concern raised, and what was done about it — instead of a transcript that already scrolled away. And because secrets live in afterclick's keys vault rather than the source, the most common leak in that 86% — a hardcoded credential — never makes it into the diff in the first place.
In practice it looks like this: the agent builds a new endpoint that returns an order by ID. It works in the demo. Before it ships, afterclick's second eye flags that the route never checks the order belongs to the requesting user — a textbook broken-access-control hole. You see the plain-language concern, agree, and have the agent add the ownership check. The fix, the original risk, and the deploy all land on the dashboard. The 86% bug that would have shipped silently instead got caught at the door.
| Aspect | Without afterclick | With afterclick |
|---|---|---|
| Who reviews security | Only you, if you read every diff | Independent second eye on risky changes |
| Unvalidated input / injection | Ships if the demo works | Flagged in input-handling diffs before it lands |
| Missing authorization | Invisible on the happy path | Flagged on data-access changes that skip a check |
| Insecure change reaching prod | Slips out unnoticed | Ship gate makes the deploy deliberate and recorded |
| "Was this ever checked?" | Lost in the transcript | Audit trail of every change and review |
Ship fast, just not blind
The 86% statistic is not an argument against vibe coding. It is an argument against vibe coding with no one watching the security-relevant changes. The speed is real and worth keeping. The fix is not to slow down — it is to put an independent second eye and a ship gate between the agent's confidence and your users.
afterclick is advisory by default, with owner override and opt-in enforce, and it is free to start in one paste. Keep building on vibes — just put a reviewer at the door, and stop being the 86%.