git.example.com/felixbrandt/fleet-dashboard ↗
Internal fleet dashboard. Dashboard.tsx was 4,000 lines so I had Claude Code break it up. It is now 31 files, and several are 20 line components that take eight props and are used once. Tests still pass. Honestly I find it harder to follow than before and I would like a sanity check on whether that is habit or a real regression.
The prompt shape matters here. "Split this file" optimises for the thing you can measure, which is file size, so you get 31 files. Ask for the boundary instead: "which parts of this file change for different reasons, and what would each own". Then refactor along the answer.
It also helps to say explicitly that a component used once should stay inline. Otherwise extraction is the default move at every level.
It is a real regression, and a common one. A component used once, taking eight props, is not an abstraction. It is the same code with an argument list bolted on, and now you read two files instead of one.
The useful split is by what changes together, not by line count. In a dashboard that is usually: the data layer, one component per widget that owns its own query, and a layout that arranges them. Three or four real boundaries, not 31.
Inline anything that is used once and has more than about four props. Keep the pieces that another screen actually reuses. You will probably land around 900 lines across six files, and that is a better place than either end.
