---
title: "Is my AI-built codebase well designed? Count the files each change touches (2026)"
description: "The one design signal a non-engineer can measure: how many files change per small change. Three or four means separable parts; fifteen means tangled. In git."
url: https://systemtrails.com/resources/files-touched-per-change-ai-built-codebase/
markdown: https://systemtrails.com/resources/files-touched-per-change-ai-built-codebase/index.md
type: resources
date: 2026-08-31
lastmod: 2026-08-31
tags: ["architecture","code-quality","ai-mvp","git","first-hires"]
---

# Is my AI-built codebase well designed? Count the files each change touches (2026)

> The one design signal a non-engineer can measure: how many files change per small change. Three or four means separable parts; fifteen means tangled. In git.

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](https://www.gitclear.com/the_ai_code_quality_maintainability_gap), 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

```mermaid
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](/resources/audited-50-ai-codebases/).
### 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](https://docs.enterprise.codescene.io/versions/3.4.0/guides/technical/temporal-coupling.html) 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](https://google.github.io/eng-practices/review/developer/small-cls.html). GitGuardian found Claude Code commits are often [twice the size of human-only ones](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/), 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"](https://en.wikiversity.org/wiki/Software_Design/Change_amplification).

The research is older than the book. Gall, Hajek and Jazayeri showed in [1998](https://www.ifi.uzh.ch/dam/jcr:00000000-2f41-7b40-ffff-fffff06866e1/gall03.pdf) 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](https://www.semanticscholar.org/paper/On-the-Relationship-Between-Change-Coupling-and-D'Ambros-Lanza/937b72f93fe2cb74549b08f1f984c0b9e723e580) 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 git | What it usually means | What to ask |
|---|---|---|
| Small changes touch 10+ files | the same logic lives in several copies | "Which single file should own this?" |
| One file in almost every commit | one file runs everything | "What does this file not do?" |
| Two files always change together | an undeclared dependency | "Why does A need to know about B?" |
| Commits of 1,000+ lines for small features | generated in bulk, never reviewed | "What in here is not needed for this feature?" |
| A change touches only tests, then only code | the tests describe the app's promises | good 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](/resources/technical-due-diligence-ai-built-codebase/) 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](/resources/cost-to-make-ai-built-app-production-ready-2026/) 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](/free-teardown/) does: three findings and a verdict, recorded, within 72 hours.

## Sources

- GitClear, [The Maintainability Gap: 2026 AI Code Quality Research](https://www.gitclear.com/the_ai_code_quality_maintainability_gap), January 2026 (623M changes; duplication 40.3 to 73.0 per thousand changes; moved code 21% to 3.8%; cross-file calls down 35%)
- GitClear, [AI Copilot Code Quality: 2025 research](https://www.gitclear.com/ai_assistant_code_quality_2025_research), January 2025 (211M lines; copy/paste exceeded moved code for the first time in 2024)
- GitGuardian, [The State of Secrets Sprawl 2026](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/), March 2026 (Claude Code commits about 2x the lines of human-only commits)
- John Ousterhout, *A Philosophy of Software Design*, change amplification as summarized on [Wikiversity](https://en.wikiversity.org/wiki/Software_Design/Change_amplification)
- Gall, Hajek, Jazayeri, [Detection of Logical Coupling Based on Product Release History](https://www.ifi.uzh.ch/dam/jcr:00000000-2f41-7b40-ffff-fffff06866e1/gall03.pdf), ICSM 1998
- D'Ambros, Lanza, Robbes, [On the Relationship Between Change Coupling and Software Defects](https://www.semanticscholar.org/paper/On-the-Relationship-Between-Change-Coupling-and-D'Ambros-Lanza/937b72f93fe2cb74549b08f1f984c0b9e723e580), WCRE 2009
- CodeScene docs, [Temporal Coupling](https://docs.enterprise.codescene.io/versions/3.4.0/guides/technical/temporal-coupling.html), version 3.4.0, accessed August 31, 2026
- Google engineering practices, [Small CLs](https://google.github.io/eng-practices/review/developer/small-cls.html), accessed August 31, 2026

## FAQ

**How can a non-engineer tell whether an AI-built codebase is well designed?**

Count how many files each small change touches. Open the project's git history and run git log --shortstat on the last ten changes. If a one-sentence change (rename a field, change a price, add a column) touches three or four files, the parts are still separable. If it touches fifteen, everything is wired to everything. The number is in the commit history already and needs no code reading.

**Why is lines of code a bad measure of design quality?**

Lines tell you how much was written, not how well. An app that grew from a thousand lines to tens of thousands got bigger; whether it got better depends on how the lines are connected. GitClear's January 2026 study of 623 million changes found duplicated lines per thousand changes rose from 40.3 in 2023 to 73.0 in 2026, which inflates line counts while making every change touch more places.

**What is change amplification?**

John Ousterhout's term, from A Philosophy of Software Design, for the first symptom of complexity: a seemingly simple change requires code modifications in many different places. Files touched per change is the cheapest way to measure it from the outside.

**Is there research behind files-that-change-together as a quality signal?**

Yes, since 1998. Gall, Hajek and Jazayeri detected logical coupling from the release history of a telecom switching system across 20 releases. D'Ambros, Lanza and Robbes (2009) related change coupling to defects on three large systems. CodeScene productized it as temporal coupling, reporting the percentage of commits in which two files change together, and ignores commits that touch more than 50 files to avoid false positives.

**What number is bad?**

There is no universal threshold, but Google's engineering guide says a 200-line change in one file may be fine while the same change spread across 50 files is too large, and calls 100 lines a reasonable size for a change. In AI-built apps, a routine change that consistently touches ten or more files usually points to duplicated logic or one file that owns everything.

**What do I do if the number is high?**

Nothing drastic. Ask the AI (or an engineer) which single file the change should have lived in, then have the duplicates consolidated one feature at a time. That is a fix pass, not a rebuild. SystemTrails' free teardown reads your last changes and tells you where the tangle is, within 72 hours.



Free teardown: https://systemtrails.com/free-teardown/ | Contact: https://systemtrails.com/contact/ | Book a call: https://cal.com/dan-podina-snqasy/30min