NotebookLM para ingeniería de software: el cerebro de investigación que no ejecuta código por ti

Cuando un LLM genérico no encuentra una respuesta sólida en su entrenamiento, no te dice «no lo sé». Se lo inventa.

FRANK LACROIX
Software Engineer

Llevo un par de meses usando NotebookLM para ingeniería de software casi a diario, sobre todo para investigación técnica antes de tocar una sola línea de código. Trabajo como backend engineer en un proyecto de plataforma del dato para uno de los clientes de Orbitant y empecé a usar la herramienta como cualquiera: para resumir un PDF o generar un podcast rápido. Dos meses después tenía una librería completa de cuadernos especializados, roles expertos que debaten entre sí y un proyecto personal —Symposium— que conecta todo eso con Claude y Cursor.

Esto no es una guía genérica sobre qué es NotebookLM. Es el recorrido que me llevó de usarlo como curiosidad a integrarlo en mi flujo de trabajo de ingeniería, con lo que funciona y con los límites que me fui encontrando por el camino.

Por qué NotebookLM no alucina como ChatGPT o Claude

La diferencia de fondo está en el modelo de conocimiento. Un LLM genérico —ChatGPT, Claude, Perplexity, el que uses— está entrenado sobre prácticamente toda la web pública. Cuando le preguntas algo y no tiene una base sólida para responder, infiere. Y cuando infiere sin encontrar nada consistente, alucina: rellena el vacío con algo que suena plausible aunque no lo sea.

NotebookLM, potenciado por Gemini, invierte esa lógica. En vez de partir de todo internet, construyes tu propia base de fuentes verificadas, algo parecido a cómo se construye un sistema de contexto que se retroalimenta con el tiempo, aunque aquí el foco esté en evitar alucinaciones. Acepta varios formatos:

• PDFs, documentos de Google Docs y hojas de cálculo
• Audio y vídeos de YouTube
• CSV y archivos Markdown
• URLs web completas

Cada fuente admite hasta 500.000 palabras y un mismo cuaderno acepta 50 fuentes en la versión gratuita, 300 en Premium y 600 en Ultra. Con eso arma un sistema que ancla cada respuesta a citas verificables dentro de tus propias fuentes: si la respuesta sale de una fuente, te cita el documento y el párrafo exacto; si tiene que inferir algo fuera de esas fuentes, también te lo dice explícitamente. No elimina las alucinaciones al cien por cien, pero reduce muchísimo la tendencia a inventarse cosas: lo he comprobado lanzando la misma pregunta técnica en paralelo a otros asistentes.

Para poblar un cuaderno hay dos caminos: cargar las fuentes a mano cuando ya sabes que son fiables, o usar Fast Research, una búsqueda en lenguaje natural que rastrea la web y propone fuentes curadas automáticamente. Para algo más profundo está Deep Research, un escaneo más lento pero más exhaustivo.

Con el cuaderno poblado, el panel central es un chat donde preguntas sobre todas las fuentes a la vez y el panel de estudio genera resúmenes, infografías, mapas mentales, líneas de tiempo, flashcards, quizzes y hasta podcasts en formato debate a dos voces, bastante más naturales de lo que esperaba.

NotebookLM para ingeniería de software: cuadernos curados y roles expertos

Con el tiempo me creé cuadernos curados por tecnología: Node.js backend, Node.js frontend, TypeScript, Redis, SQL Server, RabbitMQ, entre otros. En cada uno cuido las fuentes: documentación oficial, libros técnicos y artículos de referencia, nada de blogs al azar. Sobre esos cuadernos, creo lo que NotebookLM llama personas o roles: Backend Engineer, System Architect, Frontend Engineer, Data Engineer.

Cada persona consulta exclusivamente sus fuentes curadas y no tiene contexto del repositorio en el que estoy trabajando: a propósito, porque esto no reemplaza a Claude ni a Cursor. Es un concilio de expertos al que consulto antes de ejecutar nada.

Mi flujo con uno de estos expertos suele ser así:

1. Hago una pregunta general y voy haciendo drill-down hasta el punto de dolor concreto.
2. Pido un resumen definitivo de la respuesta.
3. Guardo ese resumen como nota: NotebookLM la guarda en Markdown, lista para reutilizar.
4. Convierto la nota en una nueva fuente del propio cuaderno, o la copio directamente en el prompt que le paso a Claude o Cursor.

NotebookLM no ejecuta código ni resuelve tareas por ti: es el motor de razonamiento que me ayuda a llegar a Claude o Cursor con el contexto ya masticado. Ese matiz es el que marca la diferencia entre usarlo como un juguete y usarlo como una pieza real del flujo de trabajo.

El mismo patrón funciona fuera de la ingeniería de software: un despacho legal puede curar la constitución y el código civil y crear un rol de abogado corporativo y un equipo de producto puede convertir tickets de Jira en especificaciones narradas con voz y vídeo. La lógica —fuentes verificadas primero, razonamiento después— es la misma en cualquier industria.

El hueco que no cubre NotebookLM: no tiene API ni MCP

El bloqueo real con el que me encontré es que NotebookLM no tiene una API pública ni un servidor MCP oficial, el protocolo que ya usamos para conectar agentes en otros proyectos. No hay conexión programática directa con Claude, Cursor o cualquier otro agente. En la práctica, eso significaba copiar y pegar constantemente entre pestañas: preguntar en NotebookLM, copiar la respuesta, pegarla en Claude, repetir.

Para tapar ese hueco monté un proyecto personal —todavía una prueba de concepto— que llamo Symposium. La arquitectura tiene varias capas, pero la idea es sencilla:

• Alejandría es el índice general: no tiene fuentes propias, sino que sus fuentes son los demás cuadernos. Ahora mismo indexa doce.
• Ágora son los roles expertos —Backend Engineer, System Architect, Data Engineer, entre otros— que consultan Alejandría y debaten entre sí citando siempre su fuente.
• Pitágoras es el metaexperto: cuando una pregunta cruza varios dominios, decide a qué experto de Ágora consultar y sintetiza la respuesta final.
• Campus es la interfaz donde escribo el mensaje y veo el chat compartido entre Claude, Cursor y los roles de Ágora.

Por debajo corre un gateway MCP construido con FastMCP que expone un único punto de conexión para que Claude, Cursor y los roles de Ágora hablen entre sí, sin configurar un servidor MCP distinto para cada uno. RabbitMQ enruta los mensajes al bus y Redis mantiene el estado de la sesión en tiempo real. Para no perder el contexto de una sesión a medias, versiono las conversaciones con Git: cada sesión queda registrada con su hash y título en un repositorio separado —con su propio .gitignore— que vive dentro del proyecto sin mezclarse con el código de producción.

Todo esto corre por detrás con Playwright, porque hoy no existe otra forma de automatizar NotebookLM: son librerías en Python que emulan un servidor MCP sobre una interfaz pensada para humanos, no para programas.

Cuándo merece la pena orquestar varios agentes de IA (y cuándo no)

Symposium no sale gratis ni en tiempo ni en complejidad y, antes de que a nadie le entren ganas de montar algo parecido, prefiero ser claro sobre qué gano realmente y qué me cuesta mantenerlo. Estas son las ventajas que noto en el día a día:

• Un solo mensaje, varios formatos: lo escribo una vez, en lenguaje natural, y mi lenguaje de plantillas propio —MPL, Metaprompt Language— lo traduce al formato que mejor entiende cada modelo, parecido a cómo usábamos las plantillas Jinja para renderizar HTML.
• Direccionamiento selectivo: dirijo el mensaje a un solo agente —Claude, Cursor o Pitágoras— o hago un broadcast a todos y cada uno responde en el mismo hilo compartido.
• Sesiones persistentes: no pierdo el hilo de un viernes a un lunes porque cada sesión queda versionada.

Esto es lo que cuesta mantenerlo:

1. Tokens en broadcast: la investigación en NotebookLM la pago con mi cuenta gratuita de Google, así que son tokens que le ahorro a Claude y a Cursor. Pero en broadcast el coste se multiplica: pagas tokens de Cursor, de Claude y de cualquier otro agente conectado al bus.
2. Latencia de interfaz: todo corre sobre una interfaz pensada para humanos vía Playwright. Para una tarea de tres segundos —renombrar una variable, localizar un error puntual— no tiene sentido montar este circuito; ahí uso Claude o Cursor directamente.
3. Más capas que mantener: gateway, bus de mensajes, caché de sesión y versionado son piezas que hay que mantener funcionando a la vez.

Reservo Symposium para tareas que de otro modo me llevarían tres o cuatro horas, como la automatización de certificados en la que estoy metido ahora, con documentación dispersa que primero hay que sintetizar bien.

Symposium está en fase alfa. LangGraph ya está instalado como orquestador, aunque todavía no gestiona la autonomía completa —que los agentes decidan y ejecuten sin pedir permiso—, y no tengo prisa: prefiero que cada agente proponga y yo autorice mientras el proyecto madura. El siguiente paso es limpiar el repositorio y compartirlo dentro de Orbitant, para que cualquiera monte su propia librería de cuadernos curados: sirve igual para un despacho de abogados que para ingeniería de software, solo cambian las fuentes que curas.

Preguntas frecuentes

¿NotebookLM tiene una API oficial para conectarlo con otros agentes de IA?
No. A día de hoy no existe una API pública ni un servidor MCP oficial de NotebookLM. Cualquier integración, como Symposium, pasa por automatizar la interfaz web con herramientas como Playwright.

¿Cuántas fuentes admite un cuaderno?
La versión gratuita acepta hasta 50 fuentes por cuaderno, la Premium hasta 300 y la Ultra hasta 600, con un límite de 500.000 palabras por fuente.

¿NotebookLM puede sustituir a Claude o Cursor para escribir código?
No, y no es su propósito. NotebookLM razona sobre fuentes verificadas y te entrega contexto, pero no ejecuta código. La ejecución sigue recayendo en herramientas como Claude o Cursor.