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.

GitHubSnowflakeOpenLineagedbtAirflowRuns on the pull request, whoever or whatever wrote it.
callistoReviewerlabelled 4 pull requests 12 minutes agoacme-data/pipelines · Pull requestsIllustrative sample

4 open

Sorted by blast radius

Pull request
Author (agent or human)
Downstream impact
#611 · Rename customer key in stg_orders
claude-code12 min ago
1 break · 3 hops
#609 · Add refund_amount to core.orders
cursor-agent40 min ago
2 downstream · additive
#604 · Backfill churn_features
priya.kyesterday
1 downstream
#608 · Refactor daily_rollup DAG
copilot2 h ago
No downstream change

Four PRs, one that needs your senior reviewer today.

Each hop is one more table or job downstream of the change.

Open #611

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.

Faros AI, AI Productivity Paradox, 2025

66%

of developers name AI output that is “almost right, but not quite” as their top frustration

Stack Overflow Developer Survey, 2025

+31%

more pull requests merged without any review, human or agentic, at high AI adoption

Faros AI, AI Engineering Report, 2026

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.

Review queue · Sprint 4214 open · 11 from agents

#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

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.

models/staging/stg_orders.sqlPR #611 · claude-code
14select
15order_id,
16−customer_id,
16+customer_id as cust_id,
17order_ts,
18amount
19from raw.shop_orders
Compilesdbt tests passLooks right
callistobotcommented before merge

1 breaking, 2 affected

customer_id is renamed. These readers still select it.

Hop
Reader
Status
1
core.ordersparsed from SQL
affected
2
airflow · daily_rollupparsed from SQL
affected
3
Tableau · revenue_dailyextract field customer_id no longer exists
breaks

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.

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.

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.

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.

Question
Warehouse-native lineage
Data catalogs
Data observability
Callisto
When does it look?

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

How far does it see?

Inside one platform

As far as its connectors
are curated

The tables it monitors

Across Snowflake, dbt,
Airflow, BI and notebooks

At what grain?

Table, sometimes column

Usually table

Table and metric

Column, parsed from SQL

Who gets told?

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.

Evaluating for*

Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.

  1. 0–10 min

    Connect

    GitHubSnowflakeAirflow
  2. 10–20 min

    One open PR an agent wrote

    Pull request #[your agent’s PR]
  3. 20–30 min

    Read the comment together

    Blast radius for [your column]