Early access · Public GitHub repositories · TypeScript, Python, Java, Go and more

Know what your code changes could affect.

Understand the potential blast radius of a pull request. Trace the parts of your codebase connected to it, review evidence-based risk signals, and see what may need testing before you merge.

  1. Pull request selected
  2. Impact mapped
  3. Report ready
Illustrative example
Pull request

#128Update payment flow

payment-rounding → main

2 files changed

  • payment.ts+42 −17
  • currency.ts+6 −2
Dependency mapSelect a file

An example impact map. The pull request changes payment.ts and currency.ts. 5 other files import them, directly or through another file, and are marked as potentially affected. One file, session.ts, is not reached.

Not reached from this change

Select a file to see why it is on the map.

  • Changed
  • Potentially affected
  • Not reached
  • Is imported by
Impact report
Risk levelMedium

payment.ts is imported directly by 3 files.

Changed
2
Potentially affected
5

Suggested checks

  • Check invoice.ts still behaves correctly with both changes.
  • Run the tests for checkout.ts and refund.ts.
  • Look at receipt.ts if what invoice.ts produces has changed.
An illustration with made-up files, not an analysis of a real repository.

How it works

From pull request to a clearer picture.

Four steps from a pull request to a report you can act on.

  1. 01

    Connect a repository

    Add a public GitHub repository by its URL. Impactlia maps the imports between its source files.

  2. 02

    Select a pull request

    Pick one of its pull requests, or enter any number. The analysis starts from the files it changes.

  3. 03

    Trace potential impact

    From each changed file, the import graph is followed outwards, up to 8 steps, to find the files that may be affected.

  4. 04

    Review what to validate

    Read the signals behind the risk level, the path to each affected file, and the suggested checks.

From diff to blast radius

A changed file is only the beginning.

A pull request shows what was edited. It does not show which other parts of the codebase rely on that code. Impactlia follows the imports to find them.

  • Changed is not the same as affected.

    The files a pull request edits are marked as changed. Files that import them are potentially affected: worth a look, not evidence of a bug.

  • Every connection has a path.

    A file is on the list only with the chain of imports that reaches it, so you can see why it is there.

Code review asks
“What might be wrong with this code?”
Impactlia asks
“What could this change affect?”
Changed in this pull requestIllustrative example

5 files import payment.ts

Imports it directly

Imports it through another file

Evidence

src/checkout/checkout.ts

Potentially affected

  1. checkout.ts
  2. importspayment.ts

Each link is an import found in the source. It is a reason to look at checkout.ts, not a sign that it is broken.

Explainable risk

See why an area deserves a closer look.

A risk level on its own tells you nothing. Each one in Impactlia comes with the signals that produced it, the rule each signal follows, and what the analysis could not check.

PR #128Update payment flow2 files changed, 5 potentially affectedIllustrative example
Changed
A file this pull request edited.
Potentially affected
A file that uses a changed file, directly or through another file.

One file “uses” another when it imports code from it.

Changed files (2)

  • src/payments/payment.ts
  • src/payments/currency.ts

Potentially affected files (5)

Select a file to see how the change reaches it.

Why receipt.ts is on the list

  1. payment.tscurrency.tschanged in this pull request
  2. is used byinvoice.ts
  3. is used byreceipt.tsthe file you selected

receipt.ts uses invoice.ts, and invoice.ts uses payment.ts and currency.ts. So a change there could reach receipt.ts.

That is a reason to check it, not a sign that it is broken.

Coverage and limitations

1 connection could not be followed.

src/plugins/loader.ts decides which file to load while the app is running, so the files it loads are missing from this report.

Risk signalsMedium

  • A changed file is imported directly by many filesMedium

    payment.ts is imported directly by 3 files.

  • The change reaches files through chains of importsLow

    5 files import a changed file, directly or through another file.

  • Part of the change or of the graph could not be analysedLow

    One import elsewhere in the repository could not be resolved.

The level is the highest one among the signals that were triggered. It decides what to look at first. It is not a prediction that anything breaks.

Suggested checks

  1. Check invoice.ts still behaves correctly with both changes.It imports both changed files.
  2. Run the tests for checkout.ts and refund.ts.Both import payment.ts directly.
  3. Look at receipt.ts if what invoice.ts produces has changed.It is reached through invoice.ts.

A drawing of the report for the same made-up pull request. The signal names and thresholds are the product’s real ones.

Suggested checksIllustrative example
  1. 1

    Check invoice.ts still behaves correctly with both changes.

    Because: It imports both changed files.

  2. 2

    Run the tests for checkout.ts and refund.ts.

    Because: Both import payment.ts directly.

  3. 3

    Look at receipt.ts if what invoice.ts produces has changed.

    Because: It is reached through invoice.ts.

