August 25, 2026 · 8 min read

How Much Code Should You Give an AI Coding Assistant?

It's tempting to just dump an entire repository into Claude, ChatGPT, or Gemini and let the model figure out what matters. It works — up to a point. Past that point, you're burning context window on files the model never needed, and sometimes actively confusing it with noise that has nothing to do with the task at hand. The opposite mistake is just as common: pasting in a single file and wondering why the AI keeps suggesting changes that break something three files away it never got to see.

The right amount of context isn't a fixed number — it depends on what you're asking the AI to do. Here's how to think about it.

Why sending the entire repository is often unnecessary

Most real codebases carry a lot of weight that has nothing to do with the logic you're working on: lockfiles, compiled output, test fixtures, vendored dependencies, historical migrations. None of that helps the model reason about your actual question, and all of it eats into the context budget that could otherwise hold the files that do matter.

There's also a subtler cost. Larger contexts don't just cost tokens — they cost model attention. Even models with very large context windows tend to reason more precisely over a focused set of relevant files than over a sprawling dump where the signal is diluted by boilerplate.

When full-project context makes sense

Full-repo context earns its cost in a few specific situations:

• Architecture-level questions — "how does auth flow through this app" needs the model to see how pieces connect, not just one file in isolation.
• Refactors that touch many files — renaming a shared type or restructuring a module benefits from the model seeing every place that type is used.
• Onboarding a model to an unfamiliar codebase — the first prompt in a longer session, where broad context now saves you from re-explaining structure later.

When selective context is better

For most day-to-day work, a smaller, targeted set of files performs better:

• Bug fixes — the file where the bug lives, plus its direct dependencies, is usually enough.
• Adding a single feature — the relevant component, its types, and one or two files it talks to.
• Code review or explanation — just the diff or the specific file in question, without the rest of the app competing for the model's attention.

What generated and noisy files do to context

A few categories are worth excluding almost every time, regardless of task:

• Dependency directories and build output — node_modules, dist, build, .next — none of this is source code the model should reason about or edit.
• Configuration files that rarely change task outcomes — lockfiles, IDE settings, CI configs — unless the task is specifically about that configuration.
• Secrets and sensitive files — .env, private keys, credential files. These should never leave your machine in the first place, regardless of context size.

Project structure and file paths, on the other hand, are worth keeping even when you trim contents — a directory tree costs very little context and gives the model a map of how the pieces relate, which noticeably improves its suggestions even without every file included.

Context and token limits, practically

Every model has a context window — a hard ceiling on how much text it can consider at once, measured in tokens rather than characters or files. Getting close to that ceiling causes two separate problems: hitting the wall entirely, where the request simply fails, and a subtler quality drop that can show up well before the hard limit, where the model starts losing track of details buried in the middle of a very long context.

In practice, checking an estimated token count before pasting context into Claude, ChatGPT, or Gemini is worth the ten seconds it takes — it's much faster to trim a file or two upfront than to debug why a model's response ignored something you gave it.

When to use a GitHub/GitLab workflow vs. a local workflow

The right approach also depends on where your code actually lives:

• If the project is already hosted on GitHub or GitLab, working directly from the repo URL saves you a clone step — you can select files straight from the hosted file tree. See preparing a GitHub repository for AI.
• If the project is a local folder, a downloaded ZIP, or something that hasn't been pushed anywhere, a local workflow is the more direct path. See preparing a local codebase for AI.

The bottom line

There's no universal right amount of context — the useful question isn't "how much code" but "which files does this specific task actually depend on." Start narrow, keep the project structure visible even when you trim contents, and expand to full-project context only when the task genuinely spans the whole codebase rather than by default.