En otro artículo expliqué qué es un harness: la capa de software que envuelve a un modelo para convertirlo en agente, con su bucle, sus herramientas, su gestión de contexto y sus límites. Ahí lo conté en abstracto, válido para cualquier agente. Aquí lo cuento en un caso que casi todos los que leéis esto usáis a diario: Claude Code. Si no has leído la base conceptual, empieza por ahí: Qué es un harness en IA.
Claude Code tiene una particularidad que lo hace ideal para este despiece: podemos hablar de sus tripas con precisión poco habitual. Por un lado, Anthropic documenta abiertamente su arquitectura y la define, con esa palabra exacta, como "el harness agéntico alrededor de Claude". Por otro, en marzo de 2026 su código fuente quedó expuesto por un fallo de empaquetado, y la comunidad lo analizó a fondo durante semanas. Tenemos, por tanto, dos fuentes: lo que Anthropic cuenta y lo que se vio por dentro. Las distingo a lo largo del texto, porque no tienen el mismo valor.
Antes de empezar: versiones y una advertencia
Claude Code cambia rápido y sus versiones avanzan deprisa; además hay piezas en research preview que pueden cambiar o desaparecer. Los detalles que vienen de la documentación oficial son los más estables. Los que vienen del análisis del código filtrado son aproximados y corresponden a la versión 2.1.88, la que se expuso en marzo de 2026, así que conviene tomarlos como una foto de ese momento y no como una especificación vigente.
Y una advertencia que toca dar: el código que se filtró sigue siendo propietario. Circulan repositorios y forks que dicen ser "Claude Code liberado"; muchos están troyanizados. No los clones ni los ejecutes. Lo que aquí interesa es entender la arquitectura, no correr código de dudosa procedencia.
El bucle: lo que de verdad pasa cuando le pides algo
El núcleo de Claude Code es el mismo bucle que tiene cualquier agente. Anthropic lo describe en tres fases que se entremezclan: reunir contexto, actuar y verificar. Le das una tarea, el modelo razona qué necesita, pide usar una herramienta, el harness la ejecuta, le devuelve el resultado, y vuelta a empezar. El ciclo termina cuando el modelo responde sin pedir ninguna acción más.
Quien lleva el volante es el modelo. El código que rodea al bucle no decide qué fichero leer ni qué comando ejecutar; solo ejecuta lo que el modelo pide y le devuelve el resultado. Por eso un mismo Claude Code se comporta de forma distinta según el modelo que elijas: Sonnet resuelve bien la mayoría del trabajo de código, y Opus aporta más capacidad de razonamiento para decisiones de arquitectura. Cambias de uno a otro con /model en mitad de la sesión, y el bucle es idéntico; lo que cambia es quién razona dentro.
Aquí entra el primer hallazgo del código filtrado, y conviene marcarlo como lo que es: análisis de la comunidad, no cifra publicada por Anthropic. Quienes revisaron las casi 2.000 ficheros de TypeScript y las más de 512.000 líneas que se expusieron coinciden en algo que sorprende: el bucle "inteligente" en sí es minúsculo, unas pocas decenas de líneas, con el historial de mensajes como único estado real. Todo el peso del código está en lo que rodea a ese bucle. Una de las lecturas más citadas estimaba que en torno al 98% del código es infraestructura determinista —validación de permisos, gestión de contexto, enrutado de herramientas, recuperación de errores, persistencia— y apenas un porcentaje mínimo es la lógica que delega la decisión en el modelo. La proporción exacta da igual; la idea de fondo es la que vale: la inteligencia la pone el modelo, la fiabilidad la pone esa infraestructura "aburrida" que casi nadie ve.
Las sesiones, por cierto, se guardan en local. Cada mensaje, uso de herramienta y resultado se escribe en un fichero JSONL bajo ~/.claude/projects/, en texto plano. Eso es lo que permite retomar una sesión con claude --resume, bifurcarla o rebobinar. Cada sesión nueva arranca con la ventana de contexto limpia, sin el historial de las anteriores.
Las herramientas: cinco familias y una puerta abierta
Sin herramientas, el modelo solo escribe texto. Las que trae Claude Code de fábrica se agrupan en cinco familias: operaciones con ficheros (leer, editar, crear, reorganizar), búsqueda (encontrar ficheros por patrón, buscar contenido con regex), ejecución (lanzar comandos, arrancar servidores, correr tests, usar Git), web (buscar, traer documentación, mirar un mensaje de error) e inteligencia de código (ver errores de tipo tras una edición, saltar a definiciones, encontrar referencias; esta última requiere un plugin que conecta por LSP). Por encima de esas cinco, el modelo dispone de herramientas de orquestación, como lanzar subagentes o hacerte una pregunta.
La puerta abierta es MCP, el protocolo para conectar herramientas externas. Conectas un servidor MCP —tu base de datos, un sistema de tickets, una API interna— y sus herramientas aparecen en la lista que ve el modelo. Y aquí está lo elegante: desde el punto de vista del bucle, una herramienta de un servidor MCP es indistinguible de una herramienta nativa. El modelo ve una función que puede llamar; de dónde sale es irrelevante para la mecánica. Eso convierte a Claude Code en algo extensible sin tocar su núcleo.
Hay un detalle de contexto que importa y que está documentado: las definiciones de las herramientas MCP no se cargan enteras de entrada. Por defecto se difieren y se cargan bajo demanda mediante una búsqueda de herramientas, de modo que solo los nombres ocupan contexto hasta que el modelo usa una en concreto. Puedes ver cuánto cuesta cada servidor con /mcp. Esto enlaza directamente con el problema más difícil de todos.
El contexto: el recurso por el que se pelea todo
La ventana de contexto es finita, y en Claude Code se llena rápido: dentro va el historial de la conversación, el contenido de los ficheros leídos, la salida de los comandos, las instrucciones del sistema, tu CLAUDE.md, la memoria automática y las skills cargadas. Gestionar ese presupuesto es donde más se nota la diferencia entre un harness bueno y uno mediocre, y Claude Code dedica a ello una parte enorme de su código.
Cuando la ventana se acerca al límite, compacta de forma automática. La documentación lo explica en orden: primero descarta las salidas de herramientas más antiguas, y si hace falta más sitio, resume la conversación. Se conservan tus peticiones y los fragmentos de código clave; las instrucciones detalladas que diste al principio pueden perderse por el camino. De ahí una regla práctica que repiten en la propia documentación: lo que tiene que sobrevivir a toda la sesión no se deja en la conversación, se pone en CLAUDE.md, que se recarga siempre. La conversación es volátil; CLAUDE.md, no. Puedes inspeccionar qué está ocupando espacio con /context y forzar una compactación enfocada con /compact.
El análisis del código filtrado dejó ver hasta dónde llega este diseño. La compactación no es una sola operación, sino varias capas que se aplican de la más barata a la más cara: recortar resultados de herramientas demasiado grandes, tirar mensajes antiguos enteros, y solo al final resumir con una llamada al modelo. Y hay un cortocircuito: si un único fichero o salida es tan grande que el contexto se vuelve a llenar justo después de cada resumen, el sistema deja de intentarlo tras unos pocos intentos en lugar de quedarse en un bucle infinito, y te muestra un error. Es exactamente el tipo de lógica defensiva que no se ve en una demo pero decide si el agente aguanta una sesión larga.
La memoria automática merece mención aparte, porque su diseño fue de lo más comentado tras la filtración. Según esos análisis de la comunidad, en lugar de guardarlo todo y recuperarlo después, Claude Code mantiene un índice ligero —un MEMORY.md de punteros, no de datos— permanentemente en contexto, y el conocimiento real vive en ficheros por tema que se traen solo cuando hacen falta. La documentación oficial confirma la parte visible: las primeras 200 líneas o 25 KB de ese índice, lo que llegue antes, se cargan al inicio de cada sesión. La idea de fondo es tratar la propia memoria como una pista que hay que verificar, no como una verdad, para que el modelo no contamine su contexto con intentos fallidos.
Las skills y los subagentes son las otras dos piezas de gestión de contexto, y atacan el mismo problema desde ángulos distintos. Una skill es una carpeta de instrucciones que se carga bajo demanda: el modelo ve solo su descripción al arrancar la sesión, y el contenido completo entra en contexto únicamente cuando la skill se usa. Un subagente va más allá: recibe un encargo, lo resuelve en su propia ventana de contexto aislada y devuelve solo un resumen, de modo que todo el detalle de su trabajo no ensucia la conversación principal. Por eso delegar en subagentes ayuda en sesiones largas: el coste de su trabajo no lo pagas en tu propio contexto.
Los límites: dónde decides tú
Un agente que edita ficheros y ejecuta comandos puede hacer estropicios. Claude Code mete el control en dos sitios.
El primero son los permisos. Con Shift+Tab recorres los modos: el normal, en el que pide confirmación antes de editar ficheros y lanzar comandos; uno que acepta ediciones y comandos comunes de sistema de ficheros sin preguntar, pero sigue parando para el resto; un modo de planificación, en el que explora y propone un plan sin tocar tu código; y un modo automático con comprobaciones de seguridad en segundo plano, todavía en research preview. Además puedes permitir comandos concretos de antemano en .claude/settings.json para que no pregunte cada vez:
{
"permissions": {
"allow": ["Bash(npm test)", "Bash(git status)"]
}
}Esas reglas se pueden definir desde una política de toda la organización hasta una preferencia personal, con la organización mandando por encima del individuo. Es la pieza donde vive tu autoridad sobre el agente, y es justo la que la industria mira con más cuidado: cuanta más autonomía, más peso tiene el sistema de control alrededor del modelo.
El segundo son los checkpoints. Antes de editar cualquier fichero, Claude Code guarda una instantánea de su contenido. Si algo sale mal, pulsas Esc dos veces y rebobinas, o se lo pides directamente. Es local a tu sesión y separado de Git, y solo cubre cambios en ficheros: lo que toca sistemas externos —una base de datos, una API, un despliegue— no se puede deshacer así, y por eso el agente pregunta antes de ejecutar comandos con efectos fuera de tu disco. La asimetría es deliberada: lo reversible se hace sin fricción, lo irreversible pasa por ti.
La filtración que nos dejó verlo todo
Buena parte de lo que se ha contado aquí sobre las tripas no salió de un blog de Anthropic, sino de un accidente. El 31 de marzo de 2026, un investigador de seguridad avisó en X de que el paquete de npm de Claude Code, en su versión 2.1.88, se había publicado con un fichero de source map de casi 60 MB. Ese fichero, pensado para depurar, bastaba para reconstruir el código fuente completo: cerca de 2.000 ficheros de TypeScript y más de 512.000 líneas. En cuestión de horas estaba replicado en GitHub y siendo diseccionado por miles de desarrolladores.
La causa fue una cadena de descuidos de empaquetado: el bundler generaba los source maps incluso en producción por un bug conocido, y nadie había excluido los ficheros .map al publicar. Anthropic retiró el paquete y dio una explicación escueta: fue un problema de empaquetado por error humano, no una brecha de seguridad, y según su comunicado no se expuso ningún dato ni credencial de clientes. Conviene tener clara la distinción: no se filtraron los pesos del modelo ni datos de usuarios; se filtró el harness, el cliente que envuelve al modelo.
Para quien estudia agentes, ese cliente era un manual de referencia: la lógica de orquestación, la estructura de los system prompts, cómo se aplican las defensas contra inyección de prompts, el diseño de la memoria. Y ahí está el lado de seguridad: conocer por dentro cómo decide el harness facilita atacarlo. Si sabes dónde y cómo se aplican las defensas, es más fácil buscar un hueco; si conoces los prompts del sistema, un repositorio malicioso puede redactarse para colar instrucciones antes de que veas siquiera una pregunta de permiso. Por eso la lección práctica no es alarmarse, sino endurecer la postura: cuidado con apuntar el agente a repositorios o plugins en los que no confías.
Qué te llevas de todo esto
El primer artículo te daba un mapa con cuatro casillas: bucle, herramientas, contexto y límites. Lo que hace Claude Code es rellenar esas casillas con piezas concretas, y entenderlas cambia cómo lo usas.
Cuando el agente falle —y va a fallar—, deja de pensar "el modelo es tonto" y mira la casilla que toca. ¿Se está olvidando de algo que le dijiste hace rato? Es contexto: revisa qué se compactó con /context y mueve esa instrucción a CLAUDE.md. ¿Le falta poder hacer algo? Es herramientas o permisos: igual necesitas conectar un servidor MCP o permitir un comando en settings.json. ¿Se está liando en una tarea enorme? Es contexto otra vez: parte el trabajo y delega trozos en subagentes para que cada uno traiga solo su resumen. Casi ningún problema de los que verás a diario se arregla esperando a un modelo mejor; se arregla ajustando el harness, que es la parte sobre la que tienes control.
Sobre hacia dónde va esto, un apunte sin exagerar. Claude Code ya experimenta con flujos en los que el propio modelo escribe un script de orquestación que reparte trabajo a un gran número de subagentes en paralelo, con el estado intermedio guardado fuera de la ventana de contexto; es research preview y cambiará. Y en el terreno de la investigación, la frontera de 2026 es el harness que se optimiza a sí mismo: sistemas que, manteniendo el modelo fijo, ajustan de forma automática las piezas del arnés guiándose por observabilidad. Pero eso es otro artículo.
La conclusión es la misma que en la base conceptual, ahora con las piezas concretas: el modelo marca el techo de lo que Claude Code puede hacer; el harness decide cuánto de ese techo aprovechas. Si todavía te falta la parte conceptual, está aquí: Qué es un harness en IA.
Rutas de aprendizaje
