“A large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge.”

(Una fracción grande de mi consumo reciente de tokens ya no va a manipular código, sino a manipular conocimiento.)

Eso lo escribió Andrej Karpathy el 2 de abril en un post en X que acumuló más de 17 millones de vistas. Karpathy fue Director de IA en Tesla, cofundador de OpenAI, y es la persona más influyente explicando cómo funcionan las redes neuronales a nivel práctico. Cuando cambia la forma en que trabaja, vale la pena prestar atención.

Describió un cambio de función: dejó de usar la IA principalmente para escribir código y empezó a usarla para compilar y mantener conocimiento.

Tres carpetas y un cambio de paradigma

El sistema que publicó es casi insultantemente simple. Tres carpetas:

• raw/ — Documentos fuente. Artículos, papers, repos, datasets, imágenes. La IA lee pero nunca modifica.
• wiki/ — La wiki compilada. Archivos markdown con resúmenes, referencias cruzadas, backlinks entre conceptos. La IA es dueña de esta carpeta. Karpathy casi nunca la toca directamente.
• Un archivo de esquema — Las reglas: cómo organizar, qué convenciones seguir, qué hacer cuando entra una fuente nueva.

El resultado: ~100 artículos y ~400,000 palabras sobre un solo tema de investigación. No escribió una sola línea manualmente. El LLM se encargó de todo: desde leer las fuentes y redactar los artículos, hasta cruzar las referencias y auditar contradicciones entre documentos.

Lo logró usando solo carpetas y texto plano, dejando de lado la complejidad de bases vectoriales y sistemas RAG.

Dos días después publicó un gist en GitHub con los detalles. Más de 5,000 estrellas y 1,400 forks en 48 horas. La frase que define su filosofía: “Obsidian es el IDE; el LLM es el programador; la wiki es el codebase.”

Y la conexión histórica que pocos notaron: en 1945, Vannevar Bush imaginó el Memex, un dispositivo personal que almacenaría conocimiento con “trails asociativos” entre documentos. La idea era correcta. El problema que nunca resolvió fue quién hace el mantenimiento. Ochenta años después, el LLM lo hace.

Las reacciones que importan

Más allá de la viralidad, lo que importa son las respuestas que generó en la industria.

Lex Fridman confirmó que usa un sistema similar. Genera visualizaciones interactivas en HTML con JavaScript y crea “mini bases de conocimiento temporales” que carga en modo de voz para conversaciones durante caminatas de 10-15 kilómetros.

Steph Ango, CEO de Obsidian, dio el consejo más práctico de todo el hilo: separar las bóvedas. Mantener el conocimiento curado por humanos en un espacio limpio. Dejar que la IA compile en un espacio separado. Solo traer lo útil una vez destilado. No mezclar las dos fuentes.

Elvis Saravia de DAIR.AI publicó un análisis completo y confirmó que usa un sistema similar para curar investigación de IA. Su conclusión: “Es el sistema de investigación más personalizado que he construido, y no está ni cerca de lo que existía antes.”

Y la reacción que debería importarle a cualquier director de tecnología: Vamshi Reddy escribió “Every business has a raw/ directory. Nobody’s ever compiled it.” Todas las empresas tienen un directorio raw/. Nadie lo ha compilado. Karpathy estuvo de acuerdo.

En menos de una semana aparecieron más de siete implementaciones en GitHub. Farza construyó “Farzapedia”, una Wikipedia personal compilada a partir de 2,500 entradas de su vida. Y Edra, fundada por ex-ejecutivos de Palantir, levantó $30M en Serie A liderada por Sequoia para resolver la versión empresarial de exactamente este problema.

El problema que sí le toca a tu empresa

Llevo 35 años en computación y negocios. He visto muchas modas pasar. Pero lo que Karpathy describe apunta a un problema que las empresas B2B arrastran desde hace décadas y que la IA debería estar resolviendo, pero está resolviendo mal.

McKinsey estima que los empleados pierden 1.8 horas al día buscando información interna. El 25% de la jornada laboral. IDC lo pone en 2.5 horas. Los números varían; la dirección no.

¿Dónde está ese conocimiento? Disperso entre Confluence, SharePoint, Slack, correos, documentos de Google, y una cantidad enorme de conocimiento tribal que vive en la cabeza de tres personas que llevan diez años en la empresa y que nadie se ha sentado a documentar.

Ahora mira cómo la mayoría de empresas usa la IA para “resolver” esto: suben documentos a ChatGPT, hacen una pregunta, obtienen una respuesta, cierran la sesión. La próxima vez que alguien tiene la misma pregunta, el proceso empieza de cero. No hay memoria ni acumulación entre sesiones. Cada consulta es un viaje nuevo al mismo lugar.

