A checkout rounding fix can pass its unit tests and still break another consumer of the same pricing function. Giving a coding agent the entire repository does not guarantee it will identify that dependency. Restricting it to the edited file can hide the dependency altogether.
That is the practical challenge of AI repository context: provide enough evidence to make a reliable change, while preserving a way to discover what is missing.
The useful default is a task-specific starting point, followed by dependency tracing and explicit reasons to expand the investigation.
Separate access, indexing, and active context
These terms describe different things:
- Repository access: What the agent can inspect.
- Repository indexing: What a search system has cataloged.
- Active context: The instructions, code, conversation, and tool results supplied to the model for a particular step.
An agent can search an entire monorepo while loading selected files into its active context. An index can cover the repository while retrieving a few passages.
Should AI agents read the entire repository? For a small project, that may be reasonable. For a large codebase, the more useful question is: what must the agent establish before making this change?
What makes context expensive?
Large inputs, repeated reads, and verbose tool output can increase processing costs and waiting time. The actual economics depend on model pricing, caching, and the agent’s execution system. Retrieval also has overhead.
Irrelevant code can introduce ambiguity. Imagine an older service that validates authentication tokens directly and a newer service that uses shared middleware. Both implementations exist, but the agent must determine which pattern governs the target service.
Too little context creates a different cost. A reviewer may have to discover missed callers, explain a compatibility requirement, and request another implementation.
Evaluate the total work required to reach acceptance. Token usage is only one part of that calculation.
A larger context window does not resolve scope
A larger LLM context window can help an agent examine several relevant components together. It does not establish that those are the right components.
Research should be interpreted carefully. Lost in the Middle found that information position affected performance in the evaluated retrieval and question-answering tasks. Those findings do not establish a universal limitation for current coding agents. Read the study.
Later research reported strong retrieval near the context limit for Gemini 2.5 Flash on simple factoid questions. Retrieving a fact, however, differs from coordinating a compatible change across services. Read the findings.
Neither result provides an optimal context size for your repository. Test the workflow against actual engineering tasks.
A practical workflow for coding agent context
Consider a hypothetical discount-rounding bug. The agent has located a function in a shared pricing package.
1. Establish the intended behavior
Before implementation, clarify:
- Should rounding happen per line item or after aggregation?
- Which currency precision applies?
- Must historical invoice behavior remain reproducible?
- What input demonstrates the failure, and what result is expected?
The current code may explain existing behavior without establishing intended behavior. Resolve missing business rules through a specification or an owner’s decision.
The first output should be a short explanation of the discrepancy, supported by the failing example.
2. Trace the dependencies
Inspect callers, exports, shared types, configuration, and relevant tests.
If the pricing function serves checkout and subscription billing, determine whether both need the new behavior. The correct fix might belong in the shared function or in checkout-specific handling.
Combine symbol references, text search, and semantic retrieval where available. Treat search results as leads to verify. Reflection, dynamic registration, and external consumers may require additional investigation.
Ask the agent to name affected components and explain why each matters.
3. Expand on explicit triggers
Broaden the investigation when the agent discovers:
- An exported utility or shared interface
- Another consumer with different expectations
- Configuration that changes runtime behavior
- Conflicting documentation and implementation
- A failing integration or contract test
- An unresolved compatibility question
This helps reduce context for coding agents without imposing an arbitrary file limit.
If the agent cannot establish whether a consumer depends on existing behavior, record that uncertainty. Obtain the missing evidence before presenting the change as ready.
4. Preserve findings
For longer tasks, keep concise notes covering inspected components, decisions, source locations, and unresolved questions.
Verify important retrieved passages against the current checkout. An index can lag behind the code; a summary can omit an exception.
Keep repository instructions focused on navigation, critical constraints, local conventions, and validation commands. Extensive duplicated implementation details create more material to maintain.
5. Verify behavior and impact
For the rounding fix, test boundary values and the agreed calculation rule. Check the relevant consumers and inspect the diff for unintended changes.
A passing unit test supports a specific behavior. It does not demonstrate that the dependency investigation was complete.
When broader analysis is appropriate
Match investigation scope to the task:
| Task | Useful starting scope |
|---|---|
| Localized bug | Failing case, implementation, callers, tests |
| Small unfamiliar repository | Overview and potentially a full read |
| Shared API migration | Producers, consumers, schemas, clients, rollout |
| Architecture change | System boundaries, contracts, ownership |
| Security review | Defined coverage and relevant trust boundaries |
Changing an API field from optional to required may affect generated clients, fixtures, contract tests, and deployment order. Begin with a broad inventory, then investigate each affected area.
Do not exclude lockfiles or generated code solely because they are large. Their relevance depends on the task.
Measure cost per accepted change
Compare context strategies using the same task set, repository revision, model configuration, and acceptance criteria. Run independent trials so one strategy does not inherit another’s findings.
Track model and tool costs, review effort, rework, acceptance rate, and observed regressions. Include context preparation and maintenance.
Use:
Cost per accepted change = total cost of attempts, validation, review, and rework ÷ accepted changes
Include unsuccessful attempts. Track elapsed time separately from hands-on effort.
The goal is guidance by task type. A compact repository may favor broad reading; a monorepo bug fix may benefit from selective investigation.
Make the investigation reviewable
Better AI repository context supports a reviewable explanation of the change:
- Which behavior must change?
- Which contracts constrain it?
- Which consumers were checked?
- What remains uncertain?
- Which checks support readiness?
The agent’s patch and its supporting evidence should make those answers clear.
What do you ask an agent to show before accepting that it investigated the relevant dependencies?
Top comments (0)