How should we determine the impact of an API change?

One thing I've been thinking about lately:

As software gets easier to change, does understanding the impact of a change become the harder problem?

A change that looks small in one repository can affect:

• another service
• an API consumer
• an existing workflow
• a dependency
• a different team
• something that isn't obvious from the code you're currently looking at

And knowing what changed isn't necessarily the same as knowing what could be affected.

I've been experimenting with an open-source project called Kaktoos around this idea.

The workflow I'm exploring is:

Understand → Change → Impact → Verify

Before making a change, the system can provide context about existing services, APIs, workflows, dependencies, ownership, and related work.

After the change, it analyzes what actually changed and what could potentially be affected, then connects that to existing verification workflows.

The interesting part for me is the last step.

Instead of generating another set of tests, can we reuse the verification workflows that already represent how the system is expected to behave?

For example:

POST /orders
    ↓
200 OK
    ↓
GET /orders/123
    ↓
404 Not Found

The API returned success, but the expected outcome didn't actually happen.

That made me wonder:

How do you currently determine what might break when you change something?

Is it mostly:

• developer knowledge?
• code search?
• documentation?
• dependency graphs?
• CI?
• integration tests?
• architecture diagrams?
• something else?

And once you identify the potentially affected parts, how do you decide what actually needs to be verified?

I'm interested in real workflows here, especially the messy ones that aren't captured by tooling.

I'm building Kaktoos in public, but I'm more interested in learning how other teams solve this problem than trying to prescribe a particular solution.