Reduce repeated Agent scans with a code map

One-sentence takeaway

This post records the author's experience using Gemini 3.8 Flash in Antigravity 2.0, where the model repeatedly read the same files, consumed a large amount of quota, and damaged the code. A comment offers a reusable mitigation workflow: maintain a small code knowledge base first, then use the code map to locate the relevant feature and implementation files, instead of rescanning the entire repository for every prompt.

Use cases

• Suitable tasks: Locating code in medium-to-large repositories, making incremental changes, pre-test checks, and coding Agent work that requires controlling the amount of context read.

• Prerequisites: The Agent must have permission to read from and write to the repository and run tests; knowledge-base files should be maintained alongside the code.

• Unsuitable tasks: Direct modification in a production environment without testing or rollback capabilities; community comments should also not be treated as an official guarantee of Gemini 3.8 Flash's behavior.

• Applicable model and client: The original post uses Gemini 3.8 Flash in Antigravity 2.0; it does not disclose a public API model ID, thinking level, temperature, context configuration, or complete system prompt.

Ready-to-use content

1. Code knowledge-base workflow (organized from the comment text, with constraints preserved)

The commenter GrillePainVert described the following approach; this is a workflow shared by the commenter, not an official solution verified by the original poster:

Have the Agent build a knowledge base for the code, with each knowledge-base file no longer than 200 lines.

The knowledge base should contain:
- A code map
- Architecture files
- Feature files
- Links between features and the code files that actually implement them

Always start searches from the knowledge base.

Continuously build or update the knowledge base during the work.

For each new discussion, first analyze the code map, then the feature files referenced by the code map, and finally only the relevant portions of the actual code files.

Its minimal execution order is:

Code map → relevant feature summary → relevant implementation excerpt → modification and testing → write back to the knowledge base

2. Input constraint for JSON responses (comment text)

Another commenter, Chemical_Hawk_6307, provided this actual input:

Do not search, list directories, write, or request sandbox bypass.

The comment said this instruction was used for a simple task that asked Gemini 3.8 Flash to return JSON in a sandbox; the original comment did not disclose a JSON schema or complete user input, so it cannot be expanded into a more complete API prompt.

Input–output cases

Case A: Knowledge-base workflow

• Input: A medium-to-large code repository requiring a feature to be located and modified, along with the code map, architecture summary, and feature summary above.

• Expected process: First search the knowledge base, read only the relevant implementation through its links, then modify, test, and update the knowledge base.

• Effect claimed by the commenter: It can reduce repeated scanning and token consumption; the original comment gives no savings percentage, repository size, test log, or independent retest.

Case B: Strict JSON sandbox task

• Input: A request for the model to return JSON, with explicit instructions not to search, list directories, write files, or request a sandbox-permission bypass.

• Result recorded in the comment: The model did not return JSON directly. Instead, it began searching and repeatedly ran pwd / attempted to list directories.

• Visible problem: The constraints were not followed; the comment did not show the model's complete output, JSON schema, runtime environment, or request logs.

Results of the coding tasks in the original post

The original poster said they tested Gemini 3.8 Flash in Antigravity 2.0:

1. Windows display-control application: The model was asked to audit bugs, fix them, and test; the author said it found some issues, but some fixes failed, testing was insufficient, and the application still crashed silently.

2. Three.js game: The model was asked to use existing assets to add a set of simple features and test again; the features were mostly added, but the author considered the code quality poor, said reusable parts were not extracted, and soon found a game bug.

3. Deployment/migration tool: The model was first asked to propose enhancements, after which the author selected the projects to implement; after implementation, the model began testing, but the author soon saw anomalies in the logs.

The author also said that a single task once consumed about 93% of five hours of Google AI Pro usage. They then switched back to Gemini 3.7 Flash and felt that it was faster and produced usable results in the same attempt. This is one user's subjective report, not a controlled benchmark.

Testing/workflow steps

1. In a branch or sandbox that supports rollback, create a code-map, architecture summaries, and feature summaries, keeping each knowledge-base file to no more than 200 lines.

2. Link each feature summary to the actual implementation files, test files, and key entry points; update links promptly when they become invalid.

3. For each new Agent task, first require it to read the code map and relevant feature summary, then open only the necessary implementation excerpts.

4. For modification tasks, explicitly state the test commands, pass conditions, and stop conditions; do not merely write “please test.”

5. If the Agent repeatedly reads the same file, keeps running commands, or drifts from the objective, stop the current session and restart from the knowledge-base summaries to avoid further quota consumption.

6. After tests pass, write newly added structure and decisions back to the knowledge base; retain the diff, logs, and failure records to make the next investigation easier.

Applicability boundaries and verification notes

• “A code knowledge base can save a large number of tokens” is the commenter's experiential judgment. No before-and-after token measurements were published, so it cannot be extrapolated into a fixed benefit.

• The original post describes only the client experience in Antigravity 2.0. It does not disclose Gemini 3.8 Flash API-call parameters, a snapshot, the complete system prompt, tool schema, or retry strategy.

• The original poster's reports of “93% usage,” “silent crashes,” “repeated reads,” and “success after switching back to 3.7” all come from a single session's subjective record. There is no repository, log, or independent reproduction material, so they cannot support a claim that the model generally fails.

• The JSON case exposes only a short constraint and a failure symptom. It does not disclose the complete input, expected schema, raw response, or sandbox-permission configuration; anyone reproducing it must fill in those details independently.

• Use this only in repositories and test environments you are authorized to access. A knowledge base may contain internal architecture, paths, or security information, so redact it before sharing. Do not put API keys, tokens, user data, or production credentials in the knowledge base.

• A code map is not a fact-checking mechanism and cannot replace testing, code review, rollback, or human approval; this serves a different purpose from the already collected agy_help four-tier fact-checking Agent.

Source excerpt or observation (compliance short quote only)

The commenter summarized the workflow as: first analyze the code map, then the feature files it points to, and finally only the relevant portions of the relevant code files. The value of this sequence is that it limits the reading scope; however, the original post provides no reproducible experiment showing whether it improves Gemini 3.8 Flash's actual success rate.