01
"LGTM"
Reviewers approve PRs they didn't fully understand because nobody has 90 minutes to trace a 100-file diff. Bugs ship in the gap between "looks right" and "is right".
GitHub Action · MIT · v1
The PR review that explains what actually changed.
Andy reads every pull request and posts one comment: an architecture map, a money / time impact card, ranked code suggestions, a risk quadrant — and a 60-second audio summary you can play. Drops in via one YAML file. No service to authorize.
Built onGitHub ActionsMIT licensedZero PII out
8.4
PR health
4-axis weighted
4-axis weighted
5 features3 risks12 tests
💰 Money
+32%
👥 Customer
+48%
⚙ Runtime
+60%
🎨 UX
+25%
9 findings · 3 above suggestion thresholdOpen full review →
Andy at a glance
30s
Typical review time
per pull request
6
Artifacts per comment
arch, value, risk, …
$0
Service cost
runs in your runner
1
YAML file to install
no token, no key
Three questions every PR comment fails to answer.
02
Why does this exist?
Context lives in Linear, Slack threads, and the author's head — not in the PR. New reviewers spend half their time inferring intent before they can judge the code.
03
What did it cost?
No one can answer in dollars or minutes. The PR closes, the impact disappears into vibes, and the team forgets what they shipped by next quarter.
Six artifacts. One PR comment.
One sticky comment per pull request, re-rendered on every push. Inside it: the visuals that turn a large diff into a guided handoff, plus the code suggestions and risks that actually need a reviewer's eye.
Featured
Architecture map
Before → after diagrams of what your PR changed, plus the data structures connecting the two. Rendered as Mermaid.
Value card
Money, customer, runtime, runtime-UX — each scored with the formula, the inputs that produced it, and a confidence label.
Ranked suggestions
Every code suggestion ships with a confidence score, a category, an applyable diff, and references to specs or docs.
Risk quadrant
Severity × likelihood map of every risk Andy spotted. You see what to block on before merge versus what to monitor.
Hot-touch mindmap
The files reviewers should open first, grouped by subsystem — the difference between a 100-file PR and a 6-file mental model.
Business context
A product-level diagram with the slice your PR touches highlighted — so reviewers see why the change exists, not just what.
And a 60-second audio summary, right in the comment.
Andy now narrates every review. Press play on the comment and hear what changed, why it matters, and where to look first — for the commute, the code walk, or the reviewer who'd rather listen than scroll a hundred-file diff.
One YAML file. Then push.
Andy runs as a GitHub Action on your own runner. Nothing leaves the workflow — no service to authorize, no API key to manage.
.github/workflows/drift.yml
name: Drift
on:
pull_request:
types: [opened, synchronize, reopened]
permissions:
contents: read
pull-requests: write
checks: write
models: read
jobs:
drift:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- uses: refactorlab/drift@main- 1
Add the workflow
Copy the YAML into .github/workflows/drift.yml. No tokens, no profile commands, no extra config.
- 2
Open a PR
Andy auto-detects the latest profiler release, caches it via $RUNNER_TOOL_CACHE, and posts a sticky comment within ~30 seconds.
- 3
Re-run on each push
The comment is overwritten in place (identified by a hidden marker). A "Drift / PR review" check run summarises the verdict.
A peek at the output.
Two artifacts pulled from a real review on a 100-file PR. The full comment also includes the architecture map, risk quadrant, and three more ranked code suggestions.
🎯 PR Value Card▲ improvement
💰 Money
▲ 32%
👥 Customer value
▲ 48%
⚙️ Software runtime
▲ 60%
🎨 Runtime UX
▲ 25%
Net infra + dev-time: −$1,840 / mo · debug-loop: 16 → 12 min median · scan artifact: 9.83 → 3.9 MB.
🅑 Product correctnesscompact.rs0.77 conf
Why it matters: pagerank == 0.0 is a valid value for isolated nodes. Treating 0.0 as "not set" silently ships wrong output the moment another f64 intrinsic copies this pattern.
42fn prefer_frame_f64(frame_v: f64, node_v: f64) -> f64 {
43 if frame_v != 0.0 { frame_v } else { node_v }
42fn prefer_frame_f64(frame_v: Option<f64>, node_v: f64) -> f64 {
43 frame_v.unwrap_or(node_v)
Things people ask before installing.
Does Andy upload my code anywhere?
No. Andy runs entirely inside your GitHub Action runner — public or private. Nothing leaves the workflow.What does it cost?
The Action is free and MIT-licensed. You pay only your usual GitHub Actions runner minutes (Andy typically finishes in ~30 seconds).Does it work on private repos?
Yes. It runs on whatever runner the repo uses — public, private, or self-hosted.Will it slow down my pull requests?
No. Andy runs in parallel with your other checks and posts within ~30 seconds of a push, overwriting its previous comment.How is it different from a Copilot-style review?
Andy ships a fixed bundle of artifacts — architecture map, value card, risk quadrant, ranked suggestions — with confidence-scored, applyable diffs and references. Not free-text vibes.
Still have a question? Talk to us →
Questions, integrations, or a quick demo?
Drop a line or grab a slot — we usually reply within a day and the call is 30 minutes, no slide deck.