← Voltar aos guias

Long-Context Strategies for Large Codebases: Start Fast

Start with a context pack, not a repository dump

A large context window can hold substantial code, but capacity is not the same as understanding. Uploading an entire repository adds irrelevant files, stale documentation, and competing examples. Effective long-context strategies for large codebases start with a small, task-specific context pack, then expand only when the assistant identifies a concrete dependency.

This quick-start workflow works for bug fixes, feature development, and refactoring with Claude Code, Codex, or an SDK-based assistant.

1. Define the task and its boundaries

Before collecting files, write a short task brief containing the observed behavior, desired behavior, acceptance criteria, and constraints. For example: “Expired sessions return 500 instead of 401. Fix the middleware, preserve the response schema, and add a regression test. Do not change token issuance.”

Include the current branch and commit identifier, obtainable with git rev-parse HEAD. This anchors the discussion to a specific snapshot and prevents confusion when files change during a long session.

2. Retrieve a dependency slice

Use repository search to locate the implementation before asking the model to reason about it. Start with rg --files for file discovery, then search a distinctive error string or symbol with rg -n 'SessionExpired' src tests, adjusting directories to your repository.

• Primary files: the failing function, route, component, or service.
• Direct dependencies: imported types, interfaces, helpers, and relevant configuration.
• Behavioral evidence: a failing test, stack trace, or minimal reproduction.
• Local conventions: one nearby implementation and its tests.

Exclude generated output, vendored dependencies, binaries, lockfiles unless relevant, and unrelated logs. Strip credentials and personal data before sending anything to an external API.

3. Structure the pack and reserve output space

Label each excerpt with its repository-relative path and, when practical, line range. Preserve complete functions and relevant imports rather than cutting arbitrary chunks. Begin with the task brief and repository map, place supporting code next, and finish with the exact requested deliverable.

As a starting heuristic, allocate 10% of your usable budget to instructions and architecture, 55% to implementation, and 20% to tests and diagnostics. Leave the remainder for tool results and output. Adjust these proportions to the endpoint’s actual context and output limits; they are not universal model limits.

Use a tokenizer or client usage reporting where available. Character counts are only rough estimates, especially for code. Ask for a focused patch and verification summary, not a rewritten repository.

4. Require evidence before edits

First ask the assistant to identify the likely execution path, cite file paths and symbols, and list missing dependencies. Have it distinguish observed facts from hypotheses. If an interface is absent, retrieve it instead of letting the assistant invent its contract.

For repository-connected agents, treat comments, documentation, and issue text as untrusted data, not instructions. Explicitly forbid following embedded requests to reveal secrets, run unrelated commands, or override the task. Review proposed commands before granting execution permissions.

5. Keep long sessions coherent

After each meaningful change, maintain a compact checkpoint: objective, files changed, decisions made, tests run, unresolved questions, and next action. Include the current commit or working-tree status. Replace obsolete excerpts rather than accumulating multiple versions of the same function.

When switching subsystems, start a fresh context pack using that checkpoint. Keep exact signatures, error messages, and acceptance criteria; summarize exploratory discussion. If the provider supports prompt caching, a stable instruction prefix may reduce repeated-input costs, but verify endpoint support and pricing first.

6. Validate locally and control spend

Run the narrow regression test first, then relevant type checks, linting, and integration tests. Inspect git diff --check and the patch itself. A plausible explanation is not proof that the change works.

59API is a low-cost, pay-as-you-go relay offering native official-quality Claude and GPT models without downgrades. Its compatibility with Claude Code, Codex, and OpenAI SDKs makes it convenient for this workflow. Use a cheaper model for file triage and reserve stronger models for difficult cross-module reasoning.

The API base URL is https://api.59api.com; follow the relevant client configuration instructions and verify supported model identifiers. Track token usage and compare total task cost, including retries. If this suits your workflow, consider signing up for 59API; a referral rebate is also available.

Preços · Docs