Friday Triage in a 200-File Repository

A 200-file repository is not a 200-file conversation

At 9 a.m. on release day, a developer may ask an AI assistant to find the cause of a failing checkout test in a repository containing 200 files. It is tempting to assume the assistant can read the whole project at once. Usually, that is the wrong mental model.

A context window is the amount of text an AI model can consider during one interaction. That text includes your instructions, files or file sections you provide, tool results, previous messages, and the model’s planned response. The limit is measured in tokens rather than files. A token is a small piece of text; source code, long names, logs, and JSON can use tokens faster than ordinary prose.

What the context window counts during a coding task

Imagine an assistant with a context window of 100,000 tokens. That number is not a 100,000-token allowance reserved only for your source code. Your prompt might use 1,000 tokens, a directory listing 3,000, several files 60,000, tool output 20,000, and the response another 8,000. The total is already close to the limit.

Some systems also keep room for future tool calls or the next response. In practice, the useful working space is smaller than the headline number. A large context window helps, but it does not make an entire repository equally visible or equally understandable.

Why 200 files can exceed a generous context window

File count tells you very little about repository size. A small service may have 200 compact files and fit comfortably in a window. A frontend with generated bundles, lockfiles, fixtures, snapshots, migrations, and large test data may exceed it several times over.

As a rough illustration, 200 files averaging 500 lines creates 100,000 lines. Even when many lines are short, that can represent hundreds of thousands of tokens. Reading everything also creates a quality problem: the model must spend attention on unrelated code, which makes it harder to trace the few files that control the bug.

What an assistant can see when the repository is too large

Modern coding tools do not always paste the entire repository into one prompt. They can list files, search for symbols, open selected ranges, inspect references, and run tests. This is closer to how a developer works: start with a map, form a hypothesis, then inspect the relevant paths.

The assistant may therefore have access to the repository without holding every file in its active context. A file that was viewed earlier can also fall out of the current working conversation, especially after many tool calls. Ask for fresh excerpts when accuracy depends on exact code.

A practical review sequence for the 200-file checkout codebase

• Start with the project map: top-level directories, package manifests, build scripts, and test commands.
• State one task clearly, such as “trace the failed checkout request from the route to the database write.”
• Search for the error message, endpoint, class, or test name before opening broad directories.
• Read the main path first: the failing test, entry point, service, data layer, and configuration it directly uses.
• Exclude generated files, dependency directories, lockfiles, compiled assets, and unrelated documentation unless the evidence points there.
• After each meaningful discovery, ask for a short summary of files inspected, assumptions, and open questions.
• Run a focused test or static check before expanding the investigation to neighboring modules.

How to make context useful instead of merely large

Give the assistant a target, constraints, and a definition of done. “Review this repository” is vague. “Find why the checkout test returns a 500 after address validation; identify the responsible function and propose a minimal patch” directs attention toward a manageable slice.

Use staged conversations for large tasks. One pass can map architecture, another can investigate authentication, and a third can review the proposed change. Carry forward concise summaries rather than repeatedly pasting every file. This reduces noise and leaves room for tests, diffs, and reasoning.

Choosing a model and relay for repository work

For long investigations, choose a model with a context window that matches your largest expected tool result, not merely your average prompt. Claude Sonnet 5.5 can be a practical choice for codebase reasoning, while smaller tasks may not need the largest available window.

RelayVano provides pay-as-you-go access to models through Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs at https://api.relayvano.com. If you want to test this workflow across models without committing to a fixed plan, sign up for RelayVano and start with a focused repository task.

The useful question at the deadline

When a 200-file repository feels too large, do not ask only whether it fits. Ask whether the assistant has the right files, enough history to connect them, and enough remaining space to produce and verify a useful answer. Context windows are working budgets. Good repository analysis comes from spending that budget on evidence that changes the decision.