← Anti-Patterns · Headliner
The 9,000-Line Component
When AI keeps adding behavior to one massive file because nobody stopped to redesign the structure.
What it is
One file holds the data fetching, the rendering, the business rules, and the side effects for an entire feature. Every new requirement gets appended. Nobody ever splits it.
How it happens
Each individual change makes sense in isolation. “Add a tooltip here.” “Handle the loading state.” “Add the empty case.” Each prompt is small, each diff looks reasonable, and the AI gladly extends the file you point it at. Nobody zooms out.
Warning signs
- The file mixes distinct concerns — data fetching, rendering, business rules, and side effects all in one place.
- Every change in this area starts the same way: “let me re-read the file first.” Every time. By everyone.
- Reviewers admit they’re trusting the diff in isolation, because the file as a whole is too much to load in their head.
- AI sessions on this file routinely hit context limits — and the model adds new code rather than restructuring, because it can’t see the whole picture at once.
- Changes here take meaningfully longer than equivalent changes elsewhere in the codebase, and people quietly route around it when they can.
Why it’s dangerous
The cost of every change in this area scales with the size of the file, not the size of the change. Bugs cluster here because nobody can hold the whole thing in their head. New AI work prompted against this code inherits the mess as its starting context, so each new generation comes out more sprawling than it had to be. The file becomes a black hole that bends every nearby change toward itself.
The AI era hasn’t made this go away — but it has changed the math underneath it. The structural change is now dramatically cheaper than it used to be, if you have the habit and the tests to use that leverage.
How to prevent it
Make refactoring a habit, not a project. Every time you finish a feature — tests passing, ready to commit — ask the question: is there an obvious low-risk, high-value refactor sitting in this diff or its neighborhood? Most of the time the answer is “not today.” Sometimes it’s “this 800-line file wants to be three smaller ones,” and AI can carry out the split in the same session that wrote the feature.
Line counts aren’t the signal — friction is. When changes here cost more than they should, you’ve found one.
The serious team fix
Three things, reinforcing each other:
- A team habit of opportunistic refactoring. At the end of every shippable change, ask the refactoring question out loud. Bite off the small ones inline. Note the bigger ones for a dedicated session.
- An AI assistant tuned to scout for opportunities. A slash command, an agent, or a recurring prompt — whatever fits your tooling — that periodically scans the codebase for files trending the wrong way and proposes concrete cohesive splits. The human decides what the new shape should be; the AI does the legwork of surfacing candidates and drafting the diff.
- Real test coverage — unit and integration. Without tests that exercise actual flows end-to-end, no refactor is safe and “we’ll clean it up later” becomes never. With them, AI can carry out the structural change while the suite verifies behavior is preserved. The integration tests are the precondition that makes everything above possible.
The shift is: refactoring stops being a heroic intervention and becomes cheap, frequent maintenance. That’s what “using AI well” looks like for code that’s already in your repo.