Count how many files each small change touches. That number, already in your git history, is the one design signal a non-engineer can read without reading code: if a one-sentence change (rename a field, change a price, add a column) touches three or four files, the parts of your app are still separable; if it touches fifteen, everything is wired to everything, and every future change costs more. Lines of code tell you how much was written. Files per change tells you how well.

TL;DR

The measurement, why it works, and what to do with it:

  • Run git log --shortstat on the last ten changes and read the “files changed” number
  • Three or four per small change: parts are separable. Ten or more, routinely: tangled
  • It is the artifact, not the agent: the one number a coding tool cannot grade for itself
  • Research since 1998 ties files that change together to design decay and to defects
  • AI-built code trends the wrong way: duplication up, refactoring down (GitClear, January 2026)
  • High number is a fix pass, not a rebuild: consolidate one feature at a time

The question, and why “lines” cannot answer it

A founder building an agentic app asked his network in public this summer: can an AI-built app be well architected, and how would a non-engineer know? He could inspect tests, modules and latency, but every inspection meant asking an agent to grade its own homework.

The answer is a measurement of the artifact, not a report from the agent. Lines of code fail because AI tools inflate them. GitClear’s Maintainability Gap study, January 2026, across 623 million changes, found duplicated lines per thousand changes rose from 40.3 in 2023 to 73.0 in 2026, moved (refactored) code fell from 21% of changed lines in 2022 to 3.8%, and cross-file function calls dropped 35%. A codebase can triple in size and get worse.

Files touched per change captures what those trends do to you: when logic is duplicated, one business change has to be made in every copy.

The measurement

flowchart LR A["Pick the last 10 small changes"] --> B["git log --shortstat"] B --> C{"Files changed per change"} C -->|"3 to 4"| D["Separable parts: a new hire can work here"] C -->|"5 to 9"| E["Watch it: find which files always travel together"] C -->|"10 or more, routinely"| F["Tangled: duplicated logic or one file owns everything"] F --> G["Fix pass: consolidate one feature at a time"]

If the app is on Lovable, Replit or Bolt, connect or export the project to GitHub first; the history is then a terminal command away. Four numbers are worth reading, and none requires understanding the code.

1

Files per change

git log --shortstat -20 prints one “N files changed” line per commit. Read the N for changes that were small in business terms. This is the headline number.
2

The file in every commit

git log --name-only --pretty=format: | sort | uniq -c | sort -rn | head lists the most-changed files. One file at the top of every commit is the God File from the five patterns.
3

Files that travel together

Two files that appear in the same commits 70% of the time have a dependency nobody drew. CodeScene calls this temporal coupling and reports it as a percentage.
4

Lines per change

Google’s guide calls 100 lines a reasonable change and 1,000 usually too large. GitGuardian found Claude Code commits are often twice the size of human-only ones, which is where secrets slip in.

Why this number has held up since 1998

John Ousterhout named the symptom in A Philosophy of Software Design: change amplification, when “a seemingly simple change requires code modifications in many different places”.

The research is older than the book. Gall, Hajek and Jazayeri showed in 1998 that release history alone, across 20 releases of a telecom switching system, reveals logical coupling between modules that the source code does not declare, and that this coupling points to structural shortcomings. D’Ambros, Lanza and Robbes followed in 2009 by testing, on three large systems, whether change coupling correlates with defects and whether it improves bug prediction models.

CodeScene turned it into a product: it flags file pairs by the percentage of commits in which they change together, requires at least 10 commits before trusting the trend, and ignores any commit touching more than 50 files so a one-time reorganization does not count. That last rule is also your caveat: one big cleanup commit is fine; ten routine commits that each touch fifteen files are the signal.

What the number looks like in an AI-built app

Change the price of the Pro plan
14 files changed: the price is a literal in the pricing page, the checkout, the email template, two Edge Functions, the admin table, the marketing banner, and seven tests that each hardcode $49. Miss one and customers see two prices.
Same change, separable parts
2 files changed: one config entry and one test. Every screen and function reads the price from the same place. A new hire ships this on day one without asking anyone.

The first version is what an AI tool produces when each feature was requested in a separate session: it re-creates what it needs rather than reusing what exists, the copy-paste-over-refactor shift GitClear measured.

What you see in gitWhat it usually meansWhat to ask
Small changes touch 10+ filesthe same logic lives in several copies“Which single file should own this?”
One file in almost every commitone file runs everything“What does this file not do?”
Two files always change togetheran undeclared dependency“Why does A need to know about B?”
Commits of 1,000+ lines for small featuresgenerated in bulk, never reviewed“What in here is not needed for this feature?”
A change touches only tests, then only codethe tests describe the app’s promisesgood sign, keep it

The number does not tell you what to fix. It tells you where to look, and whether it is getting better. Run it again after each fix pass; it should fall.

When this number decides something

The five trigger moments each ask this question in their own words. An investor’s engineer in technical due diligence checks maintainability by exactly this signal. A first hire experiences it directly: a fifteen-file change on day three is why they leave in month two. An enterprise buyer’s security review asks how a fix would be rolled out without touching payment code. After an incident, the fix that touched twelve files is the fix that introduced the second incident. Under load, the file in every commit is the one that cannot be scaled independently.

The one thing to do today
Open a terminal in the repo (or in the GitHub codespace) and run git log --shortstat -10. Write down the ten “files changed” numbers next to a one-line description of what each change was for. If most small changes sit at three or four, keep building. If they sit at ten or more, that list is the first page of your fix plan, and the cost of the pass is now easier to estimate.

What to do with a high number

Nothing drastic. The fix is consolidation, one feature at a time: pick the change that touched the most files, ask which single file should own the logic, move it there, and delete the copies. This is a two to three week fix pass on most AI-built apps, and the trail it leaves, one place per fact and a test that proves it, is what your first hire inherits.

If you would like a senior architect to read your last ten changes and say where the tangle is, that is what the free teardown does: three findings and a verdict, recorded, within 72 hours.

Sources