Start Gemini 3.1 Pro with one repository question
A large codebase is less intimidating when you approach it with a specific question. Instead of asking Gemini 3.1 Pro to explain everything, start with something concrete: where does a login request go, what writes an invoice, or which module loads application settings?
Think of the model as a reading partner, not an authority on your repository. It can help organize the code you provide and suggest connections worth investigating. Its answers still need evidence from the files, especially when behavior depends on configuration, generated code, or external services.
Build a small repository map before sharing source
Your first input should establish the shape of the project. Include the top-level directory tree, the main documentation, and the files that declare dependencies. Add application entry points if you know them. Avoid dumping every file into the conversation immediately.
Exclude secrets, private keys, customer data, build outputs, and dependency directories. Check your organization's rules before sending proprietary code to any external service. A configuration example with sensitive values removed is usually more useful than a real environment file.
Try this opening request:
Read this directory tree, project documentation, and dependency configuration. Identify likely application entry points, major modules, and test locations. Separate confirmed facts from guesses. List the next files you need to investigate the login flow.
Give Gemini 3.1 Pro a connected slice of code
A connected slice means the files involved in one behavior. For login, that might include a route, its handler, the authentication service, the user data model, and relevant tests. Keeping these together gives the model useful relationships rather than a pile of unrelated source files.
If your tool supports repository search and file reading, ask it to locate those files first. If you are working through a chat interface or SDK without file tools, provide the contents yourself. The model does not automatically have access to your working directory.
- Label each pasted file with its repository path.
- Include the configuration that selects the active implementation.
- Keep related tests beside the implementation they exercise.
- Ask which missing files could change the explanation.
Trace one request from entry point to side effect
Once the relevant files are available, ask for a step-by-step trace. You want to understand what calls what, where decisions happen, and which operations change state.
Trace a successful login from the route to the response. Name each function and file involved. Explain validation, database access, session creation, and error handling. Cite file paths and symbols for every step. Mark any connection you cannot confirm from the supplied code.
Request line numbers only when the tool provides reliable numbered source. Otherwise, file paths and function names are better anchors. If an answer mentions a function you cannot find, stop and investigate rather than building the next explanation on it.
Check the explanation against tests and runtime choices
A plausible trace is not proof. Open the cited files and follow the calls yourself. Check whether dependency injection, feature flags, environment settings, or framework conventions select a different implementation.
Then ask Gemini 3.1 Pro which existing tests support the trace and which branches remain unverified. Run relevant tests using the project's documented commands in an appropriate local environment. Passing tests support specific expectations; they do not establish that the entire explanation is correct.
Use SwiftRelay for a focused first reading session
If you want to access Gemini 3.1 Pro through a relay, SwiftRelay offers per-token billing and works with Gemini CLI and OpenAI-compatible SDKs. Gemini CLI takes the bare host https://api.fastapirelay.com; OpenAI-compatible SDKs use https://api.fastapirelay.com/v1. Authentication and model selection still need the appropriate client configuration.
Sign up for SwiftRelay to use the small gift credit available to new accounts on a focused repository-reading session. Start with one question and a limited set of files rather than repeatedly sending the entire repository.
Finish your first lap with a short, verified note: the entry point, the main call chain, the important tests, and the remaining unknowns. That note becomes your starting map for the next feature you explore.