Review scope stays bounded
PatchPatrol starts from explicit GitLab or local diff context, then keeps the review path tied to the change instead of wandering across the repository.
PatchPatrol
AI code review for GitLab that doesn't suck and won't disappear into a black-box abyss
Stop wondering whether your merge requests got meaningful review signal. Run bounded reviews, publish inspectable artifacts, and skip the mystery.
Product proof
PatchPatrol gives teams one review path they can explain, inspect, and control.
Artifacts stay inspectable
Each run produces `ai-review.md` and `ai-review.json` so teams can read the summary quickly and still keep a structured contract for downstream automation.
Trust posture stays explicit
The product is built for self-hosted GitLab CI, local developer workflows, and customer-controlled model endpoints where privacy boundaries matter.
Why teams use PatchPatrol
The value is not more AI surface area. It is a safer, clearer first review signal.
PatchPatrol is for teams that already review code seriously and want faster signal without giving up accountability, privacy posture, or control over where model calls go.
Give reviewers a faster first pass
Teams use PatchPatrol when they want earlier signal on GitLab merge requests without turning review into a black-box automation step.
Keep human judgement in the loop
The output is meant to support reviewer decisions, not replace them. PatchPatrol helps teams preserve human judgement while making review runs more repeatable.
Stay privacy-first by default
PatchPatrol favors customer-controlled model endpoints, bounded context collection, and artifact-first delivery over vague claims about autonomous AI.
How the first review path works
The first PatchPatrol rollout stays focused: bounded input, explicit trust checks, then artifact-first output.
Step 01
Start from the review context that matters
PatchPatrol resolves GitLab merge requests or local developer diffs so the run begins from the exact change a team wants reviewed.
Step 02
Constrain the run before provider calls
The review scope is chunked into bounded work and checked against trust gates before anything is sent to a model endpoint.
Step 03
Publish evidence teams can inspect
The first rollout path stays artifact-first: reviewers inspect `ai-review.md`, keep `ai-review.json` for structured follow-on use, and decide what action to take next.
Start with docs when you need the technical path
The website explains fit first. The docs surface takes you through the actual setup and follow-through path.
PatchPatrol keeps technical onboarding in the separate `/docs` surface so visitors can choose the role-specific path they need without turning the launch site into a reference index.
Admin path
Set up the first supported review flow
Use the admin quickstart when you need the GitLab artifact-first setup path, provider prerequisites, and the first rollout contract.
Open admin quickstartDeveloper path
Follow the first review as a developer
Use the developer quickstart when the workflow is already wired and you need to understand the first run, artifacts, and next shared steps.
Open developer quickstartDirect help
Use contact when fit or rollout shape is the real question
If the next step is deciding whether PatchPatrol fits your environment or constraints, stay on the direct conversation path instead of jumping straight into setup docs.
Talk to PatchPatrol