← Blog

Arquitectura de Claude Code en profundidad: Lo que revela el código fuente filtrado

El código fuente filtrado de Claude Code expuso 512K líneas de TypeScript en producción. Aquí está el análisis completo de la arquitectura: sistema de herramientas, motor de consultas, patrones multiagente y compresión de contexto.

11 min read
Arquitectura de Claude Code en profundidad: Lo que revela el código fuente filtrado

Hola a todos, soy Dora. No estaba buscando meterme en un laberinto en marzo de 2026. Un mensaje apareció en mi feed: “El código fuente de Claude Code ha sido filtrado a través de un archivo map en su registro npm.”

Cerré la pestaña en la que estaba y no volví a mirar atrás.

Lo que siguió fue una de las tardes más genuinamente interesantes que he pasado estudiando cómo se construye realmente una herramienta de IA en producción. No por el drama de la filtración —eso cansa rápido— sino porque el código es algo poco común: un CLI agéntico real, publicado y comercialmente dominante, examinado con 512.000 líneas de detalle.

Esto es lo que noté.

Por Qué el Código Fuente Filtrado Es una Rara Oportunidad de Estudio de Arquitectura

Después de que se filtró Claude Code, el código fuente salió a la luz —expuesto a través de un archivo .map mal configurado en el propio paquete npm de Anthropic— los desarrolladores rápidamente se dieron cuenta de que esto no era un envoltorio alrededor de una API de chat. Según el análisis de cybersecuritynews.com sobre el incidente, la exposición incluía aproximadamente 1.900 archivos y más de 512.000 líneas de TypeScript estricto, con el punto de entrada principal pesando 785KB por sí solo.

El stack en sí ya es interesante: Bun como runtime (no Node.js), React con Ink para el renderizado de la UI en terminal, y Zod v4 para la validación de esquemas en todo el código. Usar patrones de componentes React en un CLI significa gestión de estado, rerenderizados y componentes de UI componibles dentro de tu terminal. Es una elección deliberada y audaz.

Lo que hace que esto valga la pena estudiar más allá de los memes: los patrones de arquitectura de Claude Code aquí se aplican a cualquier equipo que construya sistemas agénticos serios.

El Sistema de Herramientas — Más de 40 Módulos Autocontenidos con Control de Permisos

Lo primero que me llamó la atención fue lo limpiamente aislado que está el sistema de herramientas. Cada herramienta define su propio esquema de entrada, nivel de permiso y lógica de ejecución — de forma independiente. No hay estado mutable compartido filtrándose entre herramientas.

BashTool y FileReadTool están en el mismo registro pero tienen perfiles de riesgo fundamentalmente diferentes. La ejecución de Bash puede alterar el estado del sistema; la lectura de archivos es de solo lectura. La arquitectura los trata en consecuencia, protegiendo cada uno detrás de su propio nivel de permiso en lugar de aplicar una política general. Esa separación importa enormemente en sistemas agénticos de producción, donde un modelo de permisos que se filtra entre herramientas es un problema de seguridad y fiabilidad esperando a ocurrir.

AgentTool es el inteligente. Permite al sistema generar sub-agentes como una simple llamada a herramienta — sin capa de orquestación especial requerida, sin modelo de proceso separado. Los sub-agentes son ciudadanos de primera clase del mismo registro de herramientas. Esa decisión de diseño mantiene la arquitectura plana y predecible.

La definición base de herramienta sola abarca alrededor de 29.000 líneas de TypeScript. Eso no es código inflado — eso es lo que la validación rigurosa de esquemas, la aplicación de permisos y el manejo de errores realmente parecen a esta escala. La documentación oficial de Claude Code de Anthropic confirma esta filosofía centrada en herramientas: las herramientas son lo que hace que el sistema sea agéntico en absoluto.

El Motor de Consultas de 46K Líneas — El Verdadero Cerebro de Claude Code

QueryEngine.ts tiene 46.000 líneas. Deja que eso asiente por un momento.

Este es el módulo que maneja todas las llamadas a la API LLM, streaming, caché y orquestación. En un solo archivo. Eso podría sonar como una señal de alerta — y dependiendo de las convenciones de tu codebase, tendrías razón en cuestionarlo — pero el razonamiento es coherente: todo lo que toca la API del modelo está en un solo lugar, lo que significa que la lógica de reintentos, el manejo de límites de velocidad, la gestión del presupuesto de contexto y los errores de streaming se razonan todos juntos.

