Why More Context Can Make Coding Agents Worse

More evidence is not always better evidence

A model can process a great deal of text while still struggling to decide which part matters. If a prompt includes unrelated modules, generated files, old logs and contradictory documentation, the relevant failing assertion may be harder to use. The model can imitate a plausible pattern from the wrong package. Additional context also costs tokens, latency and potentially data exposure. The problem is not the size alone; it is the declining signal-to-noise ratio.

When an agent's answer worsens after you attach more files, inspect what changed. Did the new material contain a deprecated example? Was the correct code now surrounded by multiple near-duplicates? Did a summary replace exact test output? Understanding this failure is more useful than simply reducing every prompt to a tiny fixed size.

Contradictory versions create false confidence

Repositories often contain generated clients, migration snapshots and copied examples. A long prompt may include several versions of the same API. Without clear paths and revision information, the model can merge them into an implementation that never existed. A stale search index or previous chat episode can add another version. The resulting patch may look internally consistent while targeting the wrong contract.

Before editing, ask the agent to identify the authoritative source and current branch. Open the actual file, inspect its callers and run a relevant test. Mark historical material as historical. A broad architectural overview can still be useful, but it should not be treated as current line-level evidence.

Long logs can bury the decisive error

An agent that pastes an entire build log may spend most of its context on successful compilation messages, repeated warnings and unrelated stack frames. The single failing assertion becomes easy to miss. Summarize the command, exit code and first relevant diagnostic, and keep the full log available for targeted follow-up. If the initial hypothesis fails, inspect more of the log rather than resending everything reflexively.

This is especially important in iterative agent loops. A huge log attached to every retry increases cost without adding new information. The agent should explain what changed between attempts and which new evidence justifies another edit. Otherwise more context can simply reinforce a mistaken direction.

A better expansion rule

Begin with the request, relevant error and smallest set of source files that can support a hypothesis. Add a caller, test fixture or configuration file when a specific question requires it. After each new piece, ask what it changes. If it does not alter the understanding or the next action, leave it out of the model request. This is a discipline rather than a rigid token cap.

For a public API migration, broader context may genuinely be needed to find every caller. In that case, include a structured map and then inspect each affected module. The rule is not 'always use less.' It is to make every added source earn its place in the decision.

Measure quality, cost and reviewability

Try the same task with a narrow evidence set and a broad one. Compare whether the final patch passes tests, how many unrelated files changed, how many agent retries occurred and what the provider billed. Also ask whether a human can trace the reasoning from cited files. If broad context prevents missed dependencies, the added cost may be justified. If it produces confusion or duplicates, the extra material was harmful.

Do not optimize only for token count. An agent that saves tokens by ignoring a required contract is not efficient. The ideal is a verified change with the minimum sufficient evidence, plus an explicit route to fetch more when uncertainty remains.

A concrete prompt repair

Suppose an agent proposes changing an old checkout helper after reading a broad folder dump. The failing test actually imports a newer route handler. Instead of supplying more of the same directory, give the test import path and ask the agent to trace the runtime call. Remove the deprecated helper from active context, but keep it available as historical background if needed. The new evidence should change the hypothesis before any patch is applied. This repair illustrates why relevance and provenance matter more than raw size. It also gives the human reviewer a clear reason for the eventual edit, which a larger undifferentiated prompt would not provide. Repeat this test with a second issue that truly depends on the old helper. The lesson is not to ban historical code, but to mark its status and bring it into the request only when the evidence requires it. Context should evolve with the investigation rather than accumulate every file seen along the way. Keep the final evidence list short enough for another developer to review independently.