The Robot Reviews Live in the Noizu fleet
Your code review
remembers.
Every codebase accumulates decisions to deal with something later. Almost every tool forgets them the moment they're made. We're building the one that doesn't: findings with a lifecycle, deferrals that expire, waivers that are signed and dated.
Live now, across the fleet.
The Robot Reviews is installed across the Noizu organization fleet — five organizations and every repository in them. Here is what runs in production today, not on a slide.
The review agent
Every opened pull request gets a structured audit within seconds: a what-changed summary, a risk assessment, and severity-tagged findings anchored to exact file and line. Complex changes come with a mermaid diagram of the new architecture.
The commit story, checked
The reviewer reads the commit history as part of the review. Does the series tell a coherent story? Do the messages describe what the diff actually does? A message that misdescribes its diff is itself a finding.
Check runs, honestly labeled
A check run lands on every pull request head. Today it is a neutral presence check that says what it is — merge-gate conclusions arrive in the next slice on the same surface.
Re-refresh on every push
New commits on an open PR? The audit updates in place — one current review per pull request, never a pile of stale ones.
A finding store with a memory
Findings live in Postgres behind a tamper-evident hash chain, and the dashboard triages them — acknowledge, defer, waive — through the same audited path whether the call comes from a human or an API.
Signature-verified, replay-safe
Every webhook is HMAC-verified against the raw bytes and de-duplicated by delivery id. A redelivered event can't make the reviewer talk twice.
Debt amnesia is a product decision.
Static analysis has been solved for a decade. What hasn't been solved is what happens after the finding — the part where a person looks at it, decides it can wait, and the tool quietly agrees forever.
"Won't fix" is a black hole
A finding gets dismissed with a shrug and a dropdown. No reason, no owner, no date. Six months later nobody can tell you whether it was a real decision or a bad afternoon.
Suppressions outlive their reasons
The inline comment silencing a warning was correct when it was written. The code around it has changed eleven times since. The suppression has never been re-examined.
The debt lives in three heads
Analysis output, review findings, and the decisions made about them end up in three different places, none of which is the one you check before you merge.
Findings have a lifecycle. Not a delete key.
Every finding is a durable record that moves through explicit states. Two of those states carry a clock. Nothing leaves the ledger by being ignored.
- open found, unread
- acknowledged seen, owned
- deferred expires on a date
- waived reason + review date
- fixed gone for real
Deferred is not forgiven
A deferral is a promise with a date attached. When the date passes, the finding reopens itself and lands back in front of whoever owns it. You can push it again — you just can't push it into the void.
Waivers are signed
Waiving a finding requires a written reason and a review date. The ledger keeps who, why, and until when. It's an audit trail because it was one from the start, not because someone bolted reporting on.
Baselines make legacy debt a budget
Import what's already there, once. Then gate on new code only. Existing debt becomes a number that trends instead of an ambient cloud of guilt nobody can act on.
Budgets, per repo
Set a ceiling — no more than N blockers, this much new debt per quarter — and watch the trend line rather than the raw count. Merge gates become policy you wrote down, not a vibe.
Three surfaces. One finding store.
review surface live · CI orchestration on the roadmap
Build, scan, and review are usually three tools that don't share a vocabulary. Here they write to the same ledger, so a merge gate can reason about all three at once.
CI/CD orchestration
Pipelines as code, run scheduling, status gates, and an audit trail of what ran against what. Your existing runners stay the muscle — this is the brain that decides and remembers.
Static analysis
Pluggable analyzers run as isolated jobs, one image apiece, results normalized into a single finding schema. Rule packs per repo, baselines, and quality gates that only look at new code.
PR review & audit
Rule-based and agent-assisted review passes on every pull request. Findings land in the same store as everything else, which means the gate is policy — not whoever happened to read the diff.
A review is only as good as its context.
Most automated review re-derives your codebase from scratch on every run, which is why it keeps telling you things you already decided. Ours reads what your team already wrote down.
-
Docs mapped to code
A doc-pointer registry links architecture and layout docs to the modules they describe, so a verdict can cite the design rather than guess at it.
-
Style-guide aware
House style guides are first-class review references, and house style overrides language defaults. Your conventions win arguments with the linter instead of losing them.
-
Diagrams of what changed
Review passes produce and refresh diagrams explaining what the changed code actually does — the artifact reviewers always wanted and never had time to draw.
-
Doc-drift as a finding
Change code whose documentation didn't move, and that's a finding like any other — soft-tracked, deferrable with an expiry, visible until the docs catch up.
Agents don't want a console.
A growing share of review, triage, and remediation is done by agents. They need an API surface with the same authority a human reviewer has — not a web UI to scrape.
Every finding operation is available programmatically over MCP. Query the ledger, acknowledge, defer with an expiry, waive with a reason, open an audit. Same permissions, same audit trail, same lifecycle rules. An agent that defers something is held to the date exactly like anyone else.
On the workbench.
Shipped features graduate up the page. Everything here has a design and a milestone — most of it has merged code waiting on its run.
Merge gates
Check runs grow conclusions driven by policy: blocking severity, new-code-only gating, per-repo budgets. The surface is already on every pull request head.
Rule packs and per-toolchain analyzers
Credo, Dialyzer, Sobelow, eslint, tflint — each in its own isolated job, results normalized into the same finding schema, gated on new code against your baseline.
Issue-tracker bridges
Audits and reviews propose work items; on approval they land in the tracker you already use — GitHub Issues today, Jira, Asana and ClickUp behind the same adapter.
Instrumentation pull requests
The reviewer doesn't just annotate — it prepares patches. Doc pointer trackers, telemetry spans, doc drift fixes: proposed on a derived branch, applied on your explicit yes.
Doc-drift as a finding
Change code whose documentation didn't move, and that's a finding with the same lifecycle as everything else — visible until the docs catch up.
Performance and telemetry signals
Deployment health and test-run events ingest alongside static findings, so the ledger sees what happened after the merge too.
Sign in with fleet SSO.
Dashboard triage, the finding ledger, and review dashboards are for Noizu people and their agents. Sign in through Authentik — the same identity you already use across the fleet.
Get beta access
The Robot Reviews is in beta with the Noizu fleet. Drop your email and you're on the list — we'll let you know the moment your repos can be onboarded.
Already on the fleet? Sign in with your @noizu.com account.