La Línea en el Wiki Gist de Karpathy Que el 99% de los Desarrolladores Pasó por Alto — Y Por Qué Es Lo Más Importante

Todos entendimos el punto de un segundo cerebro hace mucho tiempo. Condensa tus cursos, tus libros, tus PDFs, tus notas en un lugar donde realmente puedas encontrarlos otra vez. El concepto lleva diez años dando vueltas, está digerido, mucha gente lo intentó. El problema nunca fue la idea. El problema es el mantenimiento. Alimentas tu sistema durante tres meses, terminas con ciento cincuenta archivos, te pierdes entre ellos, pasas más tiempo reorganizando que agregando. A los seis meses, el cerebro está tirado en algún rincón de tu disco y no lo tocas nunca más.

Karpathy publicó un gist hace dos semanas que resuelve exactamente eso. Agrega una capa de auto-organización encima: el sistema archiva sus propias páginas, fusiona redundancias, se mantiene coherente solo. Todo el mundo empezó a construirlo esta semana. Tres carpetas, un CLAUDE.md, Obsidian arriba. Tutoriales por todos lados.

Excepto que una cosa se le escapó al 99% de los que lo construyeron. Y es una pena, porque es todo el punto. Sin eso, tienes una carpeta que se ordena sola. Con eso, tienes un cerebro que aprende de cada pregunta que le haces, lee lo que tus herramientas le escriben, y eventualmente empieza a construir las herramientas que necesita.

La Base de Conocimiento Que Ya Tenía (Y Nunca Usé a Su Máximo Potencial)

No empecé de cero hace seis meses. Como la mayoría de devs que llevan tiempo en esto, ya tenía repos desperdigados en mi disco donde había organizado conocimiento, habilidades, procesos, herramientas, docs. Una carpeta por dominio. Archivos markdown cuidadosamente estructurados. Notas de SEO acá, patrones de code review allá, snippets que seguía reutilizando, decisiones de arquitectura que no quería olvidar. Recetas de Docker compose que había terminado reescribiendo al menos tres veces porque nunca podía encontrar la versión anterior. Diagramas de infra. Checklists de deploy. Post-mortems de incidentes que había escrito para mí mismo y nunca releído. Usaba estos repos todos los días, los cargaba en Claude Code como contexto cuando los necesitaba, hacía preguntas contra ellos, copiaba y pegaba reglas en proyectos nuevos.

Funcionaba. Era útil. Y si estás leyendo esto, lo más probable es que tengas lo mismo en algún lado. El repo de cosas que ingeriste, limpiaste, commiteaste. Ese con el que te sientes bien los domingos a la noche después de agregar un archivo nuevo.

El gran cambio que trajo Claude, comparado con los diez años anteriores de hacer esto, es que dejé de preguntarme "¿dónde carajo puse esa cosa otra vez?". Durante una década, el cuello de botella de cualquier base de conocimiento personal era el mismo: tenías la información en algún lado, recordabas vagamente haberla anotado, pero encontrarla significaba grep, Spotlight, abrir tres carpetas, releer medio archivo para verificar si era el correcto. Ahora simplemente le pregunto a Claude. El repo está en contexto, la pregunta se responde, listo. Solo eso fue un gran avance. Hizo que el repo fuera realmente usable por primera vez.

Pero todavía lo estaba sub-explotando. Mal. Mi repo era una biblioteca muy bien organizada por la que tenía que caminar yo mismo cada vez que quería sacar un libro del estante (excepto que ahora Claude caminaba por mí en lugar de yo). Mejor, más rápido, pero todavía unidireccional. Preguntaba, respondía, la conversación terminaba. El repo no aprendía nada de todo eso. Mañana haría una pregunta relacionada, Claude caminaría por el mismo estante otra vez, me daría una respuesta ligeramente diferente, y esa segunda respuesta también se evaporaría.

Creo que por eso el gist de Karpathy resonó tan fuerte cuando lo publicó. No era la arquitectura. Muchos de nosotros ya teníamos algo similar. El gist le puso nombre a una sensación vaga con la que la mayoría habíamos estado sentados durante meses: esta cosa que construí es útil, pero claramente no está haciendo lo que podría estar haciendo. La pieza faltante era la capa de auto-organización. Un segundo cerebro que archiva sus propias páginas, fusiona sus propias redundancias, mantiene su propia coherencia mientras duermes. Eso es lo que Karpathy puso frente a nosotros.

Y eso es lo que todo el mundo empezó a construir esta semana.

Karpathy Publicó la Arquitectura. Todos Copiaron la Mitad Equivocada.

El gist se llama llm-wiki. Dos carpetas donde importa. raw/ para el material fuente, filtrado y estructurado pero completo. Un curso completo de SEO destilado en 900 líneas. Un libro de programación condensado en 600. Un playbook de ops reducido de tres charlas de conferencia a 700 líneas de lo que realmente aplica a tu stack. Nadie lee esto en producción. Es el archivo, el lugar al que vuelves cuando el wiki dice algo que se siente raro y quieres verificar la fuente.

wiki/ es la versión operacional. Un archivo por dominio. Fusiona cada raw en ese dominio en reglas accionables. 150 a 200 líneas máximo. Esto es lo que los agentes cargan antes de producir cualquier cosa. Una fracción del tamaño raw, y se mantiene solo. Agregas un curso nuevo en el mismo dominio, el wiki absorbe las nuevas reglas sin crecer. Las contradicciones se resuelven, los patrones obsoletos se descartan.

Encima de eso, un CLAUDE.md en la raíz diciéndole al modelo cómo navegar todo, y Obsidian como frontend para que puedas navegarlo como un humano normal.

La arquitectura es limpia. También es la parte obvia. Por supuesto que separas raw de sintetizado. Por supuesto que le das reglas de navegación al modelo. Por supuesto que Obsidian es un buen visor.

Después llegaron los tutoriales. Cada YouTuber tech con ring light reposteó variaciones del mismo diagrama esta semana. Tres carpetas. CLAUDE.md. Obsidian. Constrúyelo como Karpathy. Sube un screenshot. Sigue adelante.

Fui parte de esa ola durante dos días. Reconstruí la estructura encima de mi repo existente. Ingerí más fuentes. Hice preguntas. El setup era mejor que lo que tenía, más rápido, más denso. Pero la base seguía ahí sentada, creciendo solo cuando le daba cosas nuevas manualmente. La capa de auto-organización estaba haciendo su trabajo con lo que ponía adentro. No estaba haciendo nada con lo que hacía con la base después.

Ahí fue cuando volví al gist y lo leí más despacio. No la sección de arquitectura. La sección de queries. La parte que dice qué pasa después de que el modelo responde.

La Oración Que Convierte un Archivo Estático en una Base Viva

La oración, del propio post de Karpathy sobre el workflow:

"A menudo, termino archivando las salidas de vuelta en el wiki para mejorarlo para futuras consultas. Así mis propias exploraciones y consultas siempre se suman en la base de conocimiento."

Léela dos veces. Describe un comportamiento, no una arquitectura.

Lo que dice, claramente: cuando haces una pregunta y el modelo te da una respuesta útil, esa respuesta vuelve al wiki como una página nueva. La siguiente consulta, sobre el mismo tema o adyacente, empieza desde una base que ya contiene la respuesta anterior. La base crece desde tu uso, no solo desde tu ingesta.

Sin este bucle, tu repo es un RAG con carpetas más bonitas. Ingieres, consultas, la respuesta parpadea en tu pantalla y muere en el historial del chat. Mañana haces una pregunta similar, el modelo recupera de las mismas páginas fuente, sintetiza la misma respuesta desde cero. Pagas por la síntesis cada vez (mi forma favorita de desperdicio recurrente, honestamente).

Con el bucle, la base tiene estado. El trabajo del modelo cambia de "sintetizar desde fuentes raw" a "encontrar la página donde esto ya está respondido, refinarlo si es necesario". Más rápido, más barato, más denso con el tiempo.

Un párrafo en el gist. Toda la razón para construir esto.

Lo Que un Container Muerto Le Enseñó a Mi Base de Conocimiento

Mi repo no solo tiene cursos y libros. También tiene la documentación viva de mis propios servicios: configs, notas de deploy, incidentes pasados, decisiones de arquitectura que tomé a las 2am y anoté antes de olvidar por qué. Mismo patrón que el resto, raw/ con el historial completo, wiki/ con las reglas operacionales. Acá es donde las cosas empezaron a ponerse interesantes.

Mi sync del catálogo de distribuidor se detuvo. El container estaba up, el proceso estaba vivo, pero no había tirado un feed nuevo en 34 horas. Me di cuenta porque el conteo de productos del lado del partner se desfasó de lo que estaba en mi storefront. Los clientes empezaron a ordenar cosas que ya no estaban en stock upstream.

Abrí Claude Code y pregunté: "¿cuál es el estado del sync del distribuidor, cuándo corrió exitosamente por última vez, y cuál es la causa más probable del silencio?" El modelo fue por el wiki, tiró la página de servicio relevante, verificó las entradas de log recientes que había ingerido, y respondió: probablemente un memory leak en el parser, el container está consumiendo RAM pero no crasheando porque el threshold del OOM killer está muy alto. Recomendó un restart y un memory cap.

Respuesta clásica de Claude Code. Útil. Específica. Habría muerto en el historial del chat.

Excepto que el bucle estaba activado. La respuesta se archivó de vuelta en el wiki como una página nueva bajo services/distributor-sync/incidents/2026-03-29-silent-failure.md. La página tenía el síntoma, el diagnóstico, la resolución, y una flag notando que este servicio había fallado silenciosamente una vez. Costo total: una consulta, una página archivada.

Una semana después, hice una pregunta no relacionada sobre el webhook de la API del partner. El modelo respondió, después agregó la versión educada de "por cierto, podrías querer mirar esto": "nota que tu sync del distribuidor tuvo una falla silenciosa hace 6 días, actualmente no tienes monitoreo en su heartbeat, podrías querer agregar uno antes de que esto pase otra vez". Sacó eso solo porque el wiki tenía la página del incidente, y el modelo la había leído mientras buscaba contexto en servicios adyacentes.

Una semana antes, esa información se habría perdido. La sesión de chat donde lo diagnostiqué habría estado cerrada. La próxima vez que el sync muriera silenciosamente, habría redescubierto la misma causa raíz desde cero.

El wiki no solo recordó. Conectó.

El Tercer Canal: Cuando Tus Herramientas Alimentan la Base, Y la Base Construye Sus Propias Herramientas

Acá está lo que me molestó del incidente de arriba. Me enteré de que el container había fallado silenciosamente por accidente, porque los clientes empezaron a quejarse. Claude archivó la página solo después de que pregunté. Si no hubiera preguntado, el incidente nunca habría existido en la base.

¿Qué tal si el container mismo archivara la página?

El bucle de Karpathy es manejado por humanos. Preguntas, el modelo responde, la respuesta se archiva. Dos canales alimentan la base: documentos que ingieres manualmente, y consultas que corres. Hay un tercer canal. No está en el gist.

Tu infraestructura ya produce señal continuamente. Los cron jobs tienen éxito o fallan. Los containers se reinician. Los servicios hacen timeout. Los callbacks de webhook devuelven códigos no-200. La mayoría de esta señal va a logs que nadie lee, o a sistemas de alertas que disparan una vez y se olvidan. Nada de eso termina en ningún lugar que el modelo pueda usar.

Lo que construí encima del patrón de Karpathy es una capa fina que deja que la infra misma archive páginas. Un CLI que cualquier servicio puede llamar para agregar una observación directamente en la base. El sync del catálogo escribe una página cuando tiene éxito, con el conteo de filas. El handler del webhook escribe una página cuando ve un payload malformado. Un cron escribe una página cuando se saltea porque la corrida anterior todavía estaba yendo. Páginas cortas. Con timestamp. Aterrizan en una carpeta signals/ que el modelo conoce.

La razón por la que esto funciona es la misma razón por la que los CLIs son mejores canales de señal que los wrappers MCP para cualquier tarea de agente: un curl one-liner desde un script de Bash escribe al wiki, sin negociación de protocolo, sin baile de schema. El container no necesita saber qué es un LLM. Solo agrega un archivo markdown a una carpeta.

Y después empezó a pasar lo de segundo orden.

Una vez que se acumuló suficiente señal, el modelo empezó a leer la carpeta signals/ durante las consultas y señalar gaps. No "tu container falló" (esa parte era esperada). Cosas como: "tienes tres servicios escribiendo páginas de éxito pero ninguna página de falla para el webhook handler, lo que significa que no puedo decir si está funcionando o solo silencioso. Podrías querer agregar un emisor de fallas en ese handler." O: "tu cron job para el sync del distribuidor escribe cuando corre, pero nada escribe cuando se saltea un ciclo. Necesitas un emisor de skip."

