How AI Coding Tools Read Your Repository

When comparing AI coding tools, we usually look at the model name first. However, even with the same model attached, results vary significantly depending on the tool. The reason is simple.

A model only sees what it is given. Even if a repository has 100,000 lines, only a tiny fraction goes into the model. Selecting that fraction is the real function of the tool.

The Journey from Repository to Model

The process can be divided into four stages.

1. Indexing

The tool scans the repository and makes it searchable. A common method is to split files into semantic units and convert each piece into a vector for storage. This is called embedding.

Differences already emerge here.

• Splitting unit: Whether it splits by function or fixed length. If cut in the middle of a function, that piece loses its context.
• Indexing scope: Which extensions are included, and whether build artifacts and dependency directories are excluded.
• Update timing: Whether it happens every time a file is saved or periodically. An outdated index causes the model to answer based on code that no longer exists.

2. Search

When a query comes in, the tool finds relevant pieces. Usually, it mixes two methods.

Good tools use both together and re-rank the results. If this stage is poor, even the best model will answer based on the wrong files.

3. Context Assembly

The found pieces are organized into the order and volume to be fed into the model. Since the context window is finite, something must always be discarded.

A common occurrence here: If you include entire files, you can only fit two or three; if you only include snippets, the surrounding context is lost. Each tool strikes this balance differently—giving weight to open files, prioritizing recently edited files, or following import relationships.

4. Iteration

Agentic tools don’t finish in one go. They generate an answer, run tests, and if they fail, search again to swap out the context. This process repeats multiple times for a single task. This is why costs can spike, but also why they can solve difficult problems.

Where Things Break Down in Large Repositories

As scale increases, problems appear in the following order:

1. Indexing time and cost increase. Initial indexing takes time, and frequent changes require constant rebuilding.
2. Search accuracy drops. There are more files with similar names, and utility functions are everywhere.
3. Context competition intensifies. If there are ten relevant files, you can’t fit them all.
4. Outdated code becomes the basis. If deleted functions or deprecated modules remain in the index, the model refers to them when answering.

Practical Steps to Improve Results

These are more effective than switching tools.

1. Clean up the indexing exclusion list. Exclude build artifacts, dependency directories, large data, and auto-generated code. Search quality improves immediately.
2. Remove secrets from the repository. Indexing reads what is readable. It’s safer to not have them there at all rather than relying on exclusion settings.
3. Delete deprecated code. Leaving old implementations as comments leads to them being used as a basis. Let the version control system handle the history.
4. Keep directory structures and naming consistent. Semantic search relies heavily on names.
5. Place a rules file in the repository. If you provide documentation on structure, conventions, and prohibitions, the tool will include it in the context every time.
6. Manually specify the file scope in your query. If the tool knows which directory to look in, skipping the search step is the most accurate approach.

Number 6 is the most effective in practice. “Fix the login handling in this repository” works much less reliably than “Fix the expiration logic in auth/session.py“.

What to Look for When Comparing Tools

Look at these instead of performance charts.

• How much can you control the indexing scope and exclusion settings?
• Does the index stay local or is it sent externally?
• Does the search use both keywords and semantics?
• Does it show which files were used as the basis for the answer?
• Can you check what was included in the context?

The last two are particularly important. Tools that show their reasoning allow you to understand why they were wrong, while tools that don’t leave you guessing.

Summary

1. Tools don’t put the whole repository into the model; they put selected parts. That selection determines the answer.
2. The process is Indexing → Search → Context Assembly → Iteration, and the design of each stage varies by tool.
3. Large repositories break down first in search accuracy and context competition.
4. Cleaning exclusion lists, deleting deprecated code, consistent naming, and rules files are more effective than switching tools.
5. Manually specifying the file scope is the most certain improvement.

Frequently Asked Questions

Where is the index stored?

It varies by tool. Some keep it only locally, some store vectors on a server, and some store parts of the original text as well. If you are handling internal code, you should check this in the contract or settings first.

If the context window is large, isn’t indexing unnecessary?

Even as windows grow, putting the entire repository in every time is unrealistic in terms of cost and speed. Furthermore, including too much irrelevant content can actually decrease accuracy. Therefore, the selection stage remains necessary even with large windows.

Is there a reason why results are particularly poor in monorepos?

There are many files with similar names and duplicate utilities, and service boundaries are often only separated by directories, which confuses the search. Specifying the target package or limiting the tool’s workspace to that directory significantly improves results.

Are tools that don’t use indexing poor in performance?

They have different purposes. Methods that work only with open files and instructions are lightweight and predictable, making them suitable for small edits, while indexing-based tools are advantageous for tasks that span across the repository. Choose based on the nature of the task.