Could this pull request break something before merge?
Reviewing the Blast Radius Before Merge
VallySeed built an AI engineering reviewer that evaluated proposed changes against the current codebase, cross-service dependencies, and production history. Before merge, it surfaced known failure patterns, unresolved assumptions, and the likely blast radius for an engineer to review.
Client
Anonymous software and technology organization
Trigger
Pull request opened
Primary users
Developers and reviewers
Output
Evidence, questions, and merge decisions
The PR looked safe locally. Production was bigger than the PR.
Traditional review could tell the team whether a change compiled, passed tests, followed style rules, or looked suspicious in isolation.
It could not reliably explain whether another service, repository, shared cache, database, queue, or historical failure made that locally reasonable change dangerous in the wider system.
A pull request opened the system-level review.
Once a pull request opened, the reviewer analyzed the diff, the code and service relationships around it, downstream dependencies, and known production failure patterns.
The review went beyond local correctness. It examined what the change could affect and what the company had already learned about that risk.
The review followed the change beyond the diff.
Three review lenses separated the proposed change, its wider effects, and the production evidence relevant to its risk.
Understand the change
The reviewer established what behavior the pull request proposed to change.
- Modified code paths
- Functions and symbols
- Schema or configuration changes
- Behavior changes
Trace the blast radius
The review followed the proposed behavior beyond the local repository.
- Upstream callers and downstream services
- Cross-repository dependencies
- Shared data stores, queues, caches, and background work
- Service contracts and operational assumptions
Compare risk against organizational memory
Production history supplied evidence about risks the company had already encountered.
- Prior incidents
- Known failure mechanisms
- Architecture constraints
- Earlier fixes and review decisions
Known failure modes could become merge guardrails.
When a proposed change recreated a documented failure mechanism, the reviewer could flag the risk or, where policy allowed, prevent merge until an engineer addressed or explicitly resolved it.
Evidence shown to the engineer
- The related historical failure
- The affected dependency or operational constraint
- Why the proposed behavior matched the risk pattern
- What needed clarification or revision before merge
When the system didn't know, it asked.
If the knowledge layer could not resolve an architectural assumption with sufficient confidence, the reviewer asked a targeted question in the pull request instead of inventing certainty.
The engineer's answer resolved the immediate review and could become reusable context for later changes. The design favored questions rather than guesses when the available evidence was incomplete.
Merged and closed pull requests informed the next review.
When a pull request merged or closed, the system incorporated relevant context about changed files, review questions, engineer responses, final implementation decisions, and merge outcomes.
That feedback kept the reviewer aligned with the current codebase as architecture and service relationships changed. Development decisions became context for later reviews instead of disappearing when the pull request closed.
The reviewer informed merge decisions without taking merge authority.
Bounded access
Least-privilege access and repository-level authorization limited which proprietary engineering data the system could inspect.
Traceable findings
Review comments included evidence and provenance rather than unsupported risk labels.
Human authority
Engineers retained override and approval authority. There was no autonomous merge or production deployment.
Explicit uncertainty
Insufficient evidence triggered a question or escalation instead of a confident but unsupported conclusion.
Production context became part of the merge decision.
- Reviewers could see cross-service and cross-repository context before merge.
- Documented failure patterns could be surfaced during development.
- Risk findings stayed connected to supporting evidence.
- Ambiguous architectural assumptions could be resolved in the pull request.
- Policy could turn known risk patterns into merge guardrails.
- Engineer answers and final decisions became context for later reviews.
- Review depended less on one engineer remembering a past production failure.
Public behavior, private implementation.
Publication is limited to the approved anonymized architecture, workflow, and qualitative outcomes. The client name, logo, source code, repository structure, production topology, incident details, internal review comments, and proprietary engineering data remain private. No quantitative engineering-performance or financial claims are made. Any future pull-request examples or screenshots must use synthetic code and fictional service names.
Published September 5, 2026
What happens when production still fails?
See how the same organizational memory can accelerate diagnosis and prepare a safe remediation path after an incident begins.