Vibe coding security: who reads the diff

What vibe coding is, in plain words

The word came from Andrej Karpathy in February 2025: giving in to the vibes, letting the agent write the code, running it to see that it works, and moving on without reading every line. It started as a half-joke about a style of working, and the style stopped being a joke. Weekend projects grew into real products, and the people building them sit anywhere on a spectrum: founders who read none of the code, engineers who read some of it, teams whose agents open most of the pull requests.

The word is still the fastest way to say it, and what it describes is becoming the default way code gets written. That is the reason to take its security question seriously instead of dismissing the word: the special case is turning into the normal case, and the normal case is exactly the world a pull-request reviewer is for.

The security question, unchanged

Nothing about the vulnerability classes changed. On a route, who is the actor and where does the gate for it live. On a lookup, who names the key, the session or the request. Access control first, the class that disappears quietly: a missing tenant check on a new endpoint, a fetch by id with no owner scoping, a role list grown by one. Then the injection and output classes that ride in on features: a sort parameter that reaches raw SQL, markdown rendered as HTML, a model response passed downstream unvalidated.

What changed is the amount of human reading in front of those classes. The tests pass, the diff looks clean, and the ownership check the old code had is simply not in the new code, because the task never asked for it. The access-review guide carries the full procedure; the point here is that somebody has to run it on every pull request, and in a world where the agent wrote most of the code, that somebody cannot always be you.

Who reads the diff, three ways

Your own pass. Open the rule before the diff, name the actor, stop at the four shapes worth stopping for. It costs the one thing the vibe is short of: attention, on every pull request, every day.

The agent's own review modes. Some coding agents ship review and security passes of their own. They run where you run them, when you think to run them, which is exactly the condition the style of working does not guarantee.

A reviewer installed on the repository. The Aevral GitHub App installs once, on the accounts or organizations you choose, and from the next pull request it reads the diff, live on install, the same reading for code a human wrote and code an agent wrote. A finding is a lead with evidence and a suggested fix, at most five findings per review, advisory and never blocking. You decide what ships.

From install to the first comment

One: install the Aevral GitHub App on the repositories you choose; a GitHub owner or admin approves the install. PR review is live on install: installing the App starts reviews on the next pull request, even before anyone signs in, and the owner can turn them off in Setup.

Two: sign in to the console with GitHub. That connects the install and starts a 14-day trial for private repositories: private reviews are free up to 500, and the trial ends at 14 days or 500 reviews, whichever comes first.

Three: open a pull request, or let your coding agent open one. Aevral reads the diff of the changed files, and the most security-relevant in full.

Four: read the result on the pull request. An advisory Check sits on the head commit, and when there is a grounded finding, inline comments sit on the added lines, at most five findings per review. Each finding carries the evidence, a suggested fix, and a Fix with your agent prompt a human can paste into Claude Code, Cursor, or Codex. Aevral never pushes, applies, or merges anything, and it never blocks a merge. You decide what ships.

What it looks for, and the published record

Aevral's PR review looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks, live on install. Access control is the first item on that list and the reason the product exists. The whole-repo scan reads authorization, IDOR, and business-logic access control across the default branch, for the rules a single diff does not show.

The published record: on the Aevral receipts page, the PR review runs of 25 September 2026 read "10 of 12" (Run 1) and "11 of 12" (Run 2) on the frozen authorization slice of planted pull requests. In the page's own words: "Each recall number is the result of that named run on that corpus. It is not a product accuracy rate, and results on your code depend on your code."

Limits worth knowing: GitHub only (not GitLab, Bitbucket, or Azure DevOps). The review reads the diff of the changed files and the most security-relevant files in full; on a large pull request the most security-relevant files are reviewed first, and the review says which files it covered. It is not secret scanning, not dependency scanning, and not a general SAST.