Change One Util. Break 23 Packages. Diff Hides It.
The 11pm Slack Message
Friday, 11:47pm. The Slack message comes in: "portfolio site is white. button is dead."
A teammate had changed the variant prop on a shared Button component three days earlier. The PR diff showed one file. The reviewer approved it. Tests passed. Two downstream apps imported that button without anyone noticing, and the deploy went out clean.
This is the monorepo blast radius problem, and it is the single most expensive blind spot in modern code review.
The Diff Lies About What Changed
Monorepos hide the true scope of a change. A typical monorepo has 50 to 500 internal packages, with shared utilities, design systems, auth helpers, and database clients living in packages/* or libs/*. A change to any of these can ripple through dozens of consumers, but the GitHub diff view only shows the file the contributor touched.
Industry write-ups of large monorepos describe scenarios where a security patch to a core auth library cascades across 23 services, and where AI assistants without architectural awareness produce changes that build locally but break consumers they never read. Gartner has forecast a 2,500% rise in software defects by 2028 for organizations shipping AI-assisted code without governance, with the worst impact in 500K+ line monorepos where most tools can ingest less than 20% of the relevant context.
The reviewer's mental model is the bottleneck. They open a PR, see src/lib/format-date.ts changed, skim the new logic, and approve. They do not run the cross-package import query. They do not check whether the Invoice package, the Reports package, and the EmailScheduler package all consume that helper. The diff is honest about what files changed. It is silent about what depends on those files.
The result is what monorepo veterans call hard coupling: teams discover the coupling in production, not in review. Every "we should have caught this" postmortem in a large monorepo is, at its core, a blast radius problem.
Reviews That Read the Whole Repo, Not Just the Diff
Octopus Review's core design assumption is that the diff is never enough. Before a PR is reviewed, the entire repository is indexed into a Qdrant vector store: every file, every export, every internal import. When a PR opens, the reviewer is not just looking at the patch. It is looking at the patch plus every consumer of every changed symbol.
When you change a function signature in packages/utils/format-date.ts, the review knows that Invoice, Reports, and EmailScheduler import it. It can see the call sites. It can tell you which ones still work with the new signature and which ones quietly start producing wrong output. That is the difference between codebase-aware review and diff-only review: one tells you what you changed, the other tells you what you affected.
This shows up in the inline review output. Instead of a generic "consider adding a test," you get:
🟠 **Major** — Breaking change to shared utility
`packages/utils/src/format-date.ts:14`
This function dropped the `timezone` parameter, but `packages/invoice/src/pdf.ts:42`,
`packages/reports/src/weekly.ts:88`, and `packages/email/src/scheduler.ts:19` still
call it with `formatDate(date, 'UTC')`. Those calls will silently ignore the
timezone argument and produce dates in the server's local time.
💡 **Tip** — Add deprecation shim
Consider keeping the old signature for one release with a console.warn, so
consumers can migrate without a coordinated PR.
That comment is not possible without indexing the whole repo. A diff-only tool cannot produce it because it cannot see the three consumer files. It is not in the patch.
The Workflow Engineers Actually Use
Pairing the indexed repo with the CLI gives you a tight local loop. Before opening a PR for a risky shared change, run:
# Make sure the index is current with main
octopus repo index
# Ask the index what depends on the file you are about to change
octopus repo chat
# Then trigger a full review on the PR once it's up
octopus review 412
The repo chat step is the one most teams miss. You can ask, in natural language, "what packages import formatDate from utils?" and get an actual list grounded in the embeddings. No grep gymnastics, no IDE-specific reference search that misses dynamic imports.
For teams that need this enforced rather than optional, the same index powers the automated PR review. Every pull request gets a codebase-aware pass before a human looks at it. Reviewers spend their time on the architectural call, not on running mental git grep against the whole repo.
And for teams in regulated industries or with private monorepos that cannot ship code to external services, the entire stack runs on your own infrastructure. The index lives on your servers. Source code is processed in-memory only. The embeddings persist, the source does not. You bring your own Claude or OpenAI key, or run the whole thing self-hosted with no external calls at all.
The Reviewer You Actually Need
The next generation of code review is not about producing more comments. It is about producing the comments that diff-only tools fundamentally cannot. Blast radius is the highest-value example: a single 🟠 Major flagging three downstream consumers is worth more than fifty 💡 Tips about variable naming.
If your team is hitting the "we shipped a one-line change and broke production" pattern, the issue is not your reviewers. It is the tooling they are working with. Open source, self-hostable, codebase-aware review is at octopus-review.ai. Star the repo at github.com/octopusreview/octopus, or jump into the Discord if you want to compare notes on monorepo review workflows.