An AI coding assistant needs the smallest coherent slice of your repository that explains the task, not a set number of files or tokens. That slice should cover the code you want changed, the definitions it relies on, any files that shape its behavior, and a check that shows whether the change works. Everything else stays out until a real gap shows up.

How much that adds up to depends on the task. A one-function bug fix may need three files, and a cross-module refactor may need many more. The rest of this guide shows how to pick each piece and when to widen the slice.

How Much Repository Context Is Enough?

No single file count or token budget fits every task. Use a simple selector instead. This is our editorial rule of thumb, not a tested performance formula.

Think of your starting context as four groups of relevant files or snippets. T is the target implementation: the code that has to change. D is the dependency and interface code that T relies on. C is configuration, schemas, or conventions that change how the behavior works. V is the applicable checks, such as tests, and their expected results. Your initial set is S = T ∪ D ∪ C ∪ V. The union symbol just means you combine the groups, and a file that fits more than one group counts once.

For example, a test file might also be the clearest example of how an interface is called. It goes in once and covers two roles. The result is a set built for this task. It will not match the next task, and it does not guarantee that you stay within any token limit.

To keep the set tight, ask one question about each candidate file. Does it explain the requested behavior, define a relevant boundary, or help check the result? If the answer is no for all three, leave it out. This keeps your AI coding context focused on what the assistant needs.

Start With the Behavior, Then Trace Its Code

Begin by writing down the behavior you want, before you pick any files. State the change in a sentence or two, then name its boundary: what should change and what must stay the same. “Return a 404 instead of a 500 when the user ID is missing, without changing the response format” gives you a clear starting point.

Next, find the code that produces that behavior today. That is your target implementation. From there, follow what the code actually uses. Researchers behind the REPOEXEC benchmark describe repository dependency examples such as function calls, imports, and class hierarchies. They also note that code can rely on definitions in the same file or in other files. Treat those as examples to look for, not a full checklist.

The key difference is between code your target relies on and code that just sits nearby. A helper your function calls belongs in the set. A sibling module in the same folder that never touches the change does not. The same goes for a parent class whose methods your code overrides compared with an unrelated class in the same package.

Do not remove a dependency merely to make the prompt shorter. In the REPOEXEC benchmark, the authors compared full, medium, and small dependency contexts and reported the strongest results with full context for the tested models. This is a result from that benchmark, not a universal ranking of context strategies for current coding agents. It does not establish that sending an entire repository is better.

Include Supporting Files Only When They Affect Behavior or Validation

Configuration, schemas, conventions, and examples belong in the set only when they change the answer. A feature flag file matters if the new behavior sits behind that flag. A database schema matters if the change reads or writes those columns. A style guide or lint config matters if the assistant’s output must follow rules it cannot guess. A sample call site helps when it shows how an interface is meant to be used. If a supporting file has no effect on the behavior, its boundary, or how you check it, it is noise.

Checks deserve a special place. When a relevant test or other executable check exists, include it along with the result you expect. That gives both you and the assistant a concrete way to judge the change. The REPOEXEC paper’s functional correctness evaluation checks whether code does its intended task, often by running test cases and comparing the output with the expected output for a given input.

Keep a passing check in perspective. It shows the change meets what that check covers. It does not prove every other behavior in the repository still works. If no test covers the new behavior, say so and describe the expected result in plain terms. That still gives the assistant a target.

When Should You Widen the Context?

Widen the slice when there is a specific gap, not because more files feel safer. Three signals are worth watching for.

First, the task itself crosses areas. A change to a shared data model, an API contract, or an auth rule can affect several modules. In that case, trace the relationships into each affected area and include the definitions that connect them. Second, a relevant caller, dependency, or interface is still unclear. If the assistant guesses at a function’s signature or asks what a type contains, add the file that answers that question. Third, your check leaves part of the behavior uncovered. If the test only covers the happy path but the task also changes error handling, add the code or examples that define the error case.

Each added file should answer a question you can name. “This file defines the type the new function returns” is a good reason. “This file is in the same folder” is not. A broad task can justify a broad AI coding context. That still does not make every repository file a default part of every request.

What If the Assistant Cannot Inspect the Repository?

What you share depends on what the assistant can actually reach. Some workflows let an assistant open, search, or index repository files. Others only see what you paste or attach. Check what your own setup supports instead of assuming either way.

If the assistant cannot inspect the repository, you are the retrieval step. Provide the target code and the dependency, interface, supporting, and check files that pass the selection test above. Snippets are fine when a full file would mostly be unrelated. Just keep the signatures, types, and imports the snippet relies on.

If the assistant can inspect files, you usually do not need to attach everything up front. Describe the task, its boundary, and the area of the codebase where it lives. Point to the check that should pass. Then let the assistant open what it needs, and watch which files it reads. If it skips a contract or config file you know matters, name that file directly.

FAQs

Should I share full dependency code or just function signatures?

Share the full implementation when the behavior of the dependency matters to your change. In the REPOEXEC benchmark, full dependency context gave the best results among the levels tested, while signatures and docstrings alone still showed some potential. Signatures can be enough when the target code only needs to call a function correctly.

Can extra unrelated files hurt the result?

Unrelated files do not explain the task, and they can blur which behavior is in scope. They also take up room you could use for a dependency or check that matters. Leaving them out keeps the request easier to follow for both you and the assistant.

What should I do when the assistant asks for more files?

Treat the request as a signal that something is missing. Check whether the file it asks for answers a real question about a dependency, interface, or check. If so, add it. If the request seems off-task, restate the behavior and its boundary before sharing more.

How should I describe the task alongside the code?

Write the change as an observable behavior with a clear boundary, such as an input and the output you expect. Mention what must not change. If a test covers the behavior, name it and state the result it should produce after the change.