- Design quality paid off in steps: the largest file went from 2,400–3,500 lines (no brief) → 570–587 (plain split-things-up brief) → 434–498 (disciplined brief).
- "Just split it" causes over-splitting (Fable scattered filters across 8 tiny files). Only a brief with upper and lower bounds converged on a healthy middle.
- The discipline held for 13–16 un-briefed edits, and even after being broken it kept acting as an anchor that slowed further growth.
- The pattern was consistent across both Opus and Fable.
The experiment
Build a reading-log app, then apply 20 edits one at a time (due dates, priority, session history, summaries, a detail screen, tags, goals, a dashboard, settings…). Three conditions:
- B (no brief): features only
- A1 (plain design): domain split, interface design, anti-bloat UI policy
- A2 (disciplined design): A1 plus module discipline — 100–300 lines per file as a guide / no tiny per-widget files (consolidate similar responsibilities) / split the CSS too / put new features into existing modules first / YAGNI
The exact prompts (in Japanese, as sent):
▶ Download the initial prompts (B / A1 / A2) + all 20 edits (.txt)
Result 1: design quality pays off in steps
The core maintainability signal is the largest code module — the biggest single file an edit has to touch. Smaller is better.
Opus 4.8: largest code module, final (lines)
Fable 5: largest code module, final (lines)
A plain “split things up” brief cut it to roughly one fifth; writing the discipline down cut another 15–24%.
Result 2: "just split it" over-splits
Under A1, Fable scattered the filter UI across 8 tiny files (41 files total, one 1,424-line CSS). A2’s “consolidate similar responsibilities” and “split the CSS” rules fixed it: one filterBar.js (234 lines), 32 files, CSS in four parts. Guardrails are needed on both sides — against monoliths and against fragmentation.
Result 3: discipline decays — but keeps anchoring
Largest code module over the 20 edits (experiment 2). Dashed line = the 300-line rule set in the initial brief
The 100–300-line rule, stated once, survived 13–16 un-briefed edits. Opus broke it at edit 14 (495 lines) — then held that file flat for six more edits, routing new work into new files. Fable stayed under 253 until edit 17 and finished at 434. Even after the break, growth stayed slow.
File count: A2 absorbs edits into new files; B stays a single file
Takeaway — the value of software engineering
- The quality of the very first brief decides maintainability 20 edits later. None → plain → disciplined took the largest module from 3,500 to 587 to 434 lines.
- Write both bounds into the brief. "Split it" alone trades one kind of bloat for another.
- Initial design decays. The rule broke after 13–16 edits — keeping it fully honored needs ongoing mechanisms (reviews, linters). Up-front design and continuous governance are both engineering.
Legend: ■ Opus-A2 / ■ Fable-A2 / ■ Opus-B / ■ Fable-B (■■ = A1). One trial per condition. B was run twice and replicated (Opus 2,976→2,389 / Fable 3,330→3,463). The visible UI converged everywhere; the difference lives in the code structure. "Largest code module" counts HTML/JS only (CSS excluded).