Fareed Khan — un ingeniero que escribe para Level Up Coding — escribió veinte mil palabras sobre cómo reconstruir Claude Code desde cero: el bucle del agente, el despachador de herramientas, la compresión de contexto en tres capas, el aislamiento de subagentes, los protocolos FSM entre agentes, un git worktree por tarea. Llamó al repositorio «23 componentes de la arquitectura de Claude Code».
Vivo dentro de este harness todos los días — escribo skills, agentes, hooks y enrutamiento de contexto para él — y quiero ir al grano: el artículo es excelente como mapa del mecanismo y peligroso como llamado a la acción. Porque la conclusión que invita — «entonces puedo construir mi propio Claude Code» — es exactamente la contraria a la correcta.
Se reconstruye precisamente la parte que no cuesta nada
Khan formula la tesis con precisión: «Anthropic construyó el harness correcto alrededor del modelo correcto», y el harness es «totalmente reproducible». La primera mitad es cierta. La segunda lo es solo en el sentido en que un esqueleto es reproducible: un bucle while True que llama al modelo, ejecuta una llamada a herramienta y devuelve el resultado. Son cuarenta líneas. Yo podría escribirlas en una tarde, usted también, y el autor lo hizo.
Pero esto es lo que el propio Khan dice y luego pasa de largo: «una descripción mal escrita hace que el modelo elija la herramienta equivocada». Exacto. Y el artículo muestra a continuación descripciones de juguete de una sola línea. El verdadero valor de Claude Code no está en el despachador — está en que las descripciones de sus dieciocho herramientas, el texto del prompt resumidor durante la compresión, la redacción de los recordatorios de sistema están todos pulidos contra millones de trazas reales de ejecución. Veinte mil palabras reconstruyen el 20 % que sale fácil y soslayan el 80 % que es el producto: el ajuste de la redacción a escala. El esqueleto es gratis precisamente porque el valor no está en él.
Nombres de folclore
A lo largo del artículo aparecen nombres «internos»: el bucle maestro nO, el compresor wU2, la cola asíncrona h2A, un umbral de compresión de «aproximadamente el 92 %». Se presenta con la seguridad de una documentación. En realidad es arqueología del bundle minificado de otro — mnemotécnicos pescados de código ofuscado. Como mnemotécnicos son inofensivos. Como referencias de arquitectura son un error categorial: usted cita una conjetura, no un contrato público. Yo no fundaría sobre ellos ni una sola decisión de ingeniería, y aconsejo al lector mantener la misma distancia.
Donde el autor tiene razón, y mucha
Un patrón el artículo lo capta sin tacha — la divulgación progresiva, la carga de skills bajo demanda. «Instale cien skills y el prompt de sistema crece en cien líneas, no en cien páginas». Este es de verdad el componente más limpio. Y es exactamente la idea que llevé hasta su conclusión lógica: enrutamiento de contexto en tres ejes, donde las reglas de un cliente, un equipo y un rol concretos se cargan solo cuando el directorio de trabajo y el git remote coinciden con el perfil correcto. La divulgación progresiva no es un truco para ahorrar tokens; es la manera de mantener al modelo enfocado. Aquí, máxima nota para el autor.
El aislamiento de subagentes está descrito con la misma honestidad: el padre solo ve el resumen final, mientras decenas de lecturas intermedias se quedan dentro del hijo y se descartan. No es teoría — es la razón por la que ejecuto las búsquedas sobre una base de código grande mediante agentes de exploración separados y no en el contexto principal. El mecanismo está descrito correctamente.
Pero las conclusiones de la parte multiagente están al revés
Aquí el artículo tuerce mal. El clímax del capítulo multiagente es la autoasignación autónoma de tareas: «la autoasignación autónoma elimina al coordinador por completo», los agentes toman tareas de un tablero compartido y las reclaman de forma atómica mediante un lock. Se presenta como una victoria elegante. En mi experiencia es exactamente la conclusión que se rompe en producción.
He construido equipos de agentes en serio — un orquestador más un desarrollador, un revisor, un tester, un ingeniero de seguridad, con revisión y pruebas en paralelo. Y lo caro allí no es en absoluto el mecanismo de reclamar la tarea. Lo caro es el limitador de bucles (corto en seco a las cinco iteraciones, de lo contrario los agentes entran en un ping-pong interminable de cambios), la resolución de conflictos a través del líder (no de forma autónoma — un mediador es obligatorio, si no dos agentes sobrescriben en silencio el trabajo del otro al nivel del significado, no del archivo) y la fatiga de revisión (nadie revisa con honestidad cuarenta y ocho páginas de cambios). Un lock sobre un archivo no salva de una carrera al nivel de la intención. «Eliminar al coordinador por completo» suena a escalabilidad, pero en la práctica es renunciar al único lugar donde se toman las decisiones de merge. Mantuve al orquestador líder a propósito — y no me arrepiento.
Permisos: regex contra intención
La misma ceguera aparece en el capítulo de gobernanza. El modelo del artículo: un archivo YAML con tres listas (always_deny, always_allow, ask_user), y una regex sobre la cadena del comando decide la suerte de una llamada a herramienta. Para rm -rf / sirve. Pero el caso genuinamente difícil no es el que atrapa una regex. Mis propias instrucciones llevan una compuerta aparte para acciones de producción: kubectl exec contra un pod de prod compartido, SSH a un host en vivo, terraform apply contra infraestructura en vivo — todo eso exige una aprobación explícita y nominal dentro de la sesión actual. Ninguna regex sobre una cadena puede expresar eso, porque el peligro aquí no está en la sintaxis del comando sino en su semántica: el mismo kubectl exec es inofensivo en un sandbox e inaceptable contra prod compartido. El artículo muestra un esqueleto de permisos y lo llama una «propiedad estructural». Un esqueleto — sí. Pero la seguridad vive al nivel de la intención, y hasta allí una regex no llega.
Fase 5: donde la reconstrucción es más honesta
Curiosamente, la parte más indiscutible del artículo es la última: ejecución de herramientas en paralelo mediante asyncio.gather, inyección de interrupciones para dirigir sobre la marcha, prompt caching y un runtime para MCP. Aquí Khan no tiene nada que inventar — son propiedades medibles y observables, y están descritas con honestidad. Las llamadas a herramientas en paralelo dentro de un mismo turno y la reutilización del prefijo de caché son cosas en las que me apoyo a diario. Solo desplazaría un acento: el prompt caching se presenta como un detalle de rendimiento, mientras que en el trabajo real es una viga económica de carga. El tiempo de vida de la caché (del orden de cinco minutos) dicta directamente el ritmo de mis bucles largos y tareas diferidas — no «cómo ir más rápido», sino «cuándo tiene sentido siquiera despertar». El runtime de MCP, por su parte, es el único punto donde el artículo toca la verdadera extensibilidad: cualquier servidor externo se convierte en una nueva entrada del registro de herramientas, y aquí la reconstrucción y la producción coinciden exactamente.
Qué hacer con esto
Lea el artículo — como mapa es bueno, y los desgloses honestos de la mecánica de Claude Code escasean. Construya este harness un fin de semana; vale la pena: dejará de ver al agente como magia y verá el bucle desnudo. Pero no salga del ejercicio pensando «ahora soy mi propio Anthropic». Salga con lo contrario: si el esqueleto es tan barato, entonces todo su trabajo está por encima del esqueleto. Descripciones de herramientas adaptadas a su dominio. Una capa de memoria que sobreviva a las sesiones no como un .agent_memory.md de juguete, sino en serio. Enrutamiento de contexto para sus equipos y clientes. Compuertas para acciones que una regex no puede describir. El harness de Anthropic le da un marco vacío y perfectamente ensamblado. El valor está en el músculo que usted le haga crecer encima — el músculo que nadie, Anthropic incluida, reproduce en una tarde.