Help & Questions3 replies
I am working with a coding agent on a repository with about 400 files, and it reads essentially all of them before it does anything useful. Every request it makes is enormous, and it takes minutes to get to a first edit.
I have a repository map, the tree, the instructions — the usual setup. What am I doing that makes it read the world?
Accepted answer
The map is not the problem. What is happening is that the agent is doing a search-then-read loop, and every read result stays in the conversation, so the context grows with every file it opens.
Four things to look at, in this order.
1. The search is too broad. If the agent greps for a common word and gets 200 hits, it will read a lot of files to find the right one. A narrower search — the symbol name, the exact string, the file path — returns a handful. The number of files it opens is usually set by the width of its first search, not by the size of the repository.
2. It is reading whole files. A 2,000-line file is 2,000 lines in the context, even if the answer is in forty of them. A tool that returns the matching lines with a few lines of context around them changes the arithmetic completely. /tools/repo-to-prompt does the same thing for a bulk case.
3. Nothing is being summarised. The agent should be writing down what it found — the file, the function, the conclusion — and carrying that forward, rather than carrying the file forward. If it is not maintaining a summary, every subsequent request re-reads everything.
4. The repository map is not being used. A map that lists files and symbols is exactly what lets the agent open four files instead of two hundred. If the map is stale or too shallow, the agent falls back to grepping, and you are back to case 1.
The measurement that tells you which one it is. Log the number of files read and the total tokens in the request per turn. If the files read is small and the tokens are large, it is case 2. If the files read is large, it is case 1. If both are small and the agent is still slow, the problem is the number of turns.
Case 2 is the one I would check first, because it is the easiest to fix and the most common.
Returning a whole file when the agent asked for a symbol is a design decision in the tool, and it is one you can change. A tool that returns the matched region plus the file path is a better tool, and it is a small change in the tool implementation rather than in the prompt.
It was case 1 and case 2 together. The agent was searching for a word that appears in 180 files, and the file-reading tool returned whole files.
Narrowing the search to the exact symbol and returning only the matching region took the first edit from about four minutes to about thirty seconds. The measurement you suggest — files read and tokens per turn — is what made it obvious, so I am keeping that.