On every push, CodeGuards reads the diff in repository context, knows the architecture your team has actually agreed on, and leaves one focused remark per real issue on the diff line. Verdict is one of clean or remarks – not a 40-comment essay your team scrolls past.
Try Code review · 14 days free See how a remark looksYou've probably tried a PR review bot before. We've watched a lot of teams turn one off after sprint two. Here's the difference we built around:
clean and the bot stays quiet.
Each is a deliberate choice that has cost us speed of shipping. We made them because a code-review bot that doesn't have these is a bot you'll mute by week 3.
Reads the surrounding files — what the function is called from, which interface it implements, which test it has. Style nits stop being style nits when the bot can see callers.
Per-repo rulebook holds your bounded contexts and dependency rules. The bot flags the diff that bypasses them — with a one-line citation of the rule, not a generic "consider refactoring".
Suppressions are per-repo, per-fingerprint, with a category-path fallback. A rephrased Claude output still hits the same rule — you don't suppress the same thing 12 times.
On GitLab, when you (or the bot, after you click Suppress) agree a remark is fine, the discussion is auto-resolved via the GitLab API. The MR view stays clean — no dead "resolved" threads.
// what a remark actually looks like
Controller is reaching the database directly — bypasses the repository layer.
This file's bounded context (BoundedContext/Billing) declares the rule Controller → Action → Service → Repository → Model. The new lines call DB::table() straight from the controller, which skips three layers and the per-tenant scoping that InvoiceRepository::findForOrganization() applies.
InvoiceRepository already enforces organization_id isolation. This change exposes any invoice id to any logged-in user.
Suggested next step: route the read through InvoiceRepository::findForOrganization($id, $request->user()->organization_id).
That's one remark, anchored to one line, on one PR. If the bot has nothing to flag, the verdict is clean and no comments are posted at all. Re-runs update existing threads in place — the discussion tab never grows by accident.
Tuned for one connected repo, both products on, default rulebook. Numbers are from teams shipping 20–50 MRs per week.
Defaults are sensible for the language and framework we detect. But the place where this stops being a generic bot is the per-repo rulebook — your architecture rules, in version control, enforced on every PR.
You can express things like "controllers never talk to Eloquent models", "every public method on a Service class needs a feature test", "no DB::raw outside Repository/". The bot flags the diff that crosses them.
If your team disagrees with a remark, click Suppress once and add a note. The rulebook stays the same — only this fingerprint stops surfacing on this repo.
// .codeguards/review.yml version: 1 tone: "professional" rules: architecture: - id: "controller-no-direct-model" severity: "high" applies: "app/Http/Controllers/**" forbid: - "Eloquent\\Model::*" - "DB::table" why: "Reach via Action → Service → Repository." tests: - id: "service-needs-feature-test" applies: "app/**/Services/**" require: "tests/Feature/**" style: - id: "no-magic-numbers" severity: "low" except: [0, 1, -1] suppressions: // auto-managed file: ".codeguards/suppressions.yml"
Each review is a timestamped record: which commit, the verdict, the remarks raised, the suppressions accepted, who clicked them, with what reason. The same evidence shape your security pipeline produces — but for everyday code-quality decisions, not just vulnerabilities.
Useful when an engineering manager asks "why didn't anyone flag X?" and the answer is "we did, here's the thread, here's who agreed it was fine, here's the rule it cited". That's SOC 2 CC8.1, ISO 27001 A.14.2, and the change-management half of PCI-DSS 6.3 — out of the box, both products contribute the same rows.
/codeguards suppress, /codeguards explain, /codeguards helpremarks verdictNo. One inline thread per remark, anchored to the line. If the bot has nothing material to say, the verdict is clean and no comments are posted at all. Re-runs update existing threads in place — the discussion tab does not grow by accident.
Click "Suppress" with a one-line reason. The remark is dismissed, the GitLab thread is auto-resolved, and the same fingerprint stops surfacing on this repo for both exact matches and rephrased neighbours. The audit trail keeps the suppression with the author and reason — so the decision is reviewable later.
To the extent your team has written it down, yes. The per-repo rulebook (.codeguards/review.yml) is where you express bounded contexts, layered dependencies, and the rules you actually enforce in PR review today. The bot reads it and flags the diff that violates it. If you don't have a rulebook, the bot still does style/quality remarks based on language defaults — but the architecture-aware part is opt-in.
Inside, yes — the reasoning is from a frontier LLM. What's around it is the actual product: the diff line mapper that anchors comments precisely, the suppression engine with category-path fallback, the per-repo rulebook loader, the GitLab/GitHub adapters that know how to post inline review comments and resolve threads, the Stripe meter that bills per run not per seat, and the audit-grade record on every review. Swapping the LLM is a one-driver change for us.
Per-repo toggle in Integrations. You can run Code review on the design-system repo and not on the marketing-site repo. You can also pin it to specific branches via the per-repo settings.
One review = one PR/MR analyzed against your rulebook on its current head. We charge per review run, metered to Stripe. Re-runs of the same head are deduplicated for free; re-runs after a new push are a new review. See the pricing page for plan details and the bundle with Security scans.
Never. We don't post commits to your branch. Some remarks include a suggested change as a code block in the comment for you to copy/paste — but the branch is yours.
Accumulated project knowledge per repo — suppressions, conventions, fixes and exceptions your team already decided. CodeGuards applies that history on the next diff.