Working with Large Files in Claude Code
Large files create specific problems for context and quality. Here's how to handle them without degrading the session.
Files over 500 lines create problems for Claude Code that smaller files don't. Not because Claude can't read them — it can — but because they eat context budget fast and make it harder for Claude to hold the full picture in attention at once.
Here's how I work with large files effectively.
Show Claude the relevant section, not the whole file
For targeted changes — fixing a function, adding a method, updating logic — I paste the relevant section rather than the whole file. I include enough surrounding context to orient Claude (the imports, the class definition, a few lines before and after), but not the entire 1000-line module.
Claude doesn't need to read code it's not changing. Keeping it focused on the relevant section produces tighter output.
For whole-file changes, use a description instead of the full content
If I need Claude to understand a large file but not modify it directly, I describe it rather than paste it. "This is a 600-line data transformation module. It exports three functions: normalizeUser(), normalizePost(), and normalizeFeed(). The normalizeUser function is at line 45 and has this signature: [signature]."
That description uses far less context than the full file and gives Claude what it actually needs: an understanding of what exists and where to find things.
Split the work across sessions
If a large file needs significant refactoring, I don't do it in one session. I identify the logical sections — each one a coherent module that could stand alone — and refactor them one per session. Between sessions I run tests to confirm nothing broke.
This keeps each session focused, keeps context clean, and gives me clear checkpoints where I can verify correctness.
Add section markers to the file
For files I work in repeatedly, I add comment markers that divide the file into named sections. When I need Claude to work in a specific section, I reference the marker name instead of pasting the whole file: "In the VALIDATION section, add a new validator for..."
Claude can then ask to see just that section if needed. The markers also make the file easier to navigate for anyone reading it.
When large files are the real problem
Often a large file is a sign that the module needs splitting. A 1000-line file that's hard for Claude to work with is also hard for human developers to work with. If I find myself regularly struggling to give Claude enough context to work on a file, that's usually a signal to break it apart rather than optimize how I share it.
Claude can help with that too: "This file is 800 lines. Suggest how to split it into focused modules with clear responsibilities." The suggestions are usually good starting points.