---
title: "Code Review — Praxis"
route: "/solutions/code-review"
template: solution
intent: "Review AI-generated changes against their intended requirement and evidence."
parent: "/solutions"
primaryCta: { label: "Talk to us about code review", href: "/enterprise?interest=code-review#contact" }
description: "Quality Harness can review a bounded implementation against its work package and evidence; private PR/MR integration is discussed separately."
schemaType: Service
hero:
  eyebrow: "Solution"
  headline: "Review AI-generated changes against intent, not only syntax."
  sub: "When generated changes outrun review capacity, inspect one bounded change against its accepted scope and the checks actually performed."
  primaryCta: { label: "Talk to us about code review", href: "/enterprise?interest=code-review#contact" }
sections:
  - { id: pain, kind: pain, heading: "Review is the bottleneck now" }
  - { id: why-review-queues-grow, kind: explanation, heading: "Why more reviewers don't fix it" }
  - { id: praxis-mechanism, kind: explanation, heading: "What Praxis Code Review does" }
  - { id: review-flow, kind: flow, heading: "How it works" }
  - { id: proof, kind: proof, heading: "What's included" }
  - { id: next-step, kind: cta, heading: "Get a review of your codebase" }
---

## Review is the bottleneck now

A reviewer receives a generated change and must reconstruct what it was meant to do. A diff and a green check alone may not show the accepted requirement, the design constraint or which tests were skipped. That uncertainty grows as the queue grows.

## Why more reviewers don't fix it

More review time helps, but repeated reconstruction consumes it. A bounded work package, implementation record and explicit check results give a reviewer a concrete starting point. They can still ask for rework; the artifact trail makes the request specific.

## What Praxis Code Review does

Quality Harness can inspect a particular Developer result against its package and evidence, report findings, and preview application of an outcome. An approved apply is separate from the review verdict, and Git delivery is another decision. Private PR/MR automation or broader monitoring can be discussed for a configured engagement; current role and Runtime sources do not establish that every MR is automatically audited in CI.

## How it works

- **Open the intent** — identify the accepted scope and Architect handoff for one WP.
- **Inspect the change** — compare the implementation, tests and available evidence with that input; show failed or skipped checks.
- **Review the finding** — a human decides whether to rework, accept or request more evidence.
- **Apply and deliver separately** — where configured, apply the approved Quality outcome; publish through Git only after its own approval. Merge remains a later human decision.

### In production

[The case contexts](/cases) explain why reviewable handoffs matter. They are not evidence of a universal installed CI integration or a live drift dashboard.

## What's included

A review conversation can start with one bounded change and its evidence. Discuss private integration, repositories and review criteria with the team before representing any automation as configured.

## Get a review of your codebase

Bring a WP and a recent change that was hard to review.