TITAN
Repository Intelligence for Change-Impact Analysis
A change in one file can affect other files, but the relevant dependencies and historical co-change relationships are not always obvious. TITAN asks: can structural relationships in a codebase and historical file co-change patterns provide complementary signals for predicting change impact?
- Role
- Solo — research design, static analysis, Git history mining, ranking models, evaluation.
- Timeline
- Software Engineering Research · Program Analysis · Repository Intelligence
- Source
- GitHub ↗
What was hard.
Overview — why change-impact analysis matters
When a developer edits a file, reviewers and test suites need to know what else might break. TITAN ranks the files most likely to be affected so testing and review effort can be focused. It is a repository-intelligence research project — not an LLM agent, bug fixer, or code generator.
Two signal families that see different things
Static dependencies capture what the code says is connected; co-change history captures what developers have actually changed together. Neither alone sees the whole picture — the research question is whether they are complementary.
Evaluating without leaking the future
Mining history makes it easy to accidentally train on commits that happen after the one being predicted. TITAN uses an 80/20 chronological split so predictions are only made from past history.
How it fits together.
Change → structural + historical signals → hybrid ranking → ranked impact list
- ▸Static analysis builds dependency relationships from source-code structure.
- ▸Co-change analysis mines Git history to learn which files tend to change together across commits.
- ▸Evaluated across 11 open-source Python, JavaScript, and TypeScript repositories.
What shipped.
- —Evaluation design shapes the conclusion — a chronological split is the difference between prediction and hindsight.
- —Candidate generation is part of the model. Comparing rankers over different candidate sets is not an apples-to-apples comparison.
- —History is a strong baseline. A structural signal has to beat co-change, not a strawman.
What the evidence supports.
Higher is better. Hybrid Model G uses an expanded union candidate set — see limitations.
Experimental setup
- ▸11 open-source repositories across Python, JavaScript, and TypeScript.
- ▸1,493 query instances drawn from 417 test commits.
- ▸80/20 chronological split — models only see history that precedes each test commit.
- ▸Metric: Mean Reciprocal Rank (MRR) — rewards placing a truly affected file closer to the top of the ranked list.
Interpretation & limitations
Hybrid Model G reports a higher MRR than both baselines. However, Model G uses an expanded union candidate set, so it is scoring a different pool of candidate files than the baselines. The observed improvement therefore cannot be attributed solely to adding static structural information — part of it may come from the larger candidate set. No statistical significance testing, production deployment, or causal claim is made here.