Critique vs Built-In Agent Checks
Codex, Claude Code, and OpenCode should check their own work. They should not be the only witness that the work is finished.
Trust, then verify
Built-in checks versus an independent finish pass
critique.sh
Critique vs built-in agent checks is not a contest over which coding agent can run a test command. Codex, Claude Code, and OpenCode can all be asked to inspect a diff, run tests, and revise a patch. The difference is what happens after the agent says it is finished. Built-in checks are the author checking its own work; Critique is a separate finish pass that tries to establish whether the claim holds, then gives the original agent evidence it can act on.
What “built-in checks” means here
“Built-in checks” is a searcher’s phrase, not one uniform feature. In practice it means the verification loop inside the agent that wrote the change: inspect the modified files, run a unit test or typecheck, perhaps ask the same model to review the diff, then summarize the outcome. That loop is valuable. It catches syntax errors, broken imports, obvious test failures, and simple misunderstandings while the agent still has the task context fresh in memory.
Codex is designed to work across a repository, run commands, and prepare code changes. Claude Code can be prompted to test, debug, and resume a terminal workflow. OpenCode provides configurable agents, permissions, and commands, including read-only review roles. None of that makes any of them inadequate. It means the implementation loop is already capable—and therefore deserves a compact, independent handoff rather than a second product workflow pasted on top of it.
The useful comparison is author-side iteration versus a separate completion decision, not “which model is smarter?”
| Question | Built-in agent checks | Critique finish pass |
|---|---|---|
| Who owns the task? | The coding agent that implemented it. | The original agent still owns it. Critique only challenges the candidate finish. |
| When does it run? | Repeatedly during implementation and debugging. | At the handoff, when a change needs an independent decision before the agent moves on. |
| What does it optimize for? | Fast feedback and the next edit. | A reproducible result: what was examined, what was tested, what changed, and what remains uncertain. |
| What happens if it finds a defect? | The author revises its own patch. | Critique can return no repair, a repair pack, or a verifier-approved patch for the calling agent to use. |
| What it cannot replace | A fresh perspective on the author’s assumptions. | Your deterministic CI, security controls, repository ownership, or human risk judgment. |
Why the self-checking loop has a blind spot
The problem is not that an agent is intentionally dishonest. It has no intent to deceive. The problem is path dependence: the same interpretation of the task influences the implementation, the tests selected, and the final prose. If the agent misunderstood “cancel an invoice” as “hide it from the UI,” it may write a precise test for hiding it, see green, and confidently report completion. A fluent summary makes that partial evidence feel more complete than it is.
Humans have the same failure mode. We call it confirmation bias, tunnel vision, or simply being too close to the change. Mature teams counter it with code review, test plans, release checks, and a second set of eyes. Agent-native work needs the same separation without forcing a developer to stop the session, open a dashboard, and reconstruct what happened from a comment thread.
How Critique fits inside an agent session
Critique is not a rival coding agent you hire beside Codex, Claude Code, or OpenCode. The developer works in their normal agent. When that agent reaches a candidate finish, it calls critique finish. Critique reconstructs the working-tree change in disposable local workspaces, tests consequential hypotheses, and returns a deterministic JSON result. The original agent receives that result and continues the conversation with the user. From the user’s point of view, there is still one agent session and one owner of the task.
Install once; the agent makes the handoff
The human authorizes the CLI once. Managed finish instructions let Codex, Claude Code, and OpenCode call it at the right moment.
npm install --global @critiquedotsh/cli
critique login
critique setup --with-chatgpt
critique model gpt-5.6-terra
critique integrate --agent allThe --json contract is intentionally for the calling agent, not for a human to parse at the terminal. It includes the outcome, whether a repair was applied, changed paths, issues, limitations, artifact IDs, usage, and a stable exit code. Repair is explicit: --repair none returns a judgment only, --repair pack prepares a bounded proposed fix, and --repair apply applies only a verifier-approved patch back to the original working tree.
Local-first verification matters
Real repositories are not clean benchmark fixtures. They depend on development databases, test credentials, local service URLs, and ignored environment files. Critique’s full reproduce-repair-verify loop is local-first at launch. With --env auto, local development and test environment files can be made available inside the disposable workspaces used for validation. They are excluded from the change capsule, patches, proof artifacts, and cloud uploads, then disappear with the temporary workspace.
That boundary is part of the product thesis. A remote verifier that cannot reproduce the local system will produce theatre; a verifier that casually exports local secrets is unacceptable. Critique would rather state a limitation than manufacture a green verdict. Remote execution is a separate, more limited path until it can meet the same evidence and safety contract.
When should you call Critique?
- 1Did the change touch money, identity, permissions, or deletion?Use an independent pass. A green happy-path test is not enough evidence for authorization, billing, migration, or destructive behavior.
- 2Did the agent make a cross-file or behavior-changing edit?Use it when the risk is not visible in one diff hunk: API contracts, state transitions, queues, data models, and service boundaries are classic cases.
- 3Is this an awkward bug that already survived one attempt?Use it. The valuable outcome may be a clear limitation or a small verified repair, not a confident narrative from the same stuck context.
- 4Is this a formatting-only or low-consequence edit?Probably not. Preserve the fast local loop for trivial changes; a completion layer should earn its latency and spend.
The practical recommendation
Do not choose between your coding agent and Critique. Let Codex, Claude Code, or OpenCode do what they are good at: understand the task, make the implementation, run quick checks, and iterate. Then give the agent one reliable way to ask, “Does my finish claim survive a fresh pass?” That is the completion layer. It is smaller than a new review ritual and more honest than treating self-report as proof.
Give your coding agent a second opinion.
Keep the fast loop you already have. Add an independent finish pass when “done” needs evidence another system can inspect.
Install the finish CLI