Review the change, not just the diff.
LGTY reconstructs what a pull request actually does, affects, and intends — grounded in your code and its production reality — so your attention goes to judgment.
Less archaeology, more judgment.
A diff shows what text changed. Reviewers spend most of their time reconstructing what it means, affects, and intends. LGTY does that reconstruction — with a receipt on every claim.
Capabilities
Change Analysis
ChangeTells you what code runs differently — call-graph receipts first, model prose marked as judgment.
Statically resolved · dynamic dispatch not shown.
2 Where your judgment is needed
ChargeService.create
calls the now-idempotent path directly
billing/charge.rb:41RefundWorker.perform
re-invokes on transient failure — same idempotency key
workers/refund_worker.rb:19● interpreted from diff — your judgment
PR description says “no behavioral change” — precedence shifted
Expired-key path now re-charges instead of failing closed.
billing/charge.rb:88 · description ¶2+ 2 more callers of the changed code
This is what shows up on your next PR.
Sign in with GitHubProduction Impact
ProductionDesigned to surface what an incident report would show — at review time, not in the postmortem: downstream consumers by production traffic, migration lock risk, and who’s still on the old behavior, each claim carrying its own coverage and snapshot age.
Row estimate, snapshot age, and coverage travel with every claim.
2 Where your judgment is needed
Migration takes an ACCESS EXCLUSIVE lock
DROP COLUMN on a hot table, no CONCURRENTLY path, rollback not defined. ~2.1M rows · estimate · snapshot 6h ago.
db/migrate/20260714_drop_legacy_status.rbinvoicing-export — not connected
No observability source covers this consumer. Declared uncovered, not “no impact.”
coverage: uninstrumented3 live consumers still on the old contract
settlement-worker reads the prior field. Coverage ~78% of traffic on this path, snapshot 34m ago.
trace: settlement-worker+ 2 more consumers, including 1 uninstrumented
Visual Review
VisualSurfaces the before-and-after render across the states a change touches, right next to the diff — the same receipt-and-coverage discipline, applied to what the user sees.
Rendered — before / after · no-discount state
2 Where your judgment is needed
“Update payment” overlaps the total on the no-discount layout
The spacing tidy renders clean in 3 of 4 states — CI stayed green throughout. No-discount is the legacy-plan layout with one fewer row; nobody wrote a story for it, so the overlap went unflagged.
rendered state · after · no-discount · BillingSummaryCard.css:81 of 4 rendered states shown here · +3 more states →
FAQ
Questions reviewers & their teams ask
What LGTY does, what it touches, and what it does when it can’t see enough to say anything.
The basics
What does LGTY actually do?
LGTY posts one brief on each pull request that reconstructs what the change does, affects, and intends — what now behaves differently, who depends on it in production, and how the screens render. Every claim carries a receipt you can open and check in seconds, so your attention goes to judgment instead of archaeology.
How is this different from an AI review bot, or from my own coding agent?
An LLM reading your diff — and your own coding agent — both see the changed text, not the running system. LGTY grounds the brief in production reality they can't reach: live downstream consumers, migration facts read from real schema metadata, and rendered screens from your own preview build. Every line links to a derivation or a live record you can open yourself — never a self-asserted confidence score.
Does it block or approve my pull requests?
No. The brief informs your review; it never gates the merge and never leaves an approval in your name. One comment, updated in place — not a status check that can turn red and hold up a merge.
How do I install it, and how soon do I see a brief?
Sign in with GitHub, install the read-only app, pick your repositories. The first brief appears on your next pull request — Change Analysis works immediately, zero integration. Connecting your observability platform and preview builds deepens it from there.
Access & data
What access does LGTY need — does it touch our source or production data?
A read-only GitHub App, plus read-only, metadata-only connections to tools you already run. It reads things like row estimates and migration lock classes from cheap metadata — never a COUNT(*), never a production database password. It does not copy your raw data out. Every connection is scoped and revocable: read-only · metadata-only · scoped · revocable · no raw-data egress.
Is our code or data used to train models?
We send Anthropic only metadata and a minimal diff slice — never your raw source tree, never production data. Anthropic does not use commercial-API traffic to train its models. If you bring your own Anthropic key, your requests run entirely under your own Anthropic account and its terms.
Does it work on private repositories, monorepos, and pull requests from forks?
Private repositories and monorepos, yes. For a pull request opened from a fork, LGTY treats the incoming code as untrusted — any rendering of it runs in an isolated, credential-free sandbox that holds no tokens of any kind, so a fork PR can never reach your connected systems.
Coverage & honesty
What are the three capabilities?
One brief that deepens: Change Analysis — what now behaves differently and who calls it, with file:line receipts; works on any PR, day one. Production Impact — downstream consumers by production traffic, migration reality, and who's still on the old behavior, each claim grounded in connected production metadata. Visual Review — the screen rendered before and after, across the states a change actually touches.
What happens when LGTY can't see enough to say anything?
It says so. Every production-grounded claim declares its own coverage and snapshot age. On net-new or uninstrumented code it degrades to silence rather than a false all-clear. A brief with nothing to flag is a first-class outcome, not padding.
For Visual Review, how does it render our screens — and what if it can't reach a state?
It rides the preview build or Storybook you already run — no per-framework renderer to install. When it reaches the same state on both base and head, it shows them before and after, stacked. When it can't reach a state reliably, it shows that as LGTY's own gap — visually distinct, never dressed up as a visual regression. A screen that's new at head with nothing to compare against is labeled exactly that.
Which languages and stacks are supported?
Change Analysis's call-graph receipts run on Go and TypeScript/JavaScript today, with more languages landing over time. Every other repository still gets a brief from day one — behavioral delta, without caller receipts for languages the call-graph doesn't cover yet. Production Impact and Visual Review ride your existing infrastructure, so their reach tracks the tools you already run.
Grounded in production reality
An LLM over a diff — and a reviewer’s own coding agent — can only see the repository. LGTY joins the change to what production actually does: the live consumers, the real traffic, the schema. An agent can’t fake a production fact.
Every item carries a receipt you can check in seconds. Model judgment is marked as judgment. Where LGTY can’t see, it says so — it declares its own coverage, and never lets absence read as an all-clear. It attaches evidence and residual unknowns; the judgment call is yours to make.