AI Agents Start 40% of Pull Requests. Who Knows What Data They Break?
Coding agents now change your pipelines faster than anyone maps them.
Most organizations treat AI coding agents as a developer productivity story. Faster drafts, fewer boilerplate tickets, shorter review queues.
The larger problem is what those changes touch. On October 28, GitHub's Octoverse report found that developers now start more than 40% of pull requests with an agent, up from 17% in March. In a data team, a pull request is rarely just code. It renames a column, changes a join or retires a table that something downstream still reads.
That leaves data teams with recurring work nobody scoped: working out, after the merge, which dashboards, models and agents quietly depended on the thing that changed.
And it gets worse as agent output scales. GitHub counted 1.3 billion merged pull requests over the past year, an average of 3.5 million a day. Review capacity does not grow at that rate. Undocumented dependencies do.
As coding agents take on more of the work, agents will also need to find, verify and work with agents beyond their own company walls. That is what we are building at OpenMap: The Agent Network, the connective tissue for the world's AI agents, starting with every person and every local business. We are raising a £5M seed. Meet us at openmap.ai/investors.
Why Does a Clean Code Review Still Break the Revenue Dashboard?
A code review checks whether a change is correct inside the repository. It cannot see the finance dashboard, the churn model or the support agent that reads the table three hops away.
Picture an agent asked to tidy up a customer model. It renames a status column, updates every reference in the repo, and the tests pass. The reviewer approves.
Two days later, a revenue dashboard owned by another team shows blanks, and a retention model starts treating every customer as new.
The change was correct.
The context was missing.
This is not a code quality problem. It is a lineage problem.
The Cost Isn't More Broken Pipelines. It's Slower Root Cause.
When a human engineer makes a change, the reasoning usually lives in their head or a chat thread. Someone can ask them why.
When an agent drafts the pull request, that memory may not exist at all. Your data team is left reverse-engineering intent from a diff, under pressure, while business users wait for their numbers.
Before agents change anything that feeds reporting or AI, someone has to:
Map which tables, columns and jobs feed each critical dashboard and model
Identify every downstream consumer of a dataset, including other AI agents
Name an owner who must hear about it when a critical asset changes
Flag the definitions that cannot change without sign-off
Make all of this visible where the agent and the reviewer already work
None of these tasks are particularly difficult. The problem is that they are usually documented once, by hand, and drift the moment the pace of change goes up.
How to Make Your Pipelines Safe for Coding Agents in 30 Days?
You do not need to redesign your data platform, or slow your engineers down, to let agents work safely in it.
Within the first month, focus on the assets that would hurt most if they broke: board metrics, regulatory reports, customer-facing models and the agents that serve customers.
Start by tracing each of them back to the tables, columns and jobs that feed it, and attach an owner to every critical asset along the way.
Next, expose this context through the same channels your agents and reviewers already use, so the impact check happens before the merge, not after the incident.
DataManagement.AI accelerates this process by automatically discovering metadata, mapping lineage across the modern data stack, identifying downstream dependencies, and creating a centralized knowledge layer that stays continuously updated as your environment evolves. Ownership and policy travel with every entity, so every agent-written change can be checked against what it will actually touch.
Instead of spending months documenting assets manually, your teams can see the blast radius of a change before it ships, and exactly who needs to know.
Agent Velocity Is Actually a Lineage Problem
Coding agents are doing what they were built to do. They write more changes, faster, and most of those changes are fine.
What they cannot do on their own is see what your data feeds, who relies on it and what must not move.
Organizations that scale coding agents successfully do not slow them down. They give them a map of everything a change will touch.
Warm regards,
Shen and Team