Claude + Obsidian + NotebookLM: mi pila de investigación de IA

Todos los desarrolladores que conozco tienen el mismo problema: la información está en todas partes y en ninguna. Tus notas están en una aplicación, tu código en otra, tu investigación está repartida en 47 pestañas del navegador y la brillante idea que tuviste el martes pasado está enterrada en un hilo de Slack que nunca volverás a encontrar.

Pasé años probando diferentes herramientas para solucionar esto. Notion, Evernote, Roam, Apple Notes, archivos de texto sin formato en directorios aleatorios. Ninguna de ellas resolvió el problema principal: necesito investigar algo, comprenderlo en profundidad, convertirlo en código y luego documentar lo que he creado, y necesito que esos pasos estén realmente conectados entre sí, en lugar de ser actividades aisladas en aplicaciones aisladas.

Lo que finalmente funcionó fue combinar tres herramientas que se encargan cada una de una parte de ese ciclo: Obsidian para el conocimiento, NotebookLM para la síntesis de la investigación y Claude Code para la ejecución. No están diseñadas para funcionar juntas, pero lo hacen, porque todas operan sobre la misma base: texto sin formato y archivos en el disco.

El problema: fragmentación del contexto

Antes de describir la solución, voy a explicar con detalle qué es lo que no funcionaba.

Estaba investigando una nueva API para un proyecto de un cliente. Leía la documentación en mi navegador, tal vez veía un tutorial en YouTube, descargaba un PDF con ejemplos de arquitectura. Tomaba notas en cualquier aplicación que tuviera abierta. Luego cambiaba a mi editor y comenzaba a programar. Dos horas más tarde, necesitaba consultar algo en la documentación, pero había perdido la pestaña. La nota que había tomado sobre los límites de velocidad estaba en una aplicación diferente a la nota sobre la autenticación. Y tres semanas más tarde, cuando un compañero me preguntó cómo funcionaba la integración, tuve que volver a deducirlo todo de memoria porque mis notas estaban dispersas en cuatro plataformas diferentes.

El término técnico para esto es «coste de cambio de contexto», pero el término práctico es «perder medio día buscando cosas que ya había averiguado».

Lo que necesitaba era:

• Un único lugar para todo el conocimiento que realmente poseo (no la base de datos de un servicio en la nube).
• Una forma de sintetizar fuentes complejas rápidamente sin tener que leer PDF de 50 páginas de principio a fin.
• Una herramienta de ejecución que pueda leer mis notas y actuar directamente sobre ellas.
• Todo conectado, de modo que la investigación fluya hacia las notas, las notas fluyan hacia el código y el código fluya hacia la documentación.

Obsidian: la base de conocimientos

Obsidian se convirtió en la base gracias a tres decisiones arquitectónicas que lo diferencian de todo lo demás.

Markdown primero. Cada nota es un archivo plano .md en tu sistema de archivos. No es una base de datos propietaria. No es un blob JSON almacenado en la nube de otra persona. Son archivos que cualquier editor de texto puede abrir, cualquier herramienta puede procesar y cualquier sistema de control de versiones puede rastrear. Esto es importante porque significa que mi base de conocimientos no está bloqueada en Obsidian. Si la empresa desapareciera mañana, todas las notas que he escrito seguirían estando ahí, en mi disco duro, en un formato universal.

Lo local es lo primero. Nada sale de mi máquina a menos que yo lo envíe explícitamente. Para los proyectos de clientes con código confidencial, diagramas de arquitectura y credenciales de API en mis notas, esto no es opcional, es un requisito. Las herramientas de notas basadas en la nube envían todo a sus servidores, y sus políticas de privacidad cambian a su conveniencia.

Sincronización con Git. Este es el multiplicador. Todo mi almacén de Obsidian es un repositorio Git. Se realiza un seguimiento de cada edición. Puedo ver exactamente lo que añadí a mis notas sobre la API de Stripe el 14 de febrero. Puedo comparar mi comprensión de un sistema entre el mes pasado y hoy. Sincronizo mi MacBook y mi portátil Fedora a través de Git push/pull con mi NAS doméstico. Sin Dropbox, sin iCloud, sin servicios de sincronización de terceros.

El enlace bidireccional es lo que hace que Obsidian sea realmente útil para la gestión del conocimiento, en lugar de solo para el almacenamiento de notas. Cuando creo una nota sobre una API específica, la enlazo a la nota del proyecto, la nota de implementación y la nota de conceptos generales sobre patrones de autenticación. Con el tiempo, estas conexiones forman una red que refleja cómo se relaciona realmente el conocimiento. Encontrar algo tres meses después lleva segundos, en lugar de los 20 minutos de búsqueda del tesoro que solía soportar.

Claude Code: el motor de ejecución

Obsidian almacena y estructura el conocimiento. Pero el conocimiento guardado en una caja fuerte no construye nada. Necesito algo que pueda leer esas notas y convertirlas en código funcional, implementado en un servidor, con pruebas superadas. Eso es Claude Code.

Aquí es donde se rompe el modelo mental de la mayoría de la gente. Piensan en los asistentes de IA como chatbots: tú escribes una pregunta y ellos te dan una respuesta. Claude Code es fundamentalmente diferente. Es una herramienta CLI que puede leer archivos en tu disco, escribir archivos, ejecutar comandos de shell, gestionar repositorios Git y orquestar flujos de trabajo de varios pasos. No es una ventana de chat, es un agente con acceso a tu entorno de desarrollo.

En la práctica, esto significa que puedo decir: «Lee mi nota de Obsidian en ~/vault/projects/payment-gateway.md y crea un cliente Python basado en los puntos finales de la API que he documentado allí». Claude Code abre el archivo, lee el contenido, comprende la estructura y escribe un código funcional que coincide con lo que he documentado. Sin copiar y pegar entre aplicaciones. Sin volver a explicar el contexto. La nota es el contexto.

Más allá de leer notas, Claude Code está conectado a cinco servidores MCP que amplían sus capacidades: Gemini para investigación, Groq para generación rápida, modelos locales a través de Ollama y más. He escrito sobre esto en detalle en mi publicación sobre patrones de diseño de bots de IA. La integración MCP significa que Claude Code no se limita al conocimiento de su propio modelo. Puede recurrir a otros sistemas de IA cuando necesita capacidades especializadas.

La combinación de acceso a archivos + ejecución de comandos + herramientas MCP significa que Claude Code funciona como un auténtico socio de desarrollo, no como un buzón de sugerencias. Lee el código, entiende el proyecto, realiza cambios, ejecuta pruebas, se compromete con Git y se implementa, todo ello en una sola conversación.

NotebookLM: síntesis de fuentes

La tercera pieza se encarga de la parte de entrada del bucle: consumir y comprender rápidamente la nueva información.

NotebookLM es la herramienta de investigación de Google que ingesta documentos y te permite interactuar con ellos de forma conversacional. Le proporcionas archivos PDF, páginas web, transcripciones de YouTube y crea una base de conocimientos consultable a partir de esas fuentes. La diferencia clave con respecto a un chatbot general: solo responde basándose en las fuentes que le has proporcionado. Sin alucinaciones. Sin mezclar datos de entrenamiento aleatorios. Si la respuesta no está en tus fuentes, te lo dice.

La característica más importante para mi flujo de trabajo es el resumen de audio. Subo una especificación de API de 40 páginas, algunas entradas de blog sobre patrones de integración y un vídeo de YouTube de la conferencia de desarrolladores del proveedor de la API. NotebookLM sintetiza todo eso en una descripción general en audio de 15 minutos que puedo escuchar mientras camino o preparo café. Para cuando me siento a programar, ya he interiorizado los conceptos clave, los puntos clave y los patrones recomendados, sin tener que leer cada palabra de cada fuente.

Para una investigación estructurada, le hago preguntas específicas a NotebookLM: «¿Cuáles son los límites de velocidad para el punto final por lotes?», «¿Qué método de autenticación utiliza el webhook?», «¿Cuál es la diferencia entre su entorno de pruebas y el de producción?». Extrae las respuestas directamente de los documentos de origen con citas. Tomo esas respuestas y las pego en mis notas de Obsidian, donde pasan a formar parte de la base de conocimientos permanente.

Cómo funcionan juntos: el bucle

Este es el flujo de trabajo real, paso a paso:

1. Investigación (NotebookLM). Subir todas las fuentes relevantes: documentos, artículos, vídeos, artículos. Generar resúmenes de audio para una comprensión de alto nivel. Hacer preguntas específicas sobre detalles técnicos. Extraer la información clave.
2. Estructura (Obsidian). Crear notas a partir de los resultados de la investigación. Vincularlas a las notas de proyectos y conceptos existentes. Construir una comprensión estructurada con secciones para puntos finales, autenticación, modelos de datos, casos extremos y requisitos de implementación.
3. Ejecución (Claude Code). Dirige Claude Code a las notas de Obsidian y al código base del proyecto. Lee ambos, comprende el contexto y genera código funcional. Ejecuta pruebas, gestiona operaciones Git y puede implementar en el entorno de pruebas.
4. Documentar (Obsidian + Claude Code). Después de la implementación, actualiza las notas de Obsidian con lo que se construyó realmente (frente a lo que se planeó). Claude Code puede redactar actualizaciones de la documentación basándose en los cambios de código que ha realizado.

El ciclo es continuo. La investigación alimenta el conocimiento, el conocimiento alimenta el código, el código alimenta la documentación y la documentación alimenta la siguiente ronda de investigación cuando el proyecto evoluciona.

Ejemplo práctico: integración de una nueva API de pago

El mes pasado necesité integrar una pasarela de pago para un proyecto de un cliente. Así es exactamente cómo se desarrolló el flujo de trabajo.

Día 1 por la mañana: Investigación. Subí la documentación de la API del proveedor de pagos (3 PDF, unas 80 páginas en total), las entradas de su blog para desarrolladores sobre las mejores prácticas y dos vídeos de YouTube de su conferencia para desarrolladores. NotebookLM generó una descripción general en audio de 12 minutos. Lo escuché durante mi paseo matutino. Ideas clave: su modelo de idempotencia es diferente al de Stripe, su verificación de webhook utiliza HMAC-SHA256 (no solo SHA256) y su entorno de pruebas tiene modos de fallo intencionados para probar el manejo de errores.

Día 1 por la tarde: Notas. Creé ~/vault/projects/client-x/payment-integration.md en Obsidian. Secciones: Autenticación, Puntos finales (cargo/reembolso/webhook), Modelos de datos, Manejo de errores, Notas sobre idempotencia, Estrategia de pruebas. Lo vinculé a mis notas existentes sobre patrones de procesamiento de pagos y la descripción general de la arquitectura del proyecto. Nota total: unas 800 palabras de información estructurada y referenciada.

Día 2: Código. Abrí Claude Code y dije: «Lee ~/vault/projects/client-x/payment-integration.md y el código base existente en ~/projects/client-x/. Crea un cliente de pasarela de pago en src/payments/ con los métodos y el manejo de errores documentados en las notas». Claude Code leyó ambos, creó la clase de cliente, implementó la verificación HMAC webhook (obteniendo el algoritmo correcto porque estaba en mis notas) y escribió pruebas unitarias con respuestas simuladas. Lo comprometió todo a una rama de características.

Día 2, por la tarde: Documentación. Actualicé la nota de Obsidian con los detalles de la implementación: qué patrones de diseño utilicé, una nota sobre una peculiaridad en el formato de fecha y un enlace al commit de Git. La próxima vez que yo, o cualquier miembro del equipo, necesitemos comprender esta integración, todo el contexto estará en un solo lugar.

Tiempo total desde «Nunca he usado esta API» hasta «Código probado y confirmado con documentación»: unas 8 horas en dos días. Sin este flujo de trabajo, según mi experiencia previa, el mismo trabajo me habría llevado entre 3 y 4 días.

Si estás creando flujos de trabajo de automatización similares para tu equipo, se aplican los mismos principios a cualquier escala. Las herramientas son gratuitas o de bajo coste, el flujo de trabajo es repetible y los conocimientos se acumulan con el tiempo.