multi-file edit patterns

analysis of 3,312 threads with file editing operations (71% of 4,656 total threads).

distribution

files touched	threads	% of editing threads
1	1,173	35.4%
2	571	17.2%
3	376	11.4%
4	291	8.8%
5	177	5.3%
6-10	526	15.9%
11+	194	5.9%

takeaway: ~65% of editing threads touch multiple files. the median is around 2-3 files. long-tail extends to 76 files (a single resolved thread).

steering correlation

file bucket	threads	avg steering	success rate
1 file	1,177	0.16	47.1%
2-3 files	947	0.38	70.9%
4-5 files	468	0.63	75.9%
6-10 files	526	0.76	71.7%
11+ files	194	1.01	73.2%

key finding: multi-file threads require ~3.7x more steering than single-file threads (0.58 vs 0.16 avg). BUT they have significantly higher success rates (72-76% vs 47%).

interpretation

single-file threads have LOW steering but LOW success. this suggests:

many are quick fixes or exploratory queries that don’t fully resolve
users may not invest steering effort in small tasks
partial work gets abandoned more easily when scoped small

multi-file threads (4-5 files sweet spot) have the highest success rate at 75.9%. these likely represent:

well-scoped feature implementations
meaningful refactors
changes that require cross-cutting coordination

threads touching 11+ files maintain ~73% success despite high complexity, likely due to:

users actively steering to completion
larger tasks getting more intentional oversight

outcome breakdown

single-file threads (n=1,173)

RESOLVED: 468 (40%)
COMMITTED: 84 (7%)
UNKNOWN: 467 (40%)
HANDOFF: 125 (11%)
FRUSTRATED: 2 (0.2%)
EXPLORATORY: 25 (2%)

multi-file threads (n=2,139)

RESOLVED: 1,356 (63%)
COMMITTED: 191 (9%)
UNKNOWN: 344 (16%)
HANDOFF: 223 (10%)
FRUSTRATED: 11 (0.5%)
EXPLORATORY: 9 (0.4%)

takeaway: multi-file threads are 1.8x more likely to resolve (72% vs 47% success). the UNKNOWN rate drops from 40% to 16%—users invest more tracking effort when changes span multiple files.

frustrated threads

only 13 frustrated threads with file operations:

2 single-file (both small fixes that went sideways)
11 multi-file (larger tasks that got stuck)

frustration rate is slightly higher for multi-file (0.5% vs 0.2%), but absolute numbers are tiny. multi-file doesn’t significantly increase frustration risk.

extreme cases (10+ files)

the top 10 threads by file count:

files	outcome	steering	notes
76	RESOLVED	0	massive store refactor (main dashboard)
49	RESOLVED	6	nix config restructure
42	RESOLVED	3	minecraft resource pack converter
41	PENDING	3	(only incomplete one)
40	RESOLVED	2	deploy_cli monorepo setup
36	RESOLVED	0	ai e2e test suite
29	RESOLVED	0	cloudflare streams impl
29	RESOLVED	3	platform db datasets
27	RESOLVED	0	web_platform client integration
27	RESOLVED	1	github workflows

observation: 9 of 10 resolved successfully. large multi-file edits are NOT doomed—with proper context frontloading (or zero steering if context is perfect), they complete well.

recommendations

don’t fear multi-file tasks: they succeed MORE often than single-file, not less
sweet spot is 4-5 files: highest success rate, moderate steering cost
single-file warning: low success rates may indicate underinvestment or task abandonment
steering scales with scope: expect ~0.6 steering messages per multi-file thread vs 0.16 for single-file
zero-steering success: some of the largest threads (76, 36, 29, 27 files) succeeded with 0 steering—likely well-contextualized upfront prompts

methodology

extracted file paths from edit_file and create_file tool calls in assistant messages
counted unique file paths per thread
joined with thread metadata (completion_status, steering_count)
success = RESOLVED + COMMITTED