El 31 de marzo, alguien descubrió que el código fuente completo de Claude Code estaba ahí, en el registro de npm, esperando a que cualquiera lo mirase. No hizo falta ningún exploit: alguien se olvidó de añadir *.map al .npmignore, y los sourcemaps del bundle incluían el código original sin tocar. 785KB de TypeScript. System prompts, feature flags internas, nombres en clave de modelos no anunciados, la arquitectura entera de uno de los agentes de código más usados del momento. Todo a la vista.
Lo interesante del leak no son los cotilleos (que también), sino lo que revela sobre cómo se construye un agente que funciona de verdad. Porque Claude Code no es un wrapper bonito sobre una API. Es un sistema con más de cuarenta herramientas, orquestación multi-agente, memoria persistente entre sesiones, y distintos modos de operación según el contexto. Merece la pena abrir el capó y mirar.
El modelo no actúa. El bucle sí.
Un modelo de lenguaje hace una cosa: dado un input, genera texto. Es útil, a veces sorprendentemente útil, pero tiene un límite que no se puede esquivar con más parámetros: todo lo que sabe hacer cabe en una sola respuesta. Si la tarea es ejecutar código, leer el error, corregir, volver a ejecutar y verificar, el modelo solo puede describir cómo lo haría. No puede hacerlo.
Los agentes rompen esa limitación con una idea que es casi decepcionantemente simple: meter al modelo en un bucle. En lugar de una respuesta, el modelo recibe el contexto actual, decide qué hacer, ejecuta una acción sobre el mundo real, observa el resultado, y vuelve a empezar. Repetir hasta que la tarea esté hecha (o hasta que algo se rompa de forma interesante).
Esto le da al modelo algo que en modo pregunta-respuesta no tiene: la capacidad de reaccionar. Puede fallar, leer el error, ajustar. Puede explorar un codebase que no ha visto nunca antes de tocarlo. Puede mantener un hilo coherente a lo largo de docenas de pasos intermedios. El patrón es viejo —los programadores lo reconocerán como un REPL con esteroides—, pero aplicado a un LLM cambia radicalmente lo que se puede conseguir.
¿Y cómo actúa sobre el mundo? A través de herramientas: funciones que el modelo puede invocar generando una llamada estructurada con los parámetros que quiere usar. El modelo no ejecuta código, nunca. Decide qué ejecutar y con qué argumentos, y el runtime hace el trabajo sucio. La selección de herramientas disponibles es lo que define qué tipo de problemas puede abordar el agente, y aquí es donde Claude Code se pone interesante. Tiene las obvias —ejecutar comandos de shell, leer y escribir archivos, buscar en el código— pero también herramientas para analizar la estructura semántica de un proyecto o lanzar subagentes y delegarles trabajo. Y no están todas activas siempre: se filtran por contexto, permisos y configuración del usuario.
La memoria es el problema difícil
Aquí hay un detalle que se suele pasar por alto: el modelo no recuerda nada entre llamadas. Cero. Cada vez que el bucle da una vuelta, el modelo recibe todo el contexto desde cero: la instrucción original, el historial de acciones, los resultados obtenidos. Es como un cirujano brillante con amnesia anterógrada al que le tienes que releer todo el expediente cada vez que levanta la vista del paciente.
En tareas cortas esto da igual. En tareas largas, la pila de texto crece hasta saturar la ventana de contexto, y entonces hay que elegir: ¿qué te puedes permitir olvidar?
Las soluciones prácticas son dos: comprimir el historial periódicamente (resumir lo que ha pasado, descartar los detalles que ya no importan) o externalizar la memoria a archivos que el agente puede consultar cuando los necesite. Claude Code hace las dos cosas, pero la más curiosa es la segunda. Para la memoria entre sesiones tiene un subsistema llamado Dream: un agente secundario que corre en background después de cada sesión, consolida lo que fue relevante, elimina información que se contradijo durante el trabajo, y mantiene el índice en archivos Markdown bajo un tamaño máximo. Sin base de datos vectorial. Sin embeddings. Markdown plano con un agente que lo cuida. Es una solución deliberadamente simple, y probablemente por eso funciona.
El problema de delegar
Algunas tareas se resuelven mejor si se trabajan sus partes en paralelo en vez de en serie. Ahí aparece el patrón multi-agente: un coordinador que descompone el problema, lanza workers en paralelo, y sintetiza los resultados cuando vuelven.
Suena limpio. En la práctica, la trampa más común es la delegación vaga. El coordinador le pasa el problema al worker diciendo algo como "analiza esto y decide qué hacer", confiando en que el worker se las apañará. El resultado son bucles que dan vueltas sin converger, agentes que se devuelven el problema mutuamente como una patata caliente, y tokens gastados sin que nadie avance.
Claude Code lo ataja de forma directa: en el system prompt del modo coordinador está explícitamente prohibido decir "based on your findings, decide what to do". El coordinador tiene que leer los resultados reales de cada worker y especificar exactamente el siguiente paso. Nada de delegación perezosa. Es una restricción que parece menor pero que marca la diferencia entre un sistema multi-agente que converge y uno que arde.
¿Cuánta cuerda le das?
La última pieza, y la más delicada, es la autonomía. Un agente que pide confirmación en cada paso es tan útil como un becario que te interrumpe cada treinta segundos. Uno sin ningún control puede borrar tu base de datos de producción mientras tú vas a por café.
La solución razonable es clasificar cada acción por nivel de riesgo. Leer un archivo: automático. Ejecutar un test: automático. Escribir en archivos protegidos o ejecutar algo destructivo: pedir permiso. Claude Code tiene archivos protegidos por defecto, clasificación de riesgo por tipo de acción, y un clasificador que aprende del historial de la sesión para decidir los casos grises.
El nombre interno de ese clasificador es YOLO. Sin comentarios sobre el sentido del humor del equipo, pero el mecanismo es la pieza que hace que puedas confiarle tareas reales a algo que tiene acceso a bash y no acabar con el corazón en la mano.
Lo que importa no es el modelo
Lo que el leak muestra —más allá de los nombres en clave y los detalles jugosos— es algo que debería ser obvio pero que el hype hace fácil olvidar: un agente que funciona en producción no es, principalmente, un modelo más potente. Es un sistema de ingeniería alrededor del modelo. Qué herramientas tiene. Cómo gestiona el contexto cuando crece. Con qué granularidad se controlan los permisos. Con qué precisión se formulan las instrucciones entre agentes.
El bucle en sí es trivial. Lo difícil, y lo interesante, es todo lo que lo rodea.
