Shift-left dependency analysis: catching breaking changes in review, not production

When platform engineers talk about shift-left, they almost always mean testing: unit tests that run locally, integration tests that run in CI, contract tests that run before staging. Dependency impact analysis belongs in the same conversation — but rarely makes it there, because most CI pipelines were built before multi-repo contract analysis was tractable.

The cost argument, made precisely

Shift-left is a cost argument at its core. The later in the development cycle you detect a defect, the more expensive it is to fix. A bug caught by a unit test in local development costs minutes: fix the code, re-run the test, move on. The same bug caught by a production alert costs hours of incident response, carries potential customer impact, requires a hotfix deploy or rollback decision, and generates a postmortem that occupies a calendar slot for multiple squads.

The 1×/10×/100× cost multiplier across detection stages is a rough rule of thumb from the testing literature, but the direction is empirically reliable. For cross-service breaking changes specifically, the cost curve is steeper — the fix isn't local and doesn't belong to one engineer. A field rename caught during PR review takes one conversation and one commit. The same field rename caught in production requires: incident response across multiple on-call rotations, root cause analysis that spans team boundaries, coordination between the producing and consuming squads, a hotfix or migration strategy decision, a canary or staged rollout of the fix, and a postmortem. The ratio between "caught in review" and "caught in production" for a cross-service breaking change is realistically 40–80:1 in engineering hours, depending on team coordination overhead.

This is the argument for shift-left dependency analysis: not "it would be nice to know earlier" but "the cost differential between pre-merge detection and production detection makes pre-merge analysis economically required."

The gap in current shift-left tooling

Standard CI shift-left tooling handles these detection points adequately:

• Syntax errors: Linters catch these in under a second, locally or in the first CI stage.
• Type errors: Compilers and type checkers at build time.
• Unit test failures: Caught locally or in the first CI gate.
• Integration test failures: Caught in CI against a shared test environment.
• Schema format violations: OpenAPI validators, Buf lint, proto lint — caught in CI.

The gap: consumer impact analysis. "Does this schema change break any of my downstream consumers in other repos?" is not answered by any of these tools. A schema change can be syntactically valid, type-safe, lint-passing, and integration-tested in isolation while still being a hard breaking change for a consumer service that lives in a different repository and was never part of the test suite.

The only way to catch this without dedicated dependency analysis is a human reviewer who carries the consumer landscape in memory — exactly the kind of contextual knowledge that doesn't scale past 20 services and is unavailable at 2am.

The right detection point in the pipeline

The optimal placement for consumer impact analysis is before merge — specifically in the PR CI check, not pre-push and not post-merge.

Pre-push (developer local) is theoretically the earliest detection point, but impractical for dependency analysis. A meaningful consumer impact analysis requires an up-to-date graph of all declared consumer relationships across all repos — not just the current repo. That graph can't run locally without a live connection to a central analysis service, and running a remote analysis call as a pre-commit hook creates friction that engineers will disable immediately.

Pre-merge (PR CI check) is the right balance: the engineer is still in context and can modify the change, no code has shipped, the CI pipeline has connectivity to the dependency graph service, and the impact report surfaces in the PR comment thread where the engineer and reviewers are already making the ship/don't-ship decision. The cost of addressing a breaking change is still low — a conversation and a commit.

Post-merge / pre-deploy (staging gate) is valuable as a secondary defense but not a substitute. By the time a change has merged, the PR is closed, the engineer is likely on the next task, and the fix requires a new PR branch. The cost has already shifted right.

Three properties of an impact check that gets used

A dependency check that fires on every PR regardless of whether the PR touches a schema file generates noise and gets ignored within a sprint. Effective pre-merge dependency analysis has three operational properties:

Schema-scoped triggering. The check fires only when the diff touches OpenAPI specs, proto files, AsyncAPI documents, or internal SDK declaration files. PRs that modify application logic, tests, or infrastructure don't trigger it. This is a prerequisite for a reasonable signal-to-noise ratio. Checking dependency impact on every commit is the check-that-cried-wolf path.

Consumer-specific, clause-specific output. An impact report that says "this change affects 8 consumers" is marginally better than nothing and much worse than useful. The engineer needs to know: which specific consumer services, what specifically breaks for each one (which field, which endpoint, which event topic), the SLA tier of each affected consumer, and the owning squad's Slack channel. That level of specificity is what converts an impact report from a warning into an actionable coordination artifact. Without it, the engineer reads the number and merges anyway.

Severity-proportional gating. Zero-impact and low-severity warning changes should be advisory — they surface in the PR comment but don't block merge. Only high-severity breaking changes should trigger a CI failure. This is the difference between a useful signal and a bureaucratic gate. The risk scoring model (change type severity × consumer count × SLA tier × deprecation status) described in the risk scoring post is the mechanism for making this determination consistently rather than by engineer judgment.

What changes in engineering behavior after a few months

When a pre-merge dependency check is consistently in place and consistently producing accurate, specific impact reports, the behavioral change is observable within two to three sprint cycles.

Engineers stop treating "what will this break?" as a rhetorical question. It's answerable in 30 seconds by opening the impact report in the PR. PR reviews stop reconstructing dependency context from tribal knowledge, because it's already there. Postmortems for cascade incidents that the check missed start including "consumer X was not surfaced in the dependency analysis — their schema declaration was not current" as a concrete action item, which drives graph completeness improvements instead of the usual "improve cross-team communication" placeholder.

The dependency check doesn't eliminate cross-service coordination — it focuses it. Coordination happens before the change ships, with specific information about which teams need to be in the conversation and what specifically they need to know. That's a different quality of coordination than "I think this might affect someone, should I ask around?"

On waiting for perfect schema coverage before starting

The most reliable way to delay deploying dependency analysis indefinitely is to treat complete schema coverage as a prerequisite. Complete OpenAPI specs, fully annotated proto files, AsyncAPI documents for every event topic — that state is always one sprint away, and it never arrives.

Partial coverage is immediately valuable. A dependency graph covering 65% of services catches 65% of the breaking changes that would otherwise reach production. The uncovered 35% is not a failure state — it's a prioritized backlog, and each item has a concrete framing: "this service's consumers are invisible in the dependency graph; any contract change it ships is an undeclared blast radius." That framing creates urgency for schema documentation work that "we should have better API docs" has never been able to generate.

Start with the services that have schemas. Add the check to their CI pipelines. Let the uncovered gap drive schema investment organically. The covered portion immediately begins paying back in prevented incidents; the uncovered portion shrinks as schema hygiene improves. Waiting for 100% coverage to start getting 65% value is the cost argument working against you.