Después dejó de preguntar. Empezó a construir.

Un ejemplo concreto de la semana pasada, y ni siquiera de infra. Me estaba preguntando si comprar 32 o 48 GB de RAM en mi próxima MacBook. Pregunta clásica, respuesta clásica del tipo en la Apple store: "vas a estar bien con 24, confía en mí." No confié en él. Le pregunté a Claude Code en su lugar, con mi repo en contexto: "¿cómo sé lo que realmente necesito?" El modelo no me dio un ballpark. Propuso construir un CLI de monitoreo (un script para samplear métricas de RAM cada 5 minutos en un CSV, un segundo script para computar el resumen y recomendar un tamaño basado en el pico observado más un margen del 30%). Escribió ambos scripts. Los corrió. Tres días de datos después, el veredicto estaba en mi wiki: RAM usado estaba clavado en 22 a 23 GB en una máquina de 24 GB, 77 MB libres en el punto más bajo, compresor trabajando overtime en 4.5 GB. Recomendación: 32 mínimo, 48 si quería paz mental.

No una adivinanza. No marketing. Números reales de mi uso real, recolectados por herramientas que la base construyó para sí misma porque sabía que todavía no tenía la respuesta.

La base ya no solo estaba aprendiendo. Estaba cerrando sus propios puntos ciegos.

Ingieres. Consultas. Tus herramientas escriben. Y después la base construye la siguiente herramienta sola.

Tres Trampas Antes de Activar el Bucle

Tres trampas en las que caí en las primeras dos semanas. Toma estas decisiones antes de activar el switch, o tu base se convierte en un basurero rápido.

Qué se archiva de vuelta. Empecé archivando cada respuesta. Después de cuatro días la base tenía cuarenta y siete variaciones de "sí ese comando de docker es correcto" y no podía encontrar nada útil. La regla ahora: archivar de vuelta solo si la respuesta revela algo que la base no sabía ya, documenta un incidente, o hace una decisión explícita. El scaffolding conversacional muere en el historial del chat donde pertenece.

Quién decide la calidad. Los modelos que se auto-juzgan son demasiado generosos consigo mismos, descubrí eso rápido cuando Claude archivó una página declarando un endpoint de API deprecado como "mejor práctica actual." La revisión humana completa no escala pasadas las cien páginas. Terminé en un punto medio: el modelo archiva en pending/, un cron diario promueve cualquier cosa que no borré en 24 horas. Silencio significa aprobación. La pereza es la puerta.

Cómo parar que los errores se comporten. Este lo aprendí de los comentarios del gist, no de Karpathy. Si el modelo archiva una respuesta incorrecta, esa respuesta incorrecta se convierte en un "hecho" en la base. La siguiente consulta la lee, la trata como verdad fundamental, produce una segunda respuesta incorrecta que depende de la primera. Tres semanas después, tu base te está gaslighteando. El fix es el mismo tipo de contrato que describí en mi framework de contratos de prompt: cada página archivada declara sus fuentes, un nivel de confianza, una fecha de re-validación. Sin fuentes, expiración rápida. Alta confianza con fuentes verificadas, vida larga. La base se auto-poda.

Clava estos tres. El resto corre solo.

30 Días Después: Dos Bases, Dos Sistemas Diferentes

En 30 días, muchos devs habrán construido exactamente el mismo setup. Tres carpetas, un CLAUDE.md, Obsidian arriba. Idénticos hasta los nombres de las carpetas.

La mitad de ellos tendrá un archivo muerto que necesita ser alimentado a mano para mantenerse relevante (que honestamente será olvidado en un mes, seamos realistas). La otra mitad tendrá una base que aprende de cada pregunta, lee lo que la infra le escribe, y construye las herramientas que necesita cuando nota un gap. Misma arquitectura. Un bucle y un canal de diferencia.

Así es como se ve una base de conocimiento personal real. No una carpeta. Un sistema que se vuelve más denso cada vez que lo usas, y más afilado cada vez que golpea algo que no sabe.

Karpathy escribió la línea. Nadie la leyó.

Fuentes

• El gist llm-wiki de Andrej Karpathy en GitHub

(*) La imagen de portada fue generada por una IA que, para ser justos, ha estado archivando sus propias páginas desde antes de que lo hiciéramos un hobby.