ArchitectZero
Review below, above and beyond the diff.
Code review the way a principal engineer does it — below the diff for bugs and security, above it for architecture and intent, beyond it for what the code actually does in production. For legacy systems it discovers the architecture before it reviews anything.
- built for
- Staff+ engineers
- Architects
- CTOs
- Consultancies
Why this exists
Why ArchitectZero exists
Code review has settled into a comfortable shape: a tool reads the diff, checks it against a rulebook, and leaves comments. Done well, that catches a real class of defect, and the market is crowded with tools that do it well.
It also means the review stops precisely where the expensive questions start. Nothing in that loop asks whether the change respects the architecture the team agreed on eighteen months ago. Nothing checks whether the diff implements the ticket it is attached to, or merely something adjacent to it. Nothing consults what the code does once it is running. Those are the questions a principal engineer asks in a review, and they are the ones that get skipped when the principal engineer is in another meeting.
ArchitectZero reviews below the diff — bugs, security, quality — above the diff — architecture, intent, judgment — and beyond the diff — runtime, performance, contracts, production feedback. Where the architecture was never written down, which is most legacy systems, it discovers and models the architecture first, because there is no point grading a change against a document that does not exist.
One position worth stating plainly: the architecture is judged against the codebase, not against a file the audited team wrote. A declaration of intent is useful context. It is not evidence.
Service lines
Four lines of work.
S1 — Audit Services
The review engine. Below the diff for bugs, security and quality; above it for architecture conformance and intent; beyond it for runtime behaviour. Free on your first project, because a workspace should be able to produce a real finding on its own code before it costs anything.
S2 — Solutioning Services
Author the target instead of only grading the present. Versioned solution documents and diagram artifacts, produced by a loop that asks you the questions it cannot answer rather than guessing and calling it a proposal.
S3 — Legacy Modernization
Discover the architecture of a system nobody documented, model where it bends under load, and produce a modernization roadmap — plus the programme tracking to see whether the roadmap is actually being executed.
S4 — Active Support
Ongoing engagement against a live workspace rather than one-off runs. Available on Enterprise, with quotas agreed per engagement instead of per seat.
Capabilities
What it actually does.
Architecture conformance
Grade a change against your declared architecture and your ADRs. The as-built model is derived from the codebase, never from a declaration written by the party being audited — that is a policy, not an oversight.
Intent verification
Does the diff actually implement the ticket it claims to? A review that only reads the code cannot answer that. One that reads the spec alongside it can, and it is the question reviewers skip most often.
Runtime intelligence
Review the code that is running, not just the text that was written. Traces, performance data and incident history feed the same verdict as the static analysis.
Landscape discovery
Point it at a scattered codebase and its equally scattered documentation, and get the architecture documentation nobody ever wrote — the baseline everything else needs in order to have an opinion.
Bottleneck modelling
Model where the architecture bends under load and what the throughput ceiling actually is, then get an untangling order rather than a proposal to rewrite it.
Project-scoped context
A project tier sits between the org and the repo: many repos plus the docs, PDFs, recordings, Jira, Confluence and Drive folders that explain them. What the platform learns stays in the project until it is promoted.
Governed promotion
Learning that generalises beyond one project can be submitted for org-level memory. Deliberately a submission rather than an automatic write — org memory is the one store you cannot afford to pollute.
Skills as an extension surface
Import skills to extend what the models can do, governed on the tool bus. A capability can be added without waiting for us to ship it, and without handing an unreviewed tool the keys.
Under the hood
Specifications.
- Service lines
- S1 Audit · S2 Solutioning · S3 Legacy · S4 Support
- Scope
- Workspace → project → repo
- Context sources
- Repos · docs · PDFs · video · Jira · Confluence · Drive
- Trial
- Free — S1 on one project
- Projects
- Free 2 · Standard 5 · Enterprise 100
- Isolation
- Structural per tenant, not a runtime check
- Model posture
- Deterministic first, LLM when justified
- Audit
- Every consequential act is an event
Questions
The ones people actually ask.
How is this different from CodeRabbit, Greptile or SonarQube?
Those review below the diff, and several do it well. The gaps ArchitectZero targets are the ones no tool covers today: whether a change respects the architecture, whether it implements the ticket it claims to, and what it does once it is running. Most teams will run both.
We have no architecture documentation. Can it review anything?
That is the common case, and the reason legacy modernization is its own service line. Landscape discovery builds the model from the code and whatever documentation does exist, so by the second pass there is something to review against.
Do we declare our architecture in a file for it to check?
No, and that is deliberate. The as-built model is derived from the codebase, because a declaration written by the team being audited is not evidence of anything except intent.
What does the free trial actually get you?
Audit Services on one project, with no payment. The bar we set for it is that a new workspace can produce a real finding on its own code before anyone is asked for money.
Can we get reports in our own format?
Yes. Tenants using the platform for reviews only can define their own report structure and branding, because the report is the artefact that actually gets circulated.