Data pipeline review for AI coding agents
Callisto checks every pull request against your lineage, what reads from what, and posts what the change would break before anyone approves it.
4 open
Sorted by blast radius
Four PRs, one that needs your senior reviewer today.
Each hop is one more table or job downstream of the change.
01 · The problem
Why AI coding agents
strain data pipeline review
Agents now write transforms, models and DAGs faster than anyone can review them. They see the code in front of them, not what reads from it.
Output up, review up with it
98% more pull requests merged on teams with high AI adoption, and 91% longer PR review time on those same teams.
66%
of developers name AI output that is “almost right, but not quite” as their top frustration
+31%
more pull requests merged without any review, human or agentic, at high AI adoption
02 · Who it’s for
Who feels the gap first
Two people read the same agent PR and ask different questions. Callisto answers both on the pull request.
Engineering manager
“Which of today’s PRs
need my senior reviewer?”
Keeps them up
Every agent PR still needs someone who knows the estate, and there aren’t more of those people than last year. Review stalls, or PRs merge after a skim.
What they get
Each PR labelled with its downstream impact. Additive changes move; the one that breaks something goes to whoever owns what it breaks.
#611 · Rename customer key in stg_orders
claude-code · breaks revenue_daily
Route to m.rossi
#609 · Add refund_amount to core.orders
cursor-agent · 2 readers, additive
Safe to approve
#608 · Refactor daily_rollup DAG
copilot · no reader changes
No downstream change
Data engineer
“What reads this column?”
Keeps them up
Agents now write transforms, models and DAGs faster than anyone can review them. They see the code in front of them, not what reads from it.
What they get
An MCP server (the standard way agents call outside tools) or CLI the agent calls while it works, so it sees the blast radius before it opens the PR and can choose a non-breaking change.
@callisto what reads this column?
1 breaking, 2 affected
03 · How Callisto closes the gap
The same agent PR, with
the blast radius on it
Same diff. The difference is a comment that names every downstream reader before merge, not after deploy.
This is data lineage at review time: what reads from what. For what those jobs cost to run, see operational vs data lineage.
selectorder_id,customer_id,customer_id as cust_id,order_ts,amountfrom raw.shop_orders1 breaking, 2 affected
customer_id is renamed. These readers still select it.
revenue_daily.sql
select order_date, sum(amount),
customer_idrenamed column
from core.orders
Column-level, parsed from SQL
Edges come from parsing each job’s SQL, down to the column, so a rename is traced to the readers that select that column, not every reader of the table.
Snowflakecore.orders
Tableau extractrevenue_daily
customer_id
Across platforms, not just
the warehouse
The chain follows the column out of Snowflake into Airflow jobs, BI extracts and notebooks, which is where hop three usually is.
daily_rollup
churn_features.ipynb
core.orders
parsed
inferred
Inferred edges say so
Where no emitter supplies column lineage directly, name-matched edges are marked inferred. A reviewer can tell a fact from a guess at a glance.
04 · Where it runs
Catch it as early as possible,
from first draft to deploy
The same lineage analysis at three stages of an AI-written change: while the agent writes it, when it’s reviewed and merged, and after it ships.
agent › before renaming customer_id
$ callisto readers stg_orders.customer_id
core.ordershop 1
airflow · daily_rolluphop 2
tableau · revenue_dailyhop 3 · breaks on rename
Illustrative
01Design time
While the agent writes code
“What reads this column?”
An MCP server (the standard way agents call outside tools) or CLI the agent calls while it works, so it sees the blast radius before it opens the PR and can choose a non-breaking change.
Who it helps most: data engineers who want fewer bad PRs, not just faster rejection.
Checks · 3
dbt buildpassed
dbt testpassed
callisto / blast-radiusRequired
Label: breaks-downstream · merge blocked
02Review & merge
On the pull request
“What does this break, and can it merge?”
When a PR opens, Callisto posts the downstream impact as a comment and adds labels. Those labels can block the merge or gate CI until the owner of an affected reader signs off.
Who it helps most: engineering managers reviewing a queue of agent PRs.
Runtime · revenue_daily2h ago
Run time since Tue+38%
Likely causePR #611 · join on customer_id
Issue #148 openedSuggested fix
Illustrative
03Runtime
After deploy
“What changed before this slowed down?”
Callisto monitors runtime metadata after deploy. When a job slows down or fails, it points to the recent changes most likely responsible, opens an issue and suggests a fix.
Who it helps most: on-call data engineers tracing a regression back to a change.
Read-only on your data. It writes PR comments, labels, suggested changes and issues.
05 · Compared
Why your existing tools
don’t catch this one
Each does its job well. None checks the pull request itself, across platforms, at column level, before merge.
After objects exist in the
warehouse
When someone opens
the catalog
After a job runs and data
looks wrong
On the pull request,
before merge
Inside one platform
As far as its connectors
are curated
The tables it monitors
Across Snowflake, dbt,
Airflow, BI and notebooks
Table, sometimes column
Usually table
Table and metric
Column, parsed from SQL
Whoever checks the
lineage tab
Whoever searches
On-call, after the break
The reviewer, and the
agent, in the PR
Observability tells you something broke. Review-time lineage tells you it’s about to, while the change is still one click from being closed.
Join waitlist
See the blast radius of your
agents’ next pull request.
Thirty minutes, your estate, one open PR an agent wrote.
Callisto posts a comment and changes nothing else.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.
-
0–10 min
Connect
GitHubSnowflakeAirflow -
10–20 min
One open PR an agent wrote
Pull request #[your agent’s PR] -
20–30 min
Read the comment together
Blast radius for [your column]