Inside the Data Change Review Agent
Code Review Was Only Ever Half a Review.
The PR looked fine and the data was broken for weeks. Meet the agent that reviews what a change did to the rows - before it can merge.
The PR looked fine. The data was broken.
There's a confession that recurs on r/dataengineering: a dbt model change passed review, got approved, and broke the prod numbers - a join fan-out that quietly doubled revenue for weeks, discovered only when someone noticed downstream. The reviewers weren't careless. They read the SQL, and the SQL looked fine. Code review answers does this compile and read well? - it was never built to answer the only question that decides whether a data change is safe: what did it do to the data?
So teams fall back on either green CI - which only catches what someone wrote a test for - or a manual data-diff so laborious it lands on one senior engineer who becomes the bottleneck, and usually gets skipped. The distribution shift, the filter that drops 10% of rows, the "harmless refactor" that changes outputs: none of them show up in the diff a human reads.
What our Data Change Review Agent actually does
The Data Change Review Agent is the missing half of code review: it runs the proposed change against your live data in both environments and renders a risk verdict before the change can merge.
It maps the blast radius - every downstream table, dashboard, and model a change touches - then diffs the data the way a careful engineer would by hand: a schema diff that grades each column change breaking or harmless, a cheap row-count pass that catches the fan-out instantly, a profile diff on nulls and distributions, and a value-level diff that joins on the primary key to show exactly which rows changed. It's cost-aware about it: it starts with free metadata, spends one cheap query on counts, and only pays for expensive value-level diffs where the evidence says it matters - so thorough review stops being too laborious to actually do. Every change comes back with a clear LOW, MEDIUM, or HIGH verdict. And a dangerous finding doesn't dead-end in a scary comment: it routes the fix to the right teammate - schema migration, incident diagnosis, governance sign-off.
The shape of the win is when you find out. The regression that used to surface in a dashboard days after merge gets caught at the pull request - a grounded verdict on the data impact while the change is still reviewable. It works on your warehouse, with or without dbt.
Here's the reframe: a data change isn't a code diff to approve - it's a data outcome to verify. Reading the SQL was never the same as knowing what it did to the rows. And the review doesn't dead-end: where every other tool stops at showing a human the diff, this one hands the HIGH-risk finding into a fix - the schema agent for the migration, the incident agent for the diagnosis, the governance agent for sign-off.
A few of the agent's capabilities
The Data Change Review Agent ships with a deep toolkit. A sampling of what it can do:
| Capability | What it does |
|---|---|
| Pre-merge data review | Reviews a proposed change end-to-end and returns a LOW/MEDIUM/HIGH verdict before it can merge. |
| Impact / blast-radius diff | Maps every downstream table, dashboard, and model a change touches, so nothing breaks by surprise. |
| Schema diff | Flags added, removed, renamed, and type-changed columns and grades whether each is breaking. |
| Row-count diff | A cheap first pass that catches fan-outs and dropped rows - the doubled-revenue join - instantly. |
| Profile diff | Compares null rates, distinct counts, uniqueness, and min/max/avg per column across both environments. |
| Value-level diff | Joins on the primary key and reports exactly which rows and columns changed, were added, or disappeared. |
| Distribution diff | Top-category and histogram comparisons to see how a column's shape shifted, not just that it did. |
| Cost-aware escalation | Starts free on metadata, spends cheap on counts, and only pays for expensive diffs where evidence warrants. |
| Intent-vs-impact check | Compares what the change claims to do against what the data actually did, and flags the mismatch. |
| Resolution hand-off | Routes HIGH-risk findings to the schema, incident, and governance agents instead of dead-ending in a comment. |
…and these are just a few of many - the agent carries dozens more autonomy skills, with new ones added continuously.
How this is different from data-diff CI
The pre-merge data-review category is real and well-funded, and the incumbents are genuinely good at the half they own.
Recce is the closest pure-play - lineage, schema, row-count, profile, and value diffs with review checklists - but it's architecturally dbt-only and terminates at a human-readable summary. Datafold ships the strongest single mechanism in the space, a cross-database value-level diff used as an objective parity gate, but it's pointed mainly at migration cutover and stops once parity is proven. SQLMesh has the best deterministic foundation - column-level lineage and breaking-vs-non-breaking classification before execution - but it ends at the human plan-and-apply boundary inside one warehouse. dbt Cloud's advanced CI and Great Expectations in CI likewise surface impact or assert expectations, then post a comment or block the build for a human to act on.
The pattern across all of them is the same: they detect the breaking change and print it; a person still writes the fix. Our wedge is warehouse-generic review - not dbt-coupled - whose verdict hands off to remediation.
The takeaway
Code review stayed half a review because it answered "does this read well?" and never "what did this do to the data?" - so the regressions passed inspection and surfaced downstream weeks later. An agent that diffs the rows, distributions, and blast radius before a change can merge, and routes the dangerous ones into a fix, finally closes the other half. A change that looks fine in review and breaks the numbers in production was never actually reviewed.
See it on your next change
Point the agent at a pull request you'd normally approve on a read-through - and watch it diff the data impact, grade the risk, and catch the regression while the change is still a PR. Book a demo to see it on your stack.