Every codebase has files that nobody looks at carefully. They're small, they're imported by one or two things, they look like utilities. In code review they get a quick skim. In AI-assisted review they get deprioritised because the model's attention is elsewhere.
And then one of them is involved in a production incident. It turns out the small file called a function that called a function that touched something critical. The blast radius was never computed because the file looked isolated.
This is the blindspot pattern. Spiderbrain scores it.
How blindspot score is computed
Blindspot score combines two graph properties that move in opposite directions:
Low in-degree: the file is not widely imported. Few nodes point to it. This is why it gets deprioritised, importance heuristics are typically based on in-degree, so this file scores low.
High transitive out-reach: the file's import closure is large. It imports things that import things, and the transitive closure reaches a significant fraction of the codebase.
The combination, few things import it, but it touches many things, is the signature of a blindspot. A change to the file does not appear risky from the call-site count, but its reach through the graph means that what it touches can be far-ranging.
Why this pattern survives code review
Human reviewers use the same in-degree heuristic that AI tools use. "This file isn't imported much, it's not load-bearing." This is a reasonable heuristic that is wrong for blindspot files specifically.
The error is directional confusion: in-degree measures who depends on you; transitive out-reach measures what you can affect. For most files these are correlated. For blindspot files they are not.
A factory function, a configuration loader, or an initialisation module can have low in-degree (called in one or two places at startup) and high out-reach (pulls in half the codebase at import time). These files are particularly common at the boundary between layers, the place where infrastructure code meets business logic.
What changes when you score blindspots
When Spiderbrain surfaces a blindspot file in a PR, the review question changes. Instead of "this file has one importer, how risky can it be?" the reviewer asks "this file's import closure covers 40% of the codebase, what exactly does it touch, and do we have coverage on those paths?"
That reframing is the practical value. The reviewer doesn't need to understand the blindspot score formula. They need to know that the file they were about to skim quickly is actually the one that needs the most attention in this change.
Blindspots in AI-assisted code review
AI coding assistants face the same heuristic trap as human reviewers. Attention in a language model is influenced by how often a concept appears in the context, which correlates with in-degree. A widely-imported utility will appear in many files in the context window; a blindspot file appears in one.
When Spiderbrain serves the blindspot score for a changed file to the reviewing AI, it explicitly breaks this attention bias. The model is told: this file has a higher structural significance than its import count suggests. Attention is directed correctly before the model begins its analysis.
Building a blindspot inventory
A useful exercise: run a blindspot score audit on your codebase and identify the top 10. These are your "priority quiet files", worth labelling, documenting, and adding to your change-gating configuration.
For most codebases, the blindspot inventory reveals a category: infrastructure setup code, dependency injection containers, event emitters, or configuration parsers. These files share the structural signature (called once, reaches far) and deserve a team norm: blindspot files get extra review attention regardless of diff size.
The score makes the norm enforceable. Without it, the norm relies on tribal knowledge about which files are secretly important. With it, the knowledge is computed, stable, and transferable to new team members from day one.