Working Is Not Organized: Measuring How Data Access Spread in an AI-Built Application

In an AI-built application, operations on one settings table were named in 29 files through 14 differently named calls. We measured the spread and what a structural rule changed.

Core Finding:AI coding agents are usually judged task by task: does the change work, do the tests pass, is the code clean? We looked at what those changes add up to in one application our agents built over several months. Operations on one settings table are named in 29 files through 14 differently named calls. A rule that a visit with no service delivered cannot be paid exists as two separate implementations that return different errors. Of 145 record types named by literal operation strings in the code, 77 are referenced from more than one file. This is a different problem from code slop. Slop is dead code, swallowed errors, invented functions and fake tests, and each instance is visible in the diff that adds it. Scatter is hard to see in any one diff: a new read path can look reasonable where it is written. It shows up when you count across the codebase. The application's slop gate has 42 numbered checks, and none of them counts how many files reach the same table. We then measured one consolidation lane that moved data access into per-table owner modules: settings references went from 29 files to 1, and user profile references from 19 files to 2. That lane is unmerged and its validation is blocked, so it describes what the rule does to the code, not a released outcome. Data from October 22 and 23, 2026 (code as of those commits), analyzed October 23, 2026.

Settings table

53 sites, 29 files, 14 call names

53 call sites in the application code name a settings operation. 29 code files name a settings read; 7 of 11 write mentions sit in the owner file.

Spread across record types

77 of 145

Record types named by literal operation that are referenced from two or more files. 13 are referenced from five or more.

One rule, different errors

Two implementations

The rule that no-service visits cannot be paid lives in a route helper and in a rules file, with a third related check in payroll.

After one consolidation lane

29 files to 1

Settings references after a single unmerged, unvalidated lane moved them into a table owner module. User profiles went from 19 files to 2.

Empirical Findings Table

Most record types named by literal operation were referenced from more than one file. The most-used tables were referenced from dozens of call sites, through many differently named calls.

Telemetry Metric	Measured Value	Context & Observability
Application code measured	843 Python files	Including 159 route files and 58 files in the rules directory (counting its initializer), at one integration commit on October 23, 2026.
Direct calls to the older data entry	404 in 104 files	258 reads and 146 writes. Route files alone hold 151 reads in 53 files and 93 writes in 35 files.
Record types referenced from 2+ files	77 of 145	Across 752 call sites that pass a literal operation name. These are operation-literal references, not verified access paths. 13 types are referenced from 5 or more files and 4 from 10 or more. 87 are referenced through 2 or more differently named calls.
Settings table	53 sites, 29 files, 14 call names	Old and new data entries are both in use for the same table. Settings write operations are named in 5 code files, with 7 of the 11 mentions in the owner file. Settings reads are named in 29 code files. These are text matches for operation names, not confirmed accesses.
User profile table	60 sites, 19 files, 19 call names	The second most widely referenced record type by file spread.
Uppercase literal sets copied across files	32 of 186	Distinct literal sets of two or more uppercase constant strings that appear in 2 or more files. They include statuses as well as roles, error codes, channels and document types. 9 appear in 3 or more. One set accepts two spellings of the same error in 4 files.
After one consolidation lane	Settings 29 to 1 file; profiles 19 to 2	Record types referenced from 5 or more files fell from 13 to 8. The lane changed 127 application files, 3,470 lines added and 3,073 removed. It is unmerged; its one recorded scoped test run had 349 passed, 95 failed and 7 errors, and its later changes are unvalidated.

Engineering Action Directives

Count access paths per table and copies per business rule across the codebase.

DON'T

Assume a clean diff review means the system is organized.

Send every table through one shared data picker with per-table configuration, keep each rule in one file, and lock each table with a guard test once it is clean.

DON'T

Expect per-diff review alone to catch spread that is easiest to see as a count.

Guard reads as well as writes.

DON'T

Stop at write owners: here the remaining spread was in reads, which the write guards allowed.

Methodology Boundaries & Limits

**One application, one snapshot.** This is a static census of a single AI-built codebase at named commits. It does not estimate how common the pattern is, and it has no comparison with human-written code of similar age.
**The counts see only what is literal in the code.** Calls that build the operation name at runtime, or reach a table through an older read module by function name, are invisible to the per-type count. On the scheduling consolidation lane our metric moved only from 5 files to 4, while the lane itself reported moving 198 call sites. The scanner also counts any call that names an operation, including diagnostic helpers, so it can overcount as well. The per-type figures are syntactic reference counts, not a bound on real access paths in either direction.
**The after numbers are not a released result.** The consolidation lane we measured is unmerged, and the per-table guard was held back. Its one recorded scoped test run had 349 passed, 95 failed and 7 errors; two setup fixes followed, and revalidation is blocked by an unrelated database setup failure, so its later changes are unvalidated. We report what the change does to the code, not whether it held up in use.
**We did not measure harm.** We did not count user-facing bugs caused by the spread. The team's stated reason for the standard is that the same data read two ways lets pages disagree and lets fixes miss copies. The differing errors for one rule are an example, but we did not measure how often this happens.