Critique is now conversational

The problem with one-way reviews

Automated reviews that go nowhere

Every AI code review tool that came before worked the same way: the bot posts a block of comments when the PR opens, and then it goes silent. You get a report. You read it, or you do not. If you have a follow-up question, you are on your own.

That is a fundamentally broken model for code review. Real review is a conversation. A good senior engineer does not just drop a list of findings and walk away — they discuss the intent behind the change, ask about the edge cases you considered, explain the tradeoffs in a proposed fix, and iterate with you until the PR is in good shape. AI-assisted review should work the same way.

The static report format also misses an important reality: different people need different things from a review. The author wants to understand why a finding was flagged and how to fix it. The reviewer wants to understand what the change actually does. A team lead wants to know whether this is safe to merge. One auto-generated block of comments cannot serve all three people — it is addressed to nobody in particular and optimised for none of them.

What changes today

Tag @critique and start a conversation

Starting today, Critique is conversational. Any team member — author, reviewer, or observer — can tag @critique in a GitHub PR comment and get a context-aware response back in the thread. The bot reads the entire pull request diff, the surrounding repository files, and the existing comment history before it replies. It is not guessing. It is analyzing the actual context of your specific PR.

You can ask it anything in plain language. Why was this pattern chosen over the alternative? What does this function actually do? Is there a simpler way to write this logic? You can also use slash commands for specific, targeted operations — re-running the full review pipeline, requesting a security scan, getting test suggestions, or asking for a concrete code fix.

The commands

Eight ways to get what you need

The interactive chat supports both free-form questions and structured slash commands. Free-form questions are for the moments when you need to think out loud with the code. Slash commands are for when you know exactly what operation you want to run.

How context works

What Critique actually reads before it replies

When you tag @critique, the bot does not just read your comment and your comment alone. It builds a full context package before constructing a response. That package includes the complete PR diff, the metadata for every file touched by the PR, the repository's relevant surrounding files, the title and description of the PR, and the entire existing comment thread in the order it happened.

This is what makes the responses feel substantive rather than generic. When you ask "is this the right approach for handling auth tokens?" the answer is informed by the actual auth middleware in your codebase, the pattern the rest of your team is already using, and the specific way the PR deviates from or extends it. Critique is not reasoning about code in the abstract. It is reasoning about your code.

The model

Why Qwen 3.6 Plus

Choosing the right model for interactive PR chat is not the same decision as choosing the right model for a batch review pipeline. Batch review can afford latency. It runs in the background while your CI checks complete. Interactive chat has to feel like talking to an engineer — which means responses need to arrive in seconds, not minutes, and the model needs to hold genuinely large amounts of context without losing coherence deep in a thread.

Qwen 3.6 Plus was the clear choice on all three dimensions that matter here: context capacity, benchmark performance, and speed.

One million tokens of context

A 1-million-token context window sounds like a spec sheet number, but it has a concrete practical meaning for PR chat. A large PR can touch dozens of files. A monorepo with deep dependency chains may require reading many files beyond the diff itself to understand the change properly. A long-running PR might accumulate hundreds of comments over days or weeks of discussion. All of that needs to fit in the model's working memory simultaneously.

With 1M tokens, Critique can include the complete diff, the full content of every relevant file, the entire comment history, and still have room to reason. There is no truncation, no summarization of the thread, no soft-cutting of file contents at an arbitrary character limit. The model sees everything, and its answers reflect that.

Benchmark performance

Qwen 3.6 Plus is not just a large-context model that handles volume — it is a frontier-level coding and reasoning model that has been measured against the best alternatives available. The benchmark results are striking, and they explain why we chose it over the alternatives we evaluated.

The SWE-bench Verified score of 78.8% represents a meaningful improvement over the Qwen 3.5 series and puts it in genuinely competitive territory with frontier models. SWE-bench tests the model's ability to fix real bugs in real open-source codebases — the closest available proxy for what the model actually needs to do when you ask it to "/fix" something in your PR.

The DeepPlanning long-horizon score is especially relevant for PR chat. Long-horizon reasoning tests measure how well a model maintains coherent reasoning across a complex task with many steps — exactly what happens when a reviewer and author exchange a long sequence of questions and follow-ups across a multi-file PR. At 41.5%, Qwen 3.6 Plus significantly outperforms GPT-5.1-Codex, GPT-5.2, and GPT-5.3-Codex in this dimension. For PR conversations that run long and get complicated, this matters.

Speed

Qwen 3.6 Plus is exceptionally fast. In our testing, responses to typical PR chat messages — a question about a function, a /fix request for a specific finding — stream back within 3–6 seconds of the webhook being processed. That is fast enough to feel like an actual conversation rather than a polling loop.

This matters more than it might seem. A review tool that takes two minutes to respond to a follow-up question is not a conversational tool — it is a slower version of the original static report. Speed is what makes the interaction feel like collaboration rather than waiting.

Real workflows

What this looks like in practice

Here are the patterns we have seen teams reach for most in the first days of using this feature.

The thread as a record

One underrated benefit of the conversational format is what it produces as a side effect: a documented decision trail. When an author asks Critique to explain why a specific pattern was flagged, and Critique explains the risk, and the author adjusts the code and asks for a re-review, all of that is preserved in the PR thread. Six months later, when someone is trying to understand why that auth flow was written the way it is, the reasoning is right there in the history.

This is something static review reports cannot provide. A block of findings appended to the PR gives you the conclusions without the reasoning. An interactive thread gives you the conclusions, the questions, the answers, and the iterations — a complete picture of how the team thought about the change.

Setup

How to get started

If you already have the Critique GitHub App installed, interactive PR chat is live for your repositories with no additional configuration required. Two webhook subscriptions are needed — issue_comment and pull_request_review_comment — which the App handles automatically.

If you do not yet have the App installed, the install flow takes under two minutes. Select the repositories you want Critique to monitor, authorize the App, and the bot will be ready to respond to @critique mentions in any PR on those repos immediately.

What comes next

Interactive PR chat is the first step toward making Critique a full participant in the development workflow rather than a tool that runs in the background and produces a static artifact. The next capabilities we are building in this direction include persistent context — so Critique remembers the decisions made in previous PRs on the same codebase when answering questions in new ones — and agentic fix proposals, where a /fix command can trigger Remedy to write and push the actual patch to the PR branch directly.

The goal is to close the loop entirely: AI writes the code, Critique reviews it automatically, the author and reviewer talk to Critique interactively to understand and refine it, and Remedy applies the agreed fixes. Every step in that loop is either live or in active development.