El bucle de consulta autocurativo es la parte que me sorprendió. Cuando el presupuesto de contexto se acerca a su límite, el motor no falla ni pide ayuda. Activa la compresión automáticamente, reservando un buffer antes del techo y generando un resumen estructurado de lo que se ha discutido. Eso no es un truco — es comportamiento diseñado. Para cualquiera que construya sesiones de agentes de larga duración, este patrón vale directamente la pena estudiarlo.

Orquestación Multi-Agente — Coordinador, Trabajadores y el Patrón de Buzón

El sistema multi-agente usa lo que el código fuente filtrado llama un patrón de buzón para operaciones peligrosas. Esto es lo que significa en la práctica: un agente trabajador ejecutando una tarea no puede aprobar independientemente una operación de alto riesgo. En cambio, envía una solicitud al buzón del coordinador y espera. El coordinador evalúa y aprueba o rechaza.

El mecanismo de reclamación atómica evita que dos trabajadores manejen la misma aprobación simultáneamente — un detalle sutil pero crítico en cualquier sistema con ejecución paralela. El espacio de memoria compartida entre todos los agentes significa que el equipo mantiene un contexto coherente sin volver a buscar redundantemente.

Esta es una desviación significativa de los diseños multi-agente ingenuos donde cada agente opera con plena autonomía. La división coordinador/trabajador con puertas de aprobación es cómo se obtiene paralelismo sin caos. Los equipos que construyen capas de orquestación para sus propios sistemas agénticos harían bien en leer la documentación de patrones agénticos de Anthropic antes de diseñar los suyos propios.

Compresión de Contexto en Tres Capas — Ingeniería para Sesiones Largas

Esta es probablemente la pieza de ingeniería más directamente útil de todo el codebase para cualquiera que construya aplicaciones de IA en producción.

Claude Code usa tres estrategias de compresión distintas, cada una activada en un punto diferente:

MicroCompact edita el contenido en caché localmente, sin llamadas a la API. Los resultados de herramientas antiguas se recortan directamente. Rápido, económico, transparente.

AutoCompact se activa cuando la conversación se acerca al techo de la ventana de contexto. Reserva un buffer de 13.000 tokens, luego genera hasta un resumen estructurado de 20.000 tokens de la sesión. Hay un disyuntor integrado — después de tres fallos de compresión consecutivos, deja de reintentar. Sin bucles infinitos.

Full Compact comprime toda la conversación, luego reinyecta los archivos a los que se ha accedido recientemente (limitados a 5.000 tokens por archivo), los planes activos y los esquemas de habilidades relevantes. Después de la compresión, el presupuesto de trabajo se restablece a 50.000 tokens.

Lo notable es lo que esta arquitectura implica para las herramientas que omiten la compresión por completo. Las herramientas agénticas que no gestionan el presupuesto de contexto simplemente fallarán a escala — degradándose silenciosamente o alcanzando errores graves. El enfoque de tres capas es un raro ejemplo de diseño para la longevidad de sesión desde el principio, no añadiéndolo después.

Banderas de Funcionalidad como Arquitectura — 108 Módulos Que No Existen en Producción

Uno de los hallazgos menos discutidos del código fuente filtrado: 108 módulos con control de funcionalidad, eliminados de las compilaciones externas mediante la eliminación de código muerto en tiempo de compilación de Bun.

KAIROS, VOICE_MODE, DAEMON — estos no existen en la versión que instalas. El código está ahí en el código fuente, pero Bun lo elimina en tiempo de compilación según la configuración de la bandera de funcionalidad. El bundle de producción se entrega limpio. Así es como se itera sobre nuevas capacidades sin tocar lo que ya está en manos de los usuarios.

La ironía está bien documentada: el Modo Encubierto, un subsistema diseñado específicamente para evitar que los nombres en clave internos aparezcan en commits de git o salidas, estaba presente en el código fuente filtrado. El sistema construido para prevenir filtraciones no pudo evitar la filtración en sí misma. No es un fallo de seguridad catastrófico, pero sí instructivo sobre dónde se acumula realmente el riesgo en los pipelines de entrega de software.

Telemetría Integrada en el Bucle Principal

Dos señales de telemetría en el código fuente filtrado que no puedo dejar de pensar:

Una métrica de frustración rastrea la frecuencia de blasfemias como señal de UX. Si los usuarios están maldiciendo a la herramienta, algo está fallando — un indicador adelantado, no rezagado.

Un contador de “continuar” rastrea con qué frecuencia los usuarios escriben la palabra “continuar” a mitad de sesión. Para un CLI agéntico, esto es un proxy para los paros — momentos en que el agente perdió impulso y el humano tuvo que empujarlo hacia adelante.

Ninguna es una métrica de vanidad. Ambas revelan modos de fallo específicos que los análisis estándar pasarían por alto. Si estás construyendo cualquier producto de IA con sesiones de interacción extendidas, instrumentar el comportamiento del agente de esta manera vale el tiempo de ingeniería.

Lo Que Esto Le Dice a los Constructores Sobre las Decisiones de Stack

La conclusión honesta de estudiar esta arquitectura de claude code: construir un CLI agéntico de producción desde cero es un compromiso de ingeniería sustancial. El sistema de herramientas, el motor de consultas, la orquestación multi-agente, la compresión de contexto y la telemetría juntos representan años de iteración, no meses.

Eso no es un argumento en contra de construir. Es un argumento para ser claro sobre lo que estás asumiendo. Patrones como el sistema de aprobación por buzón y la compresión de tres capas son exportables — no necesitas 512.000 líneas para implementar las ideas centrales.

Donde el cálculo de construir-vs-comprar cambia es en el acceso y la agregación de modelos. La arquitectura asume acceso directo a un único proveedor de modelos. Los equipos que trabajan con múltiples proveedores de modelos, o que construyen productos que necesitan permanecer agnósticos al modelo, enfrentan un conjunto de compensaciones completamente diferente.

Los patrones aquí valen la pena tomar prestados. La complejidad vale la pena entenderla antes de comprometerse a replicarla.

Preguntas Frecuentes

¿En qué se diferencia el sistema de herramientas de Claude Code de las llamadas a funciones estándar?

Las llamadas a funciones estándar tratan las herramientas como una lista plana. Claude Code añade puertas de permiso por herramienta, contextos de ejecución aislados y validación de esquemas en cada límite — previniendo la fuga de estado entre herramientas y aplicando el acceso de mínimo privilegio, lo que importa cuando BashTool puede modificar el estado del sistema.

¿Qué es el patrón de buzón y cuándo deben usarlo los constructores?

Enruta las operaciones peligrosas desde los agentes trabajadores a un coordinador para su aprobación, en lugar de ejecutarlas de forma autónoma. Úsalo siempre que tengas ejecución paralela de agentes y necesites un humano en el bucle o un mecanismo de aprobación jerárquica para acciones de alto riesgo. Coste en rendimiento, ganancia en seguridad.

¿Cómo maneja Claude Code los límites de ventana de contexto a escala?

Compresión en tres capas: MicroCompact (ediciones locales, sin coste de API), AutoCompact (activada cerca de los límites, genera un resumen estructurado con buffer de tokens reservado), y Full Compact (compresión de conversación completa con reinyección selectiva de archivos). Diseñado para sesiones largas sin intervención manual.

¿Qué son las banderas de funcionalidad en tiempo de compilación y por qué las usan las herramientas de IA en producción?

Permiten que el código para funcionalidades no publicadas exista en el código fuente sin aparecer en las compilaciones de producción. Bun elimina el código desactivado en tiempo de compilación, de modo que los usuarios externos nunca encuentran funcionalidades que no están listas — separando el envío de la disponibilidad.

¿Es legal estudiar y referenciar el código fuente filtrado para inspiración arquitectónica?

Vale la pena tratarlo con cuidado. El código fuente filtrado es propiedad intelectual de Anthropic. Estudiar patrones arquitectónicos con fines educativos está en un territorio diferente al de copiar código directamente. La documentación oficial de Anthropic sigue siendo la referencia apropiada para cualquier cosa que construyas sobre sus sistemas. En caso de duda, consulta a tu propio asesor legal.

Lo que no puedo dejar de considerar es cuánto de esta arquitectura trata sobre gestionar los fallos con elegancia. Los disyuntores en la compresión, el patrón de buzón para operaciones peligrosas, el aislamiento de permisos entre herramientas — estos no son diseños optimistas. Están construidos por personas que han visto cómo las cosas salen mal y decidieron diseñar alrededor de eso.

Eso es un tipo diferente de madurez que la velocidad de funcionalidades.

Bien, el contenido de hoy ha terminado. Hasta la próxima.

Publicaciones Anteriores: