Agents write code faster than teams can review it, and they write it without memory of how the codebase already solves a problem. Each change is locally reasonable and globally inconsistent: a second HTTP wrapper, a third date helper, a layer that exists to satisfy a pattern nobody uses. Drift compounds silently because no single diff looks wrong.
Diff-scoped review cannot catch this by construction. A reviewer reading forty changed lines sees whether those lines are correct, not whether the module they just created duplicates one three directories away. The information needed to answer that question lives in the rest of the repository, which is exactly the part a pull request does not show.
VibeCop reviews the change against the codebase — its import graph, its established patterns, its prior findings — rather than against itself.
VibeCop scores every repository with an Architecture Integrity Index: a 0–100 number built from four axes of 25 points each. Each axis is computed from the findings its detector agents produced, weighted by severity, and the headline index is the sum of the four axis tiles — so the score and the tiles always reconcile.
| Axis | The question it answers | Detectors |
|---|---|---|
| Consistency | Are similar problems solved the same way? | pattern-drift · reintroduced-bugs |
| Reuse | Is logic reused, or re-implemented in parallel? | semantic-duplication · reinvented-utilities |
| Simplicity | Does every abstraction earn its weight? | hallucinated-abstractions · over-engineering |
| Structure | Are cycles, coupling, and fan-out in check? | architectural-complexity · layer-violations · orphaned-modules |
Severity drives the deduction: a critical finding costs an axis far more than a cosmetic one. Resolving or dismissing a finding takes it out of the live axis tiles on Overview, so the score you are working against climbs back. The number stored on a completed scan is a record of that scan and does not move afterwards — the trend line and the per-project cards read those stored numbers, so history stays history.
Dependency CVEs, exposed secrets, SAST hits, and infrastructure misconfigurations are real and worth fixing, but they say nothing about whether a codebase is architecturally coherent. Mixing them in would let a clean dependency upgrade paper over genuine structural decay. They carry no axis, so they carry no weight.
Where you read them differs. Overview's hygiene tray counts this week's open security findings — secrets, SAST, dependency CVEs, infrastructure — and complexity warnings; every hygiene finding, including dependency-health and vendored-drift, also sits in the org-wide Findings section alongside everything else. Neither placement can move an axis in either direction.
Three differences, and all three are about where the review happens. VibeCop grounds detection in a real code graph rather than in text patterns, reviews the plan before code exists rather than the diff after, and reviews agent-written work while it is in flight rather than at the end.
VibeCop never merges. A Feature Factory run stops at G1 until its task graph is approved — by a person on the dashboard, or by the agent driving the run when it holds authority over it. G1 asks for a reviewer, not for a person in particular. G2, the merge, is the decision VibeCop has no way to make: code reaches your default branch only because someone merged it.
The index is one half of what you get. The other is what VibeCop knows about the codebase while computing it — a symbol graph, a deployment topology, a scan and review history — and an ask bar that answers questions against them. Architecture integrity is the score; product intelligence is being able to ask what the system actually looks like and get an answer grounded in it.
Teams whose code volume has outrun their review capacity because they adopted AI coding agents. If most pull requests are agent-authored, if reviewers approve on trust rather than reading, or if nobody can answer “is this codebase getting better or worse” with a number, VibeCop is aimed at you.
It is less useful on a codebase with no established patterns yet. Every detector calibrates against how your repository already solves things, so a green-field repository has little for VibeCop to be coherent with. Connect it once conventions exist and are worth holding.