We Killed the Dashboard. It Wasn’t the Workflow.

We built a broad AI code review product around a familiar assumption: code changes happen in one place, and a human comes to a dashboard somewhere else to decide whether they are good. It was a reasonable assumption. It is also the wrong center of gravity for a world where the person is already working through Codex, Claude Code, or OpenCode and the agent—not the human—needs the next piece of evidence.

The old product had the right anxiety and the wrong place to solve it

The anxiety was real: AI makes code faster than a team can carefully review every diff. We built routes, controls, review runs, comment flows, policy surfaces, and the broader apparatus a human operator expects from a code review platform. The product could assemble a lot of information. But information is not the same as a useful handoff. If the answer to “my agent says it is done; what now?” is “open the dashboard, find the run, read the findings, decide how to explain them back to the agent,” the product has inserted itself between the work and the decision it exists to improve.

That is the subtle dashboard trap. The screen becomes the product because it is visible. The actual job is less glamorous: create an independent, inspectable answer at the precise moment a completion claim is made. The user does not want a second coding agent to monitor. They want their existing agent to know whether it should continue, repair, or surface a limitation. The interface for that job is a tool call and a contract, not a queue of cards.

What “completion layer” means

A completion layer sits after implementation and self-checking but before a change is treated as complete. It does not write the first version of the feature. It does not replace CI. It does not take merge authority. It receives a candidate finish: the working-tree change, the intent behind it, and the authoring agent’s belief that the job is done. Then it tries to establish whether that belief holds under a fresh, bounded pass.

The user should not operate two agents

This is the part of the pivot that matters most. Critique is agentic under the hood because verification requires model judgment, repository inspection, and repair work. But it is not a rival agent the user has to direct separately. The user talks to their main coding agent. That agent calls Critique mid-session when it reaches a candidate finish. Critique returns a deterministic outcome, evidence, limits, and optionally a repair. The main agent turns that result into the next conversational step with the user.

From the user’s perspective, that removes a category of friction. There is no “go ask the reviewer bot,” no extra ticket, and no requirement to learn where evidence is buried. The primary agent remains accountable for understanding the task and making the next change. Critique is the infrastructure that gives it a better basis for that change. The slogan is intentionally literal: Critique is the teammate your agent calls.

The contract is the product

The primary command is critique finish. --repair none asks for a verdict and proof only. --repair pack asks for a bounded proposed repair. --repair apply permits an approved repair to return to the caller’s working tree. --json is first-class because the audience is another tool, not a person reading a terminal flourish. The response carries the outcome, repair state, changed paths, issues, artifact IDs, limits, usage, and a stable exit code.

That shape lets the main agent remain cheap and fast where it should be cheap and fast. The broader system is model-flexible rather than married to one vendor or one expensive reasoning pass. A team can use the agent and model that make sense for ordinary implementation, then reserve stronger independent capacity for the final claim. The model is a component. The contract—the separate finish role, evidence boundary, and repair discipline—is the defensible product.

Local-first is not a launch compromise

The full reproduce-repair-verify loop launches locally first because local repositories are where the conditions of truth usually live. Test fixtures, ignored environment files, service URLs, and the uncommitted worktree can be essential to reproducing behavior. Critique creates disposable local workspaces, can make local development and test environment files available only inside those workspaces, excludes them from patches and proof artifacts, and never uploads them to Critique Cloud. Only a verifier-approved patch can come back to the caller’s tree.

That is a constraint worth preserving. A remote system that says it verified something it could not faithfully run is worse than no verifier; a system that solves the fidelity problem by absorbing local secrets is worse still. Remote execution can expand later, but only where it can maintain a comparably clear evidence and safety boundary. “Unknown because the environment did not support reproduction” is a more trustworthy output than a green badge with nothing behind it.

What we still need to prove

The pitch contains a circularity problem: do not trust the first agent’s self-report; trust Critique’s report instead. Architecture alone cannot answer that. A fresh workspace and separate role are sensible reasons to expect a better challenge, not evidence that it catches more real failures. The product needs to earn this claim in public with a benchmark that measures exactly the thing users care about: disagreement with a claimed finish that turns out to be justified.

Skills should be routed to reproduction, not comments

The temptation is to preload every code-review skill and call the result “thorough.” That is how a focused completion layer turns back into a dashboard full of generic comments. The better direction is targeted routing: choose skills based on the language, framework, and risk surface touched by the diff, and require each skill to terminate in a reproducible check. A payments skill should attempt a payment-specific failure mode. An authorization skill should test a boundary. “This looks unsafe” is not a completion-layer outcome.

Who this is for first