Lo que Karpathy demostró es lo contrario. Cada fuente que se ingesta hace la wiki más rica. Cada pregunta puede archivarse de vuelta en la wiki para enriquecerla. El sistema se vuelve más valioso con el uso en lugar de resetear con cada sesión. El sistema gana valor con el uso en lugar de perderlo con el paso del tiempo. Esa es la diferencia entre un chatbot y una infraestructura de conocimiento.

Los límites del sistema de Karpathy

Escalar esto a nivel corporativo tiene obstáculos técnicos concretos.

Las ventanas de contexto actuales limitan cuántos documentos puede procesar el LLM sin perder información. Karpathy trabaja con ~100 artículos. Una empresa mediana tiene miles; una grande tiene millones. A esa escala, el modelo navega por índices que él mismo mantiene, y puede pasar por alto información relevante enterrada en un rincón de la wiki.

Además, depender solo de enlaces manuales en markdown ignora las ventajas de RAG. Scott Rippey, un ingeniero cuyo comentario acumuló 67 reacciones en un hilo de LinkedIn, lo dijo directo: “Esto ES Graph RAG hecho a mano, no un reemplazo.” Los embeddings vectoriales descubren conexiones entre textos con vocabulario diferente que el enlace manual entre archivos no detecta.

A esto se suman problemas de seguridad que en un contexto personal no importan pero en una empresa son bloqueantes: la falta de control de acceso por roles, de logs de auditoría para cumplimiento regulatorio, de protección contra exfiltración de datos. Un chmod no es estrategia de seguridad. El historial de Git no es un log de auditoría empresarial.

Pero el riesgo que más me preocupa es la composición de errores. El LLM escribe una página de wiki con un error sutil. Alguien consulta contra esa página. El error entra en la respuesta. La respuesta se archiva de vuelta. Ahora dos páginas refuerzan el mismo error. Sin verificación externa, los errores se acumulan igual que el conocimiento correcto.

Nilou Salehi de Across AI lo articuló bien: “El verdadero desbloqueo no es cómo almacenamos conocimiento. Es cómo hacemos que el conocimiento sea ejecutable.”

Lo que sí puedes hacer esta semana

Hay acciones concretas que puedes tomar esta semana.

Antes de construir nada, identifica dónde vive hoy tu conocimiento disperso. Todas las empresas tienen conocimiento disperso. ¿Dónde viven las decisiones de producto? ¿Dónde está la documentación de procesos? ¿Qué conocimiento crítico existe solo en la cabeza de personas específicas? Mapealo antes de construir cualquier cosa.

Después, escoge un solo dominio. Compilar todo el conocimiento de la empresa de una vez es una receta para no terminar nunca. Un vertical funciona mejor: inteligencia competitiva, documentación técnica de un sistema específico, procesos de onboarding. Construye la wiki de ese dominio y valida el patrón antes de expandir.

El consejo de Steph Ango sobre separar bóvedas aplica directo. Deja que la IA compile en su espacio. Que los humanos validen y traigan lo útil al espacio oficial. Si mezclas las dos fuentes, contaminas tu base con alucinaciones que parecen hechos.

Hay una métrica que nadie mide y que te dice si este enfoque vale la pena para tu caso: la velocidad de pudrición de tu documentación. ¿Cuánto tarda en volverse obsoleta? Si la respuesta es “semanas” y nadie la actualiza porque siempre se posterga, acabas de encontrar el caso de uso exacto donde un LLM absorbe la carga de mantenimiento.

Y un recordatorio: el propio Karpathy llamó a su sistema “una colección hacky de scripts.” El patrón es correcto. La implementación empresarial necesita gobernanza, control de acceso, y una capa de contexto que los modelos no traen por defecto.

El conocimiento no es un chat

El cambio que señala este post de Karpathy va más allá de carpetas y archivos markdown. Es un cambio en la relación entre las organizaciones y su propio conocimiento.

Durante años, la promesa fue “busca mejor.” Mejores motores de búsqueda internos, mejores etiquetas, mejor organización de carpetas. Nada de eso resolvió el problema porque el cuello de botella nunca fue buscar. Fue mantener. Nadie quiere ser la persona que actualiza la wiki de Confluence un viernes a las 4 de la tarde.

El verdadero cambio que traen los LLM no es ayudarte a encontrar cosas más rápido, sino asumir la tediosa tarea de mantener la información actualizada. Por primera vez, tienes un agente que no se aburre de actualizar referencias cruzadas, que puede tocar 15 documentos en un solo pase sin quejarse, y que mejora el sistema con cada interacción en vez de degradarlo con cada mes de abandono.

El conocimiento de tu empresa acumula o se pudre.

En IQ Source ayudamos a empresas B2B a construir sistemas de conocimiento que se vuelven más valiosos con el uso, con las capas de gobernanza que un post viral de X no incluye pero que tu operación necesita.

Si quieres mapear dónde está el directorio raw/ de tu organización, empecemos por ahí.