In this article
Aider’s repository map provides structural awareness; full implementation context and the editable file set remain separate choices.
Aider’s repository map provides concise structural context; it is not the full content of every repository file or permission to edit every mapped file. Add the implementation you want changed explicitly, and keep reference-only material separate.
The concrete application boundary
The documented map includes important classes, functions, types, and call signatures. That helps a model relate the selected code to other parts of the project and reuse existing abstractions. It does not mean every function body is available in full detail. A model may know that a helper exists while lacking the exact branch it needs to modify. Treat that as a context-selection problem before changing model capacity. The editable file set is another boundary: a symbol appearing in structural context is not an instruction to rewrite its source. A narrow task should identify the target implementation, the interface it depends on, and the relevant existing test (Aider repository map).
A practical route
Ask Aider to locate the relevant symbol conceptually, then inspect the actual source yourself. Use /add for the file that must be editable. Supply supporting files as read-only context where appropriate rather than automatically widening the editable set. Ask a question about the behavior in ask mode before requesting a change. After the edit, review the diff and check that only the intended implementation or test changed. If the assistant requests another file, evaluate why its full contents are needed (Aider chat modes).
A worked example
A formatter calls a shared status helper. The repository map exposes the helper’s signature, but the requested change concerns a branch inside the formatter. Add the formatter and its relevant test as needed, while keeping the helper as reference context. Ask the model to preserve the helper’s interface. If it proposes modifying the helper instead, stop and compare that expansion with the original requirement.
| Check | Record |
|---|---|
| Structural context | The helper’s signature and its relationship to the target code. |
| Editable context | The actual formatter implementation and any intentionally editable test. |
| Review boundary | No unrequested modification of the shared helper interface. |
Reading the failure correctly
A plausible explanation based on a symbol name can still miss implementation details. If the patch addresses a nonexistent branch, provide the actual file content and retry the narrow question. Conversely, adding every file can obscure ownership and create unnecessary edit scope; more context is not equivalent to a better-defined task (Aider Git integration).
What completes the check
The useful distinction is awareness versus implementation access versus editing scope. Keeping all three explicit lets a local model work with the needed code without pretending the repository map is a complete, editable copy of the project.
Related background: Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.