A starting point for review. Not a test result, and not a guarantee.

From findings to validation

Know where to focus your review.

Impact findings help you decide what to open, read and test before you merge. They guide your judgement; they do not replace it.

  • Each check names its reason.

    A suggested check points at a file and the computed fact behind it, such as which changed files it imports.

  • Facts first, AI second.

    Files, imports, signals and checks come from analysis, not from a model. In the repository explorer you can ask an AI model to explain a file or folder. Its answer is labelled as interpretation, and it cannot add or change dependencies.

Walkthrough

One pull request, start to finish.

Step through one analysis. Each stage shows where its information comes from.

Stage 1 of 5

Pull request

Reported by GitHub

It starts with a pull request on a public GitHub repository: its number, title, author, and the two commits it sits between.

Pull request
#128 Update payment flow
Into
main
From
payment-rounding
Files changed
2

Illustrative example. The same made-up pull request as the rest of this page.

Trust

Built to read only what it needs.

Repository access is sensitive, so this is exactly what Impactlia reads and keeps today.

  • Public repositories only

    Impactlia reads public GitHub repositories through GitHub’s public API, without a token. It does not ask you to sign in with GitHub or grant repository permissions, and it cannot see private repositories.

  • Source is read, then deleted

    To build the dependency map, the repository is downloaded into a temporary folder: the whole commit, or for a large repository only the files that changed since its last analysis. Only source files and the project files that describe them are written out, nothing in the repository is run, and the folder is deleted when the run ends.

  • What is kept

    The dependency map, meaning file paths and which file imports which, and pull request details such as its title, author and changed file paths. Impactlia’s database does not store your files’ contents or the text of the diff.

  • Your organization only

    Every repository and analysis belongs to one organization. Database access policies, not only application code, decide who can read it.

One exception: when you ask for an AI explanation of a file, that file’s source and its listed dependencies are sent to an AI model provider to write the answer, and the request is recorded in a trace. Nothing is sent unless you ask.

Languages

What Impactlia reads, language by language.

Every relationship comes from reading the code itself. Each row shows exactly what Impactlia does for that language today.

What Impactlia does with files in each supported language
LanguageImports mappedRelated tests foundTest scenarios suggestedChanged code type-checked
TypeScript .ts .tsx .mtsIncluding Next.js, NestJS, Express and React roles and routesYesYesYesYes
JavaScript .js .jsx .mjsIncluding CommonJSYesYesYesYes
Python .py .pyipytest tests and commandsYesYesYesNo
Java .javaYesYesNoNo
Go .goYesYesNoNo
C# .csYesYesNoNo
C .c .hThrough #includeYesYesNoNo
C++ .cc .cpp .cxxThrough #includeYesYesNoNo
Rust .rsYesYesNoNo
PHP .phpYesYesNoNo

Ruby, Kotlin, Swift, Dart and SQL files are recognised but not read yet: when a pull request changes one, the report names it and says nothing is known about what depends on it. Several languages in one repository are mapped together, without linking files across languages unless one names the other.

Early access

Early access. Real feedback matters.

We’re building Impactlia to make change-impact analysis useful in everyday engineering work. Try it on a public repository and tell us what helps, what is confusing, and what you would want next.

Try Impactlia

FAQ

Questions

Is Impactlia another AI code reviewer?

No. It does not judge whether code is correct. It shows what a change could affect across the codebase, so review and testing go where they are needed. It complements code review rather than duplicating it.

How does Impactlia work out what a change could affect?

It parses the repository’s imports into a dependency graph, then follows that graph outwards from the files the pull request changes. The result is only as complete as the imports it can resolve, and the report says which ones it could not.

Does Impactlia guarantee a change will not break production?

No. It helps you understand potential impact and choose what to review or test. It cannot prove that a change is safe.

Which languages and repositories does it support?

TypeScript and JavaScript, including CommonJS, with extra understanding of Next.js, React, Express and NestJS files, and type-checking of changed code. Python, with related pytest tests and suggested test scenarios. Java, Go, C#, C, C++, Rust and PHP, with their dependencies and related tests found from imports and names. Ruby, Kotlin, Swift, Dart and SQL files are recognised but not yet read. Only public GitHub repositories for now; private repositories are not supported yet.

Can I use it today?

Yes, in early access. Create an account, add a public GitHub repository by its URL, and analyse its pull requests.

See what your next pull request could reach.

Trace the change, read the evidence, and decide what to check before you merge.