NotebookLM for software engineering: the research brain that doesn’t run code for you

When a general-purpose LLM can’t find a solid answer in its training data, it doesn’t tell you “I don’t know”. It makes one up.

FRANK LACROIX
Software Engineer

I’ve spent the last couple of months using NotebookLM for software engineering almost every day, mostly for technical research before touching a single line of code. I work as a backend engineer on a data platform project for one of Orbitant’s clients, and I started out with the tool the way everybody does: summarising a PDF, generating a quick podcast. Two months later, I had a full library of specialised notebooks, expert roles that debate each other, and a side project — Symposium — that wires all of it up to Claude and Cursor.

This isn’t a generic guide to what NotebookLM is. It’s the path that took me from playing with it out of curiosity to making it a real part of my engineering workflow, including what works and the limits I ran into along the way.

Why NotebookLM doesn’t hallucinate the way ChatGPT or Claude do

The real difference is the knowledge model. A general-purpose LLM — ChatGPT, Claude, Perplexity, whichever you use — is trained on practically the entire public web. When you ask it something and it has no solid ground to stand on, it infers. And when it infers without finding anything consistent, it hallucinates: it fills the gap with something that sounds plausible even when it isn’t.

NotebookLM, powered by Gemini, flips that logic. Instead of starting from the whole internet, you build your own base of verified sources, not far from how you build a context system that feeds back on itself over time, except the focus here is on avoiding hallucinations. It accepts several formats:

• PDFs, Google Docs documents and spreadsheets
• Audio and YouTube videos
• CSV and Markdown files
• Full web URLs

Each source takes up to 500,000 words, and a single notebook holds 50 sources on the free tier, 300 on Premium and 600 on Ultra. On top of that it builds a system that anchors every answer to verifiable citations inside your own sources: if the answer comes from a source, it cites the document and the exact paragraph; if it has to infer something outside those sources, it tells you that explicitly too. It doesn’t eliminate hallucinations a hundred per cent, but it dramatically reduces the tendency to make things up — I’ve checked by firing the same technical question at other assistants in parallel.

There are two ways to fill a notebook: upload the sources by hand when you already know they’re trustworthy, or use Fast Research, a natural-language search that crawls the web and proposes curated sources automatically. For something deeper, there’s Deep Research, a slower but far more exhaustive scan.

Once the notebook is populated, the central panel is a chat where you query all the sources at once, and the studio panel generates summaries, infographics, mind maps, timelines, flashcards, quizzes, and even two-voice debate-style podcasts, a lot more natural-sounding than I expected.

NotebookLM for software engineering: curated notebooks and expert roles

Over time, I built up notebooks curated by technology: Node.js backend, Node.js frontend, TypeScript, Redis, SQL Server, RabbitMQ, among others. In each one, I’m picky about the sources: official documentation, technical books, and reference articles — no random blogs. On top of those notebooks, I create what NotebookLM calls personas, or roles: Backend Engineer, System Architect, Frontend Engineer, Data Engineer.

Each persona consults its curated sources and nothing else, and has no context about the repository I’m working in. That’s deliberate, because this doesn’t replace Claude or Cursor. It’s a council of experts I consult before running anything.

My workflow with one of these experts usually looks like this:

1. I ask a general question and keep drilling down until I hit the specific pain point.
2. I ask for a definitive summary of the answer.
3. I save that summary as a note: NotebookLM stores it in Markdown, ready to reuse.
4. I turn the note into a new source in the notebook itself, or paste it straight into the prompt I hand to Claude or Cursor.

NotebookLM doesn’t run code or solve tasks for you: it’s the reasoning engine that gets me to Claude or Cursor with the context already chewed over. That nuance is what separates using it as a toy from using it as a real piece of the workflow.

The same pattern works outside software engineering: a law firm can curate the constitution and the civil code and spin up a corporate lawyer role, and a product team can turn Jira tickets into specs narrated with voice and video. The logic — verified sources first, reasoning second — is the same in any industry.

The gap NotebookLM doesn’t cover: no API, no MCP

The real blocker I hit is that NotebookLM has no public API and no official MCP server, the protocol we already use to connect agents in other projects. There’s no direct programmatic connection to Claude, Cursor, or any other agent. In practice, that meant copy-pasting between tabs constantly: ask in NotebookLM, copy the answer, paste it into Claude, repeat.

To plug that gap I built a side project — still a proof of concept — that I call Symposium. The architecture has several layers, but the idea is simple:

• Alejandría is the master index: it has no sources of its own, its sources are the other notebooks. Right now it indexes twelve.
• Ágora is the set of expert roles — Backend Engineer, System Architect, Data Engineer, among others — that consult Alejandría and debate each other, always citing their source.
• Pitágoras is the meta-expert: when a question crosses several domains, it decides which Ágora expert to consult and synthesises the final answer.
• Campus is the interface where I write the message and see the chat shared between Claude, Cursor and the Ágora roles.

Underneath runs an MCP gateway built with FastMCP that exposes a single connection point so Claude, Cursor, and the Ágora roles can talk to each other without configuring a separate MCP server for each one. RabbitMQ routes the messages onto the bus, and Redis keeps session state in real time. So I don’t lose the context of a half-finished session; I version the conversations with Git: every session is recorded with its hash and title in a separate repository — with its own .gitignore — that lives inside the project without mixing with production code.

All of this runs behind the scenes on Playwright, because today there’s no other way to automate NotebookLM: they’re Python libraries emulating an MCP server on top of an interface designed for humans, not for programs.

When orchestrating several AI agents is worth it (and when it isn’t)

Symposium isn’t free — not in time and not in complexity, and before anyone gets the itch to build something similar, I’d rather be clear about what I actually gain and what it costs me to keep it running. These are the upsides I notice day-to-day:

• One message, several formats: I write it once, in natural language, and my own templating language — MPL, Metaprompt Language — translates it into the format each model understands best, much like we used Jinja templates to render HTML.
• Selective addressing: I aim the message at a single agent — Claude, Cursor or Pitágoras — or broadcast to all of them, and each one answers in the same shared thread.
• Persistent sessions: I don’t lose the thread between a Friday and a Monday, because every session is versioned.

Here’s what it costs to keep it going:

1. Tokens on broadcast: the NotebookLM research runs on my free Google account, so those are tokens I save Claude and Cursor. But on broadcast the cost multiplies: you pay for Cursor tokens, Claude tokens and any other agent hooked into the bus.
2. Interface latency: everything runs on a human-facing interface via Playwright. For a three-second task — renaming a variable, tracking down a one-off error — there’s no point spinning up this circuit; for that I use Claude or Cursor directly.
3. More layers to maintain: gateway, message bus, session cache and versioning are all pieces that have to keep working at the same time.

I save Symposium for tasks that would otherwise take me three or four hours, like the certificate automation I’m in the middle of right now, where the documentation is scattered and has to be synthesised properly first.

Symposium is in alpha. LangGraph is already installed as the orchestrator, though it doesn’t handle full autonomy yet — agents deciding and executing without asking permission — and I’m in no rush: I’d rather each agent propose, and I authorise, while the project matures. The next step is cleaning up the repository and sharing it inside Orbitant, so anyone can build their own library of curated notebooks. It works just as well for a law firm as for software engineering; the only thing that changes is the sources you curate.

Frequently asked questions

Does NotebookLM have an official API for connecting it to other AI agents?
No. As of today there’s no public API and no official NotebookLM MCP server. Any integration, Symposium included, goes through automating the web interface with tools like Playwright.

How many sources does a notebook take?
The free tier accepts up to 50 sources per notebook, Premium up to 300 and Ultra up to 600, with a limit of 500,000 words per source.

Can NotebookLM replace Claude or Cursor for writing code?
No, and that isn’t its purpose. NotebookLM reasons over verified sources and hands you context, but it doesn’t run code. Execution still sits with tools like Claude or Cursor.