NotebookLM and Antigravity: Bringing Research Into Your Code Workflow

NotebookLM and Antigravity serve different parts of a technical workflow: NotebookLM (now Gemini Notebook) is built for organizing and questioning research sources, while Antigravity is a code-focused environment. There is no native connection between them, but the gap between a research finding and a working development brief does not need a built-in integration to close.

Tools like fenbs can hold the selected findings and the development decisions that connect research to code, so the context does not get lost when you move between apps.

What each tool does

NotebookLM, renamed Gemini Notebook in July 2026, lets you upload sources such as PDFs, web pages and documents, then ask questions about them. It synthesizes answers from your own material rather than general training data, which makes it useful for reviewing specs, papers or reference documentation before writing code.

Antigravity is an AI-assisted coding environment. The two tools sit on opposite sides of a common research-to-implementation gap: you build understanding in one place and write the solution in another.

Neither tool imports sessions from the other. What you confirmed in NotebookLM does not appear automatically in Antigravity. Bridging that gap is a deliberate manual step.

Why the gap matters for coding work

When you research an unfamiliar API, a regulatory requirement or a third-party data format in NotebookLM, you come away with decisions: which endpoint to use, which fields are required, which edge cases matter. Those decisions need to reach your coding environment.

Without a deliberate handoff, the decisions stay in the research session. A few hours later when you are writing code, you may not remember the exact constraint you read. Worse, if a colleague or an AI assistant picks up the task, they have no record of what was already established.

For related context on alternative research tools, see notebooklm alternatives. For how NotebookLM compares with Claude Projects as a research tool, see claude projects vs notebooklm.

A concrete example: research before building

Say a two-person team is building an integration with an external API. One developer uploads the API documentation to NotebookLM and asks which authentication method the vendor recommends, what rate limits apply to their plan and whether webhooks are required for their specific use case. NotebookLM synthesizes answers from those documents.

The developer comes away with three confirmed decisions: use OAuth 2.0 rather than API keys, the rate limit is 100 requests per minute, and webhooks are optional for their flow. Those three facts need to reach the coding environment before any code is written.

Without a handoff, the next developer who opens Antigravity asks the AI assistant about the same API. The assistant gives a reasonable answer from its training data, which may not match the specific version of the API the team is working with. A written record of what was confirmed in research prevents that mismatch.

Writing a handoff record from research findings

The most direct path is to write a concise brief before switching tools. After your NotebookLM session, open a plain document or a project record and write down:

• The question you were answering and the conclusion you reached.
• Any constraints or requirements the research confirmed.
• Links to the specific sources that support each decision.
• What remains uncertain and would need a follow-up check.

Keep it short enough to read in under a minute. Its job is to give your coding environment, and any AI assistant inside it, the facts it needs to proceed without reopening every source.

Keeping sources and the development brief in one place

A common problem is that the handoff record and the sources end up in different places: notes in a chat, sources in NotebookLM, decisions in someone's memory. The next session has to reconstruct the picture from scratch.

Keeping the record with the task it belongs to solves this. When the task record holds the key decisions from research, the links to the sources that support them and the open questions, whoever picks up the work next can read one record instead of searching across three tools.

An AI assistant that reads the decision record before writing code starts with the constraints already in scope. It does not need to ask which endpoint to use or which fields are optional; those answers are already in the project record.

How to do this with fenbs

1. Create a free account and add the project the research belongs to.
2. After your NotebookLM session, add the confirmed decisions to Decisions and rules. Include the reason and the source that supports each one.
3. Add links to the key sources under Links and listings, with a note on what each one establishes.
4. Record any open questions as task notes or in Where we left off, so the next session knows what still needs checking.
5. Connect a supported AI assistant from Integrations and ask it to read the project context before working on the task.

fenbs does not connect to NotebookLM and does not import your uploaded sources or conversation history. It holds the decisions and links you choose to save, not the raw research.