Change Impact

checkAdminOrOwner is a small permission check. Give it a role and it tells you whether that role is an owner or an administrator. Open its definition and there is very little to read.

Changing it is another matter.

In the cal.diy revision I used for this experiment, that check appears in shared application code, React components and API services. A signature change starts in one file, then follows imports into packages you would never discover by reading the definition alone.

This is the question I want answered before Claude starts editing: which parts of the application depend on this function, and which of those relationships have we actually checked?

I build Pharaoh, which gives AI agents a structural map of a repository over MCP. I used it alongside native code search for this investigation. Both workflows could find the relevant names; the interesting difference in these runs was the work needed to assemble the answer.

Start with a change, not an overview

The example comes from Pharaoh-so/cal.diy at 54343aa6. The function definition accepts a membership role and acts as a TypeScript type guard.

A general request to explain this repository would leave Claude with an enormous amount

The checkAdminOrOwner function takes a membership role and narrows it to an owner or administrator. In cal.diy at revision 54343aa6, its definition occupies three lines, yet its callers reach API services, web components, shared packages, and tRPC handlers. The definition gives you very little warning about the work a signature change might require.

Code impact analysis starts with a proposed change, follows its direct and indirect dependents, identifies the contracts they rely on, and uses that evidence to plan the edit and its verification. I want that investigation attached to the patch. A caller list gives me places to inspect; it doesn't prove those places will break.

Start with one function and follow a path

I build Pharaoh, a hosted MCP server that gives an AI assistant a structural graph of a repository. It supports TypeScript and Python, exposes production callers through get_blast_radius, and lets you query a function, file, or module. Its change-impact documentation describes that workflow.

On the same revision, get_blast_radius at its default depth of three lists 14 callers across four modules and two endpoints: the conferencing endpoint and the event-types app endpoint.

Here is the get_unused_code reachability result for

Imagine adding a field to an auth API response. The server still returns valid JSON, the browser ignores the extra property, your tests pass, and an older mobile app rejects the response because its decoder doesn't recognize the field. This is a hypothetical change, but the compatibility problem is real.

kotlinx.serialization's JSON decoder throws a SerializationException for unknown properties by default. kotlinx.serialization accepts an explicit setting, such as ignoreUnknownKeys = true, to ignore them, so for the hypothetical mobile app above, I'd test an old decoder against the new response.

I want an AI assistant to show me the consumers before it starts editing, including the ones outside the checkout, because fixing the server and fixing every installed mobile build are different jobs, with different release schedules.

What code change blast radius includes

Code change blast radius is the set of consumers and workflows a change could affect. It's a planning boundary, not a prediction that everything on the list will fail, and I use it to decide where to inspect callers, which tests to run, and whether the change needs a migration.

Start at the changed symbol. Follow the callers back toward the application entry points, across module