Small File Optimization

Anecdotal evidence that smaller files yield better agent responses, avoiding incidental context loading, human readability benefits aligned with agent performance

← Back to Harness engineering: Leveraging Codex in an agent-first world

Optimizing for smaller file sizes is a critical strategy for improving AI agent performance, as it minimizes "incidental context" and prevents a "death spiral" of exploding token usage. Because agents typically ingest entire files rather than targeted snippets, modularity reduces input noise and encourages the model to generate tighter, more focused solutions. While a highly fragmented codebase could potentially force an agent to struggle with excessive dependencies, the benefits of high code density are already reflected in the LLM's surprising proficiency with concise languages like Clojure. Ultimately, maintaining a low line count ensures the model stays focused on relevant logic rather than parsing irrelevant data that happens to live in the same file.

2 comments tagged with this topic

View on HN · Topics
> - Do we have reasons to care about LOC in a world where we don't write code manually? What happens to token usage numbers when the codebase is significantly larger? Yes, at least to the extent that we care about context windows and tokens consumed by coding agents processing code that is ultimately irrelevant to their assigned task. Anecdotally, I've found keeping file sizes small has been important for agentic coding not just to maintain human readability, but also for optimizing agent performance, precisely because it limits the amount of incidental context they load while working a problem, because they generally load entire files rather than just parsing the part relevant to their current assignment as a human might. That smaller file size thus reduces input noise and the LLM generates a tighter solution, which in turn reduces input noise for future solutions. Or at least this strategy avoids a death spiral into exploding context length. I expect (but cannot currently prove) that keeping overall LOC down yields similar benefits even when file sizes are kept small because it spares the LLM from parsing potentially relevant files that prove irrelevant to its current task.
View on HN · Topics
Seconded on smaller files. I feel like I tend to get better responses faster. A notable flaw here is that I’ve not tried large vs small files in a large codebase. Most of my experimentation there has been on personal projects where even a small file contains a significant part of the project. I could see degradation when it has to load 5 files to figure out how something works. Total LOC (tokens, really, literal lines probably don’t matter) is interesting as a factor. That might go some way towards explaining why LLMs are weirdly good at Clojure. Eg last I checked Anthropics one-shot performance on Clojure was about the same as Python or Go despite almost certainly being less represented in training data. The combination of density and simple primitives might be easier for an LLM to wrangle, ameliorating the impact of a less popular language.