More Thorough AI Review for Claude Code, Codex, and Claude Cowork

AI can produce a lot of work quickly. Reviewing that work is still surprisingly shallow.

Most AI review feels like one smart person reading once. The model scans the change, notices a few things, and returns a plausible summary. That can be useful, but it is easy for one pass to miss a broken contract, a race condition, an unsupported claim, or an accidental promise.

I wanted a review process that behaves more like a group of skeptical specialists. Each specialist gets a narrow mandate. They investigate independently. A stronger parent model then checks their claims, rejects weak findings, and produces one report.

That idea became two open-source projects: Friendly Adversary for software and Zero Defect for business work.

One Idea, Two Tools

The shared idea is adversarial review through focused lenses.

A lens is a reviewer with one job. It does not try to judge everything. That narrower scope encourages a deeper investigation and makes overlap useful. Two lenses may reach the same defect from different directions, which gives the final judge more evidence to work with.

The parent model still owns the result. It reads the independent reports, checks the evidence, resolves duplicates, assigns severity, and decides what is actually worth fixing. The purpose is to make important defects harder to miss without generating an inflated list.

Friendly Adversary for Code Review

Friendly Adversary is a local Claude Code and Codex code review system for TypeScript, JavaScript, and Python repositories. It can review a pull request, audit an existing codebase, or challenge a new codebase design before scaffolding begins.

Its pull request review uses nine lenses:

Anti-slop maintainability looks for needless branches, indirection, weak type boundaries, misplaced ownership, and complexity that creates a concrete maintenance burden.
Contracts checks whether producers and consumers still agree on requests, responses, functions, events, serialization, pagination, and durable identifiers.
Correctness follows reachable behavior and looks for wrong branches, missed edge cases, unsafe empty states, swallowed errors, and partial side effects.
Data integrity challenges schemas, migrations, queries, transactions, ordering, precision, and persistence invariants.
Operability asks whether failures are bounded, visible, attributable, and recoverable in real operation.
Repository fit checks placement, dependency direction, reuse, naming, and whether the change bypasses an established abstraction or recreates existing behavior.
Security looks for untrusted input crossing protected boundaries through missing authorization, injection, path traversal, unsafe token handling, secret exposure, or tenant bypass.
State and concurrency tests what happens under retries, cancellation, duplication, reordering, stale responses, and concurrent execution.
Verification asks whether important behavior has focused proof that would fail for the regression being discussed.

The system also bundles deterministic tools instead of asking the model to rediscover every clue. Semgrep, Ruff, an Oxlint-compatible engine, and ripgrep run locally as WebAssembly. Their native output becomes evidence for the review. Repository-configured checks can also run during a pull request review when the repository is trusted.

For each pull request lens, Friendly Adversary launches an isolated local Codex CLI process using the lower-cost Luna model. The lens runs with high reasoning and Fast mode in a read-only sandbox. All nine run concurrently. The Claude Code or Codex model that started the review acts as the more capable final judge. This keeps the broad investigation relatively inexpensive while reserving the strongest model for adjudication.

Zero Defect for Business Work

Zero Defect applies the same philosophy to English-language business deliverables in Claude Cowork. It is intended for proposals, emails, candidate summaries, product plans, reports, requirements, spreadsheets, presentations, and similar work.

Its seven lenses are different because business documents fail differently:

Commitments finds guarantees, deadlines, service levels, scope promises, and implied obligations that may lack authority, conditions, evidence, or ownership.
Evidence checks whether material claims are supported and whether citations are real, current, authoritative, and strong enough for the nearby statement.
Numbers recalculates arithmetic and challenges units, denominators, baselines, periods, precision, forecasts, and inconsistencies across prose, tables, and charts.
Consistency finds propositions, definitions, recommendations, dates, and status claims that cannot all be true at once.
Decision completeness asks whether the audience has the owners, dependencies, risks, tradeoffs, approvals, acceptance criteria, and next steps needed to act safely.
Language precision looks for ambiguity, hidden actors, undefined terms, audience mismatch, and wording that can reasonably be interpreted more strongly than intended.
Anti-slop looks for formulaic AI writing, empty intensifiers, canned transitions, repeated summaries, vague authority, inflated language, and other patterns that make writing sound polished without making it more useful.

Zero Defect is deliberately simple. It has no scripts, MCP server, package dependencies, local service, or filesystem output. Claude Cowork invokes the seven reviewers in parallel, and the parent model validates and consolidates their findings. It diagnoses defects and suggests concise repairs. It does not rewrite the deliverable unless you separately ask Claude to do that.

A Standard, Not a Guarantee

Neither project can promise defect-free work. Models can miss things. Deterministic analyzers have coverage limits. A reviewer can misunderstand intent, and a clean report does not replace testing, professional judgment, security review, legal review, or accountable human approval.

The standard is more useful: review important work from multiple explicit angles, demand evidence for findings, and make the final judge distinguish a material defect from a nitpick.

Both projects are early and opinionated. They reflect the review process I wanted for my own work, and they will keep changing as real use exposes weak prompts, missing lenses, noisy checks, and better orchestration patterns.

Feedback and forks are welcome. Contributions are welcome for consideration too, although I may not accept every proposed change. The repositories are the best place to inspect the full design and decide whether the approach fits your workflow: