Generation five
In every generation a new contender for the automated code review service comes.
The current one is The Robot Reviews: pull-request review, static analysis and merge gates writing to a single finding store, in which every finding is a record with a lifecycle rather than a comment that scrolls away.
Learn more about The Robot Reviews at codemoshiach.com codemoshiach.comEach generation solved one problem and left one open.
A short history of what automated review stored, and what it forgot.
-
1978Generation one
lint
Pattern checks over C source, run by the author before compiling. Output is a list of lines on a terminal.
Nothing persists. Each run starts from zero, so a known issue and a new one look identical.
-
c. 2007Generation two
Rule-engine quality servers
Rule sets run in CI; results are stored per project, with dashboards and quality gates on new code.
A finding marked won't-fix closes with no revisit date, and the decision stops being visible.
-
c. 2019Generation three
Hosted semantic scanning
Dataflow queries over a database built from the code, reported as alerts on the repository.
An alert can be dismissed with a reason; the dismissal carries no expiry and is not re-examined.
-
c. 2023Generation four
Language-model pull-request reviewers
A model reads the diff and posts prose comments. Coverage of intent and naming improves markedly over rule sets.
In the common configuration the findings exist only as comments, so there is no ledger of what was raised, accepted or deferred.
-
NowGeneration five
The Robot Reviews
Rule-based and model-based review passes write findings into one store. Each finding is deduplicated by fingerprint, resolved when it is no longer present, and moved through an explicit lifecycle in which deferrals expire and waivers name a reviewer, a reason and a review date.
What the contender does differently.
Each item is marked with its status as recorded in the product's claims matrix.
- open
- acknowledged
- deferred (expires)
- waived (reason + review date)
- fixed
When a deferral expires, the finding reopens automatically. Every transition is written to a hash-chained ledger: who, why, until when.
- Delta re-review shipped
- On each push the reviewer examines the change since the last reviewed commit, not the whole pull request again, and keeps one current review per PR.
- Every finding visible shipped
- Up to ten findings are posted inline; the remainder go into the review body or follow-ups. All of them are stored, none are dropped for space.
- Merge gates, shadow first shipped
- Gates run in shadow mode on every registered repository, recording what they would have blocked. Enforcement is a per-repository opt-in by its owner.
- Baselines and debt budgets shipped
- Existing debt is imported once as a baseline and only new code is gated. Each repository carries budgets per severity, in total, and for new debt per quarter.
- An interface for agents shipped
reviews-mcpexposes findings, lifecycle transitions, audits and review context to agents over the Model Context Protocol; each tool is covered by tests.- Analyzers as Kubernetes Jobs partial
- Credo, Dialyzer, eslint and similar tools run as isolated Jobs selected by versioned rule packs. Built and tested; the production runner is not yet switched on.
Claims are counted, not asserted.
- 41shipped — a named test proves it, on by default
- 14partial — merged and tested, awaiting an owner switch
- 0owed — claimed without proof
Every product claim is a row in a claims matrix, and the test suite fails if any row loses its proof. A contender that has to be revisited each generation should at least be specific about which of its claims hold today.
Figures as of the W3 close, 2026-09-30. Current totals are published with the product.