Del LLM Wiki de Karpathy a un segundo cerebro funcional: mi implementación con Amazon Quick Desktop

Dima Kramskoy — Senior Cloud Architect en DoiT International Más de 20 años en software engineering · 10 certificaciones de AWS · AWS Community Builder 2026 · Alumni del Architect Master Class de Juval Löwy (2022)

El problema: cada conversación arranca desde cero

Este es el antipatrón que me saca de quicio: tienes una conversación profunda de 45 minutos con un asistente de IA sobre tus decisiones de arquitectura, los trade-offs y las restricciones. Cierras la pestaña. Al día siguiente abres un chat nuevo. No sabe nada. Toca empezar el onboarding de cero otra vez.

Ahora multiplica eso por toda tu superficie de conocimiento: hilos de Slack con contexto que jamás volverá a ser buscable, cadenas de correo donde las decisiones quedaron sepultadas en la respuesta #14, documentos que existen en tres versiones repartidas entre dos drives y el conocimiento tribal que vive únicamente en la cabeza de las personas.

A nadie se le ocurriría hacerle el onboarding a su reemplazo entregándole solo su historial de Slack. Pero eso es justo lo que hacemos con nuestras herramientas de IA: les pasamos fragmentos y esperamos coherencia.

El problema de fondo no es la inteligencia. GPT-4, Claude, Gemini: todos son brillantes. El problema es la amnesia. Cada sesión es un arranque en frío. Tu contexto está disperso en una docena de herramientas, y ninguna se comunica con las demás a través de un modelo unificado de ti y tu trabajo.

Llevo meses dándole vueltas. Y entonces Karpathy publicó un tweet que terminó de cuajar la solución.

La inspiración de Karpathy: RAG recupera, un wiki acumula

En abril de 2026, Andrej Karpathy publicó en X sobre "el LLM Wiki": 17 millones de vistas y subiendo. La idea central me cayó como un patrón de diseño que encaja en su lugar:

"RAG recupera. Un wiki acumula."

Su framework es elegante. Tres capas:

1. Fuentes en bruto — artículos, papers, tweets, conversaciones, notas
2. Wiki — páginas de conocimiento destiladas, estructuradas e interconectadas
3. Schema — la ontología que rige cómo se organiza el conocimiento

La analogía que usa es perfecta: "Obsidian es el IDE. El LLM es el programador. El wiki es el codebase."

Matt Paige escribió un excelente análisis del concepto. El cambio clave: en lugar de volcar documentos en bruto en una base de datos vectorial y rezar para que la recuperación dé con el chunk correcto, construyes una base de conocimiento viva y estructurada que el LLM mantiene y enriquece con el tiempo.

RAG es una consulta. Un wiki es un sistema. Una es O(1) por consulta. El otro acumula.

Pero esto es lo que me incomodaba de la versión de Karpathy: es manual. Tú eres el operador. Tú haces los prompts, revisas, pegas, organizas. El LLM asiste, pero tú conduces. Yo quería algo distinto: un asistente que hiciera esto por mí, no un sistema que tuviera que mantener yo.

Por qué Amazon Quick Desktop

Cuando evalué herramientas para esta implementación, tenía una checklist derivada directamente de la arquitectura de Karpathy:

• ✅ Memoria de largo plazo que persiste entre conversaciones
• ✅ Grafo de conocimiento (extrae entidades y relaciones automáticamente desde Slack, correo y calendario)
• ✅ Búsqueda semántica sobre archivos locales
• ✅ Acceso de lectura y escritura a mi filesystem
• ✅ Tareas en background (investiga mientras yo trabajo en otra cosa)
• ✅ Herramientas conectadas (Gmail, Slack, Google Calendar, servidores MCP)
• ✅ Capa de acción (puede redactar correos, crear documentos, agendar reuniones)

Amazon Quick Desktop ya tenía lo que Karpathy describe, pero integrado y conectado a herramientas de trabajo reales. No es una ventana de chat. Es un runtime.

Comparación rápida:

La decisión clave: quería un asistente que acumulara conocimiento POR mí, no un sistema que tuviera que mantener yo. El costo de mantener un wiki manual termina matando la adopción. Lo he visto una docena de veces.

Lo que armé (en 1 semana)

Estructura de carpetas

~/SecondBrain/
├── raw/                          # Entradas sin procesar
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # Conocimiento destilado
│   ├── concepts/                 # Modelos mentales, frameworks
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # Personas, orgs, herramientas
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # Trabajo activo
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # Referencias indexadas
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # Seguimiento diario de output
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # La ontología
└── mkdocs.yml                    # Documentación auto-servida

SCHEMA.md (extracto)

# SecondBrain Schema v1.0

## Tipos de página
- **concept**: un modelo mental, patrón o framework. Debe incluir: definición, cuándo usarlo, antipatrones y conceptos relacionados.
- **entity**: una persona, organización o herramienta. Debe incluir: rol o propósito, relación con mi trabajo y fecha de la última interacción.
- **project**: trabajo activo o terminado. Debe incluir: estado, stakeholders, registro de decisiones y próximas acciones.
- **source**: un artículo, charla o paper ingerido. Debe incluir: URL, insights clave (máx. 5) y conexión con conceptos existentes.
- **log**: entrada diaria. Auto-generada. Registra: páginas creadas, páginas actualizadas, preguntas respondidas y acciones realizadas.

## Convención de nombres
kebab-case. Sin fechas en los nombres de archivo (eso va en el frontmatter).

## Reglas de referencias cruzadas
Cada página nueva DEBE enlazar a ≥1 página existente. Las huérfanas son mala señal.

El stack

• MkDocs + tema Material — auto-sirve el wiki localmente en localhost:8000
• launchd plist — arranca MkDocs al iniciar sesión (macOS). Cero fricción para navegar.
• Amazon Quick — lee y escribe el wiki, propone actualizaciones y responde preguntas sobre su contenido
• Indexado semántico — Quick indexa ~/SecondBrain/ y lo busca de forma contextual

El workflow de aprobación

Esto es crítico. Nada se escribe sin mi OK. El flujo:

1. Digo "ingiere este artículo" o comparto un link
2. Quick lo lee y propone una página nueva del wiki (o actualizaciones a páginas existentes)
3. Veo el diff: contenido nuevo resaltado, referencias cruzadas a la vista
4. Apruebo, modifico o rechazo
5. El contenido aprobado se escribe en disco y MkDocs se refresca automáticamente

Más de 15 páginas del wiki en la primera semana. No por darle duro, sino a partir de conversaciones que ya estaba teniendo.

Un día en la vida

Mañana:

"Buenos días"

Quick responde con: correos prioritarios (marcados o de personas clave), hilos de Slack que necesitan mi respuesta y el calendario de hoy con notas de preparación para cada reunión. No es un chorro de info, es un briefing.

Durante el día:

"Ingiere esto: [link a un blog post de arquitectura]"

Quick lo lee, identifica 3 conceptos clave y propone una nueva página en sources/ más actualizaciones a dos páginas existentes en concepts/. Reviso el diff por encima, apruebo, listo. 90 segundos.

"Redacta un blog post sobre la implementación del Second Brain"

Toma material de mis páginas del wiki, conoce mi voz (gracias a la memoria de textos pasados) y lo estructura con mi formato preferido. Yo edito, no escribo desde cero.

"Bloquea 2 horas mañana para trabajo profundo en el voice capture pipeline"

Revisa mi calendario, encuentra un hueco, lo reserva y agrega notas de preparación desde la página projects/voice-capture-pipeline.md.

En background:

Mientras estoy en reuniones, las tareas en background investigan temas que dejé encolados. Cuando vuelvo: "Encontré 3 papers relevantes sobre mantenimiento de grafos de conocimiento. ¿Quieres que los ingiera?"

El efecto acumulativo es real. Para el día 5 ya respondía preguntas sintetizando varias páginas del wiki que ni recordaba haber aprobado.

La extensión de Voice Capture (PoC)

Las mejores ideas me llegan cuando voy caminando, no frente al escritorio. Así que armé un pipeline:

Arquitectura

iPhone Shortcuts (o wearable Plaud NotePin)
    → API Gateway (REST)
        → Lambda (handler de upload)
            → S3 (bucket de audio)
                → Evento de S3 → Lambda (trigger de transcripción)
                    → AWS Transcribe
                        → Lambda (post-procesamiento)
                            → Knowledge Base de Amazon Quick
                                → Página del wiki propuesta

Cómo funciona

1. Activo un Shortcut en mi iPhone (o el NotePin graba en ambiente)
2. El audio sube a S3 vía API Gateway + Lambda
3. El evento de S3 dispara la transcripción con AWS Transcribe
4. La transcripción se limpia, se fragmenta y se envía al knowledge base de Quick
5. La próxima vez que abro Quick: "Tienes un voice capture sobre [tema]. ¿Quieres que cree una página del wiki?"

Costo total en AWS: fracciones de centavo por captura. Las funciones Lambda son triviales: 50 líneas cada una. El valor está en cerrar el ciclo: pensamiento → captura → conocimiento estructurado → algo accionable.

Reseña honesta: 7/10

Lo que funciona

• Estructura — el schema impone consistencia. Las páginas se encuentran fácil y sirven.
• Acumulación — las respuestas de la semana 2 son notablemente mejores que las de la semana 1. Sabe cosas.
• Herramientas conectadas — el contexto de Slack enriquece las páginas del wiki. Conocer el calendario permite agendar de verdad.
• Capa de acción — no solo sabe cosas; hace cosas. Borradores, slides, reservas.
• Búsqueda semántica — "¿qué decidí sobre X?" realmente funciona a lo largo del wiki.

Lo que falta pulir

• Referencias cruzadas — todavía no son totalmente automáticas. Algunas páginas siguen sub-enlazadas.
• Health checks — no he implementado auditorías programadas para páginas obsoletas o huérfanas.
• Ingesta programada — no hay un cron tipo "revisa estos 5 feeds RSS al día". Sigue siendo disparo manual.
• Detección de contradicciones — sin probar. ¿Qué pasa cuando información nueva entra en conflicto con páginas existentes del wiki?

En qué fuimos MEJORES que la visión original de Karpathy

Su visión es el plano. Pero es de solo lectura: archivos que consultas. La mía produce: redacta correos, crea slides, agenda reuniones, escribe blog posts. El wiki no es solo una referencia; es una fuente de acción.

Cómo puedes empezar (en 5 pasos)

No necesitas mi setup completo para sacarle provecho. Este es el gradiente:

Los 5 pasos

1. Conecta tus herramientas — Slack, Gmail, Calendar y una carpeta local. Son 10 minutos en Configuración.
2. Empieza a hablar — la memoria se acumula desde el día 1. Cada conversación le enseña algo sobre ti.
3. Di "recuerda esto" después de conversaciones importantes — anclas explícitas de memoria.
4. Crea ~/SecondBrain/ + SCHEMA.md — si quieres ir más a fondo, dale estructura.
5. Hazle una pregunta que abarque todo — "¿cuáles fueron mis decisiones clave la semana pasada?". Ya estás enganchado.

Tres niveles de compromiso

Empieza en 🟢. En serio. La acumulación ocurre construyas infraestructura o no. La estructura del wiki solo la vuelve visible y auditable.

Conclusión

Tu IA no debería arrancar desde cero en cada conversación.

Las herramientas existen. El patrón está probado. Karpathy mostró la arquitectura; Amazon Quick aporta el runtime. La brecha entre "asistente de IA" y "segundo cerebro" se reduce a estructura + persistencia + herramientas conectadas.

Acumular > Recuperar. Cada conversación, cada artículo ingerido y cada página de wiki aprobada vuelve más inteligente la siguiente interacción. Eso no es recuperación: es crecimiento.

Empieza en pequeño. Se va acumulando. Justamente ese es el punto.

Una última reflexión, y esta viene de Jocko Willink, no de la investigación en IA: Extreme Ownership aplicado al conocimiento. Si una información está en tu mundo —un hilo de Slack, una charla de conferencia que recuerdas a medias, una idea que se te ocurrió en una caminata matutina— y no la capturas, no es tuya. Es ella la que termina poseyéndote, al no estar disponible cuando más la necesitas.

Captúrala. Estructúrala. Deja que se acumule.

Este post se redactó con la ayuda de mi Second Brain, tomando material de páginas del wiki que había construido la semana anterior. La ironía no se me escapa. Ese es precisamente el punto.

Presentado en el GenAI Community Skill Share de DoiT, el 22 de mayo de 2026. Gracias a los ~27 colegas que hicieron preguntas filosas y empujaron la reflexión más allá.