Skip to main content
The weakness of agent-written code isn’t usually syntax — it’s an agent grading its own homework. tiny-brain’s answer is structural: the moment a feat: commit lands, a separate review agent with an isolated context challenges the work. It didn’t write the code, didn’t see the conversation, and has no investment in the approach.

​
What the reviewer does

The reviewer reads the commit against the task it claims to implement and attacks it: does the implementation cheat the tests? Does the code or its docs overstate what actually exists? Is complexity hidden, is a claim unsupported, did an unrelated change ride along? It then returns one of two verdicts:
  • clean — the cycle closes, the loop moves on.
  • needs-refactoring — concrete findings, each with a suggested change.
Verdicts and findings are persisted per task and per commit, so the dashboard (and any teammate) can see not just that a task passed review, but what the reviewer objected to along the way.

​
The refactor gate

Findings aren’t advisory. The hooks only accept a refactor: commit while a review is active, and a needs-refactoring verdict expects one — the findings get addressed (or explicitly rebutted) before the task’s cycle closes. This is the REFACTOR stage of the loop: driven by a reviewer’s findings, not by taste.

​
Beyond adversarial: the wider pipeline

Adversarial review is the always-on gate (enableAdversarial in the repo’s tiny-brain config). Around it sits a configurable quality pipeline that can include coverage analysis, mutation testing (enableMutationTesting), security scanning (enableSecurityScanning), and repository-wide quality runs — analyser passes plus specialist review agents (code quality, security, performance, testing) whose scored results are written into the repo under docs/quality/. The principle across all of it: the pipeline is the quality bar. Agents don’t invent their own review standards per session — they run the gates the repo has configured, and the gates leave a record.