# Change impact analysis: know what a change breaks before it merges

https://gitmir.com/change-impact-analysis · updated 2026-10-07

The risky part of a change is rarely the line in the diff. It is the rule in another area, the step of a customer path or the record that depends on it — and nothing in the diff says so.

## In short

Change impact analysis in software is working out, before a change ships, everything it can affect: the code it touches, what depends on that code and — the part teams miss — the business rules, customer paths and records that depend on it without sharing a file or a word with it. GitMir computes it from a model of the product: which areas a change reaches, which steps of which customer paths change, where a person should review and which checks to run — before the merge, and for the coding agent before it writes.

## Four methods, one blind spot

- **Traceability matrices** — Requirements mapped to code by hand. Thorough on the day they are written, out of date soon after.
- **Dependency analysis** — Callers and imports of the changed code. Precise about the code, silent about the business rule that depends on it.
- **Asking the person who knows** — Fast while that person is there. The answer leaves with them.
- **Tests** — They catch what somebody thought to write down. The connection nobody knew about has no test.

## A rule reaches further than an import

One rule from Supabase Studio, published on this site:

- **Rule · Billing & Subscription** — An unpaid invoice restricts the organization. Warning → grace period → restricted Reaches Organization, Project.

A change to the invoice code reaches the organization and its projects through the rule, not through an import. That is the part of impact analysis a call graph cannot give.

## From a sentence to the checks that matter

1. **Describe the change** — In your own words, in New task or Check a change — before anyone estimates it.
2. **See what it reaches** — The areas, the steps of each customer path and the records it changes, including parts with no word in common with the request.
3. **Turn it into checks** — Pick what must keep working; it becomes the task's Done when.
4. **Give the agent the same list** — Over MCP, before it writes the change.
5. **Check the commit** — What the change touched and what it left out, before it lands; after the push, Business Review says what changed in the product.

## Sizing in minutes, review as a look

On the projects GitMir has run, timing the same work both ways: sizing one change went from 16 h to 0.3 h of a product manager's time, and checking what an agent did from 45 min to 8 min. Measurements of those projects, not a promise about yours.

## Impact before the merge, review after it

- **GitMir Intelligence** — Change impact for people, from the model of your product, with the drawing beside it. https://gitmir.com/products/intelligence
- **GitMir Vibe** — The same list for your coding agent before it edits, and a check of each change before it is committed. https://gitmir.com/products/vibe
- **GitMir Business Review** — After the push: which rules, status flows, customer paths and records actually changed. https://gitmir.com/products/review

## Questions

### What is change impact analysis in software engineering?

Working out, before a change ships, everything it can affect — the code, what depends on it, and the business rules, customer paths and records that depend on it without sharing a file with it.

### How is impact analysis different from code review?

Code review reads the diff that was written. Impact analysis says what the change reaches, including what is not in the diff, and is most useful before the change is written.

### Can change impact analysis be automated?

Yes, when there is a current model of what the product does. GitMir computes it from such a model, built from the code and updated on every push.

### Does it work across several repositories?

Yes. A project with several repositories is read as one product, so a change in the backend is answered with what it reaches in the mobile app or another service.

### How does impact analysis help software testing?

It says which customer paths and rules a change reaches, so the tests to run — and the ones that do not exist yet — follow from the change rather than from a full regression.

## Read next

- [Business logic, and why AI keeps rebuilding it](https://gitmir.com/business-logic)
- [Change impact before you write code](https://gitmir.com/blog/change-impact-before-you-write-code)
- [Legacy systems and migrations](https://gitmir.com/use-cases/legacy-migration)
- [Architecture diagram from code](https://gitmir.com/architecture-diagram-from-code)
- [GitMir Business Review](https://gitmir.com/products/review)