Hello to v3 of PR Review

A founder note

We did not want to wait a month to call this V3

I want to say this plainly: this post is landing right after yesterday's V2 release because the product moved that quickly. We shipped V2, kept building, and the shape of the review system changed enough in the next stretch of work that pretending this was just a small follow-up would have been dishonest. So, yes, hello to v3 of PR Review.

That pace matters to me for two reasons. First, it shows how serious we are about building in public and tightening the product as the architecture becomes clearer. Second, it shows the exact kind of company I want Critique to be: one that does not sit on meaningful improvements just because a release went out yesterday. If the AI PR review system gets materially better, we ship it.

What changed

The review pipeline is now much closer to the real architecture we wanted

The original direction was always simple: the app should orchestrate, the sandbox should execute. The app should own identity, routing, policy, permissions, artifacts, and GitHub publishing. The sandbox should own deterministic repository work: clone the repo, inspect the real diff, run search, typecheck, lint, tests, and produce evidence that models cannot simply invent. V3 moves Critique much closer to that operating model for GitHub App PR review.

Why this is a real version jump

Review is no longer just a summary generator

Earlier versions of AI review products tend to collapse into the same pattern: ingest diff, ask model, post summary. Even when they look sophisticated, that is still the basic shape underneath. V3 is different. The new flow is explicit: create a review run, dispatch analysis, gather deterministic evidence, persist the artifact, resume synthesis from the artifact, publish back to GitHub, then expose the review as an owner action surface where discussion and remediation can continue from the same source of truth.

That shift sounds subtle when written in one paragraph. It is not subtle in the product. It changes what can be grounded, what can be retried, what can be handed off, what can be explained to the user, and how much of the system becomes durable instead of ephemeral.

The biggest product unlock

The canonical review-run page

The new review-run page is the center of gravity in V3. Every serious review now has a canonical owner-only page that pulls together the full review, the deterministic analysis report, normalized findings, GitHub publication details, Remedy handoff, latest Remedy status, a bottom review assistant, a fix prompt generator, and a PR discussion thread panel. That page is not a receipt. It is the control surface for the whole AI code review outcome.

This also solves a trust problem. AI review output is much easier to trust when the review is attached to a durable artifact and a visible workflow, not just a blob of markdown dropped into GitHub. V3 makes the review inspectable in a much more honest way.

GitHub got much better too

Checks, summaries, inline comments, and graceful fallback

We also tightened the GitHub App side substantially. V3 preserves the check-run path, preserves annotations, publishes a PR review summary, and now attempts inline PR review comments when a finding maps cleanly to a changed right-side diff line. If GitHub rejects the inline review payload, Critique degrades safely to summary-only review, and then to issue comment fallback. A flaky publish endpoint should not invalidate an otherwise successful review.

Review to fix is now real

Remedy handoff and Generate Fix Prompt

The most important downstream improvement is that review and remediation now feel like one system. V3 builds a Remedy blueprint from the actual normalized findings and analysis artifact, passes allowed write scope and validation steps forward, exposes that handoff on the canonical page, and lets the user either queue Remedy directly or generate a detailed fix prompt for another coding agent like Cursor. That turns AI code review into an execution-ready workflow instead of a dead-end comment thread.

That matters because teams are not homogeneous. Some want Critique to continue into its own isolated Remedy flow. Some want the handoff and would rather execute it inside their preferred coding agent. V3 supports both without breaking the review artifact in half.

This release says something about how we build

We are building in public at product speed

There is a product philosophy behind this release cadence. I do not think high-agency software teams should wait around for perfect bundling. If yesterday's release revealed the next obvious version of the product, the correct move is to ship again. That is what happened here. V2 made the new review system visible. V3 makes it feel operational, credible, and much easier to trust.

I want people paying attention to Critique to understand this clearly: we are not approaching AI review as a thin UI wrapped around model calls. We are trying to build the operating layer between AI-generated code and production software. That means shipping quickly, but it also means tightening the architecture every time the real product shape becomes clearer. V3 is a direct expression of that rhythm.

What is live right now

Closing

We are just getting started

The honest truth is that V3 is not the end state. It is the first version that feels like the product is really lining up with the system we wanted to build from the beginning. There is still more to do. But the contour is now visible. Review is becoming a real control plane. Evidence comes first. The sandbox does the execution work. GitHub stays native. The review artifact becomes reusable. And the path from critique to fix is no longer an afterthought.

If you have been watching Critique from the outside, this is the post where I want you to update your mental model. Yesterday was V2. Today is V3. We are moving fast, and we are building the thing all the way through.

Thanks for paying attention. Repath Khan Founder, Critique