Test Impact Analysis
Test impact analysis maps which tests actually exercise which parts of the codebase, via code coverage data or static and dynamic dependency analysis, so a given code change only needs to trigger the tests that cover the changed code instead of the entire suite.
Full-suite-on-every-commit doesn't scale once a codebase and its test suite both grow — most of a large suite is irrelevant to any single small change, but without a mapping there's no safe way to know which subset is irrelevant. Test impact analysis builds that mapping, usually from per-test code coverage collected during a baseline run, and updates it as the codebase changes.
AI enters when the mapping goes beyond direct coverage — statically knowing test A executes file B doesn't catch indirect impact, like a shared config, a downstream service, or a database schema a test doesn't directly touch but depends on — so models trained on historical "this change broke that seemingly-unrelated test" data can catch impact that pure coverage-based mapping misses.
It's most valuable in monorepos and large codebases with slow test suites; the risk is under-selecting on a change that has wider blast radius than the mapping predicted, which is why most teams pair it with a scheduled full-suite run rather than relying on impact analysis alone for every gate.
