The deliverable of a paid VibeGuard audit is not a chat transcript. It is a pull request on your repository: a security-fix branch with concrete, verified changes, plus a report explaining each one. This post walks through how that PR gets made — and why every step is shaped by one question: can a founder merge this with confidence?
It starts with a frozen scope
Before any paid model call, the audit knows exactly what it is allowed to look at. Your free scan classified every file — security-relevant code in, build artifacts and noise out — and the quote froze that scope into a manifest: every included file with its hash and size. The manifest is re-verified before execution. If your repo changed since the quote, the audit aborts instead of running against content nobody priced. The agent reads code through read-only, in-memory tools over that frozen corpus. It cannot execute your code, cannot install your dependencies, cannot fetch arbitrary URLs into the audit.
Corroboration before opinion
The engine does not start by asking a model what it thinks. Phase zero gathers independent signal: a SAST pass (Semgrep) over the corpus and a dependency check against known CVEs. That intel travels alongside the model's own review, so findings can be corroborated by tools that do not hallucinate. A finding that both a deterministic scanner and a reviewer flag is a different class of evidence than either alone.
Seven reviewers, one merged list
Instead of one giant "find all the bugs" prompt, the audit runs an ensemble of focused passes — secrets, auth, injection, payments, uploads, dependencies, and AI-agent usage. Each reviewer sees the corpus through the lens of one risk category. Narrow prompts find more because they are not trying to hold the whole threat model in one context window. The passes then merge and dedupe into a single findings list with severity and location.
Fixes are surgical edits, not rewrites
For each fixable finding, the fix agent proposes a surgical search/replace edit: an exact snippet of your existing code and an exact replacement. Not "here is the corrected file" — whole-file rewrites are where AI silently drops your comments, reorders your imports, and breaks something three functions away from the bug.
Surgical edits have three properties we care about:
- The diff is tiny and reviewable — you can see precisely what changed and nothing else.
- The hallucination surface is small — the edit either matches your real code or it visibly fails.
- Even the cheapest model can produce one cleanly, which is why every paid tier ships fixes, not just the expensive one.
Verified against your real file, in-loop
This is the step that separates "AI suggested a patch" from "merge-ready." Every proposed fix is applied to the actual file content and checked inside the audit loop — does the search target exist, does the patched file preserve everything it should, does the result hold up under similarity and line-preservation checks?
A fix that fails verification does not get politely shipped with a disclaimer. It is rejected while the agent still has budget to try again or to reclassify. Hallucinated edits — references to code that does not exist, patches that mangle surrounding lines — die here, inside the loop, not in your review. And everything is verified once more at delivery time, before the PR is built.
Not everything should be automated — so it isn't
Some findings have fixes that are genuinely risky to automate: changes that depend on business logic, migrations with data implications, anything where a wrong guess is destructive. Those become TODO items with manual instructions — a precise description of what to change and why, addressed to you or your developer. A security product that auto-applies destructive changes to be impressive is itself a security problem.
The report is guaranteed, not best-effort
The engine runs under a hard token ceiling priced at quote time, and a slice of that ceiling — the finalization reserve — is withheld from the working phases. Whatever happens during review and fixing, the engine always has budget left to write the PR description and the full report. You cannot pay for an audit and receive an exhausted agent's half-sentence.
The PR itself
Delivery creates a new branch on your repository — via the GitHub App you installed, with repository-scoped permissions — applies the verified fixes, and opens a pull request. The PR body summarizes each fix, its severity, and its reasoning, with the full report (markdown and PDF) in your dashboard.
Three things never happen:
- VibeGuard never pushes to your default branch.
- VibeGuard never merges anything.
- VibeGuard never deploys anything.
The PR sits there like any teammate's PR: you read the diff, run your tests, and merge when you are satisfied. If your project came in as a ZIP instead of a GitHub connection, you get the same verified fixes as a downloadable patch bundle.
Why this shape
We could ship findings as a PDF and call it a day — plenty of tools do. But a founder reading "you have an IDOR in your API" at 11pm does not need prose; they need the two-line diff that closes it, sitting in a branch, already checked against their real code. That is what the fix PR is: the audit's conclusions, expressed in the only language that actually ships — a reviewable diff.