Claude Code como infraestructura

Andrej Karpathy acuñó un término para lo que crece alrededor de un agente LLM: garras. Los hooks, scripts y la orquestación que permiten al agente aferrarse al mundo fuera de su ventana de contexto.¹ La mayoría de las personas tratan Claude Code como un cuadro de chat con acceso a archivos. Escriben un prompt, observan cómo edita un archivo y siguen adelante. Ese enfoque pasa por alto lo que la herramienta realmente es.

Claude Code no es una función del IDE. Es infraestructura. Y la diferencia entre tratarlo como lo uno o lo otro determina si el desarrollo asistido por IA se queda en ganancias de productividad del 10% o avanza hacia algo fundamentalmente diferente.

TL;DR

Claude Code expone 17 eventos de ciclo de vida, cada uno interceptable con scripts de shell que se ejecutan antes, durante o después de cada llamada a herramienta.² Apile hooks en dispatchers, dispatchers en skills, skills en agentes, agentes en flujos de trabajo, y obtendrá una capa programable entre usted y el modelo que impone restricciones que el modelo no puede eludir. Construí 84 hooks, 48 skills, 19 agentes y ~15.000 líneas de orquestación en dos meses. Cero frameworks. Cero dependencias externas. Todo en bash y JSON. El resultado es un sistema de desarrollo autónomo que escribe, revisa y despliega código mientras duermo. Este artículo explica la arquitectura, por qué el enfoque de IDE limita a las personas, y qué cambia ahora que Remote Control hace esta infraestructura accesible desde cualquier lugar.

El enfoque de IDE es erróneo

El modelo mental por defecto: Claude Code es un autocompletado más inteligente. Usted se sienta frente a una terminal, le asigna tareas y supervisa el resultado. Ese modelo limita su productividad a lo que pueda supervisar personalmente.

El modelo mental de infraestructura: Claude Code es un runtime programable con un kernel LLM. Cada acción que el modelo ejecuta pasa a través de hooks que usted controla. Usted define políticas, no prompts. El modelo opera dentro de su infraestructura de la misma manera que un servidor web opera dentro de las reglas de nginx. Usted no se sienta frente a nginx a escribir solicitudes. Lo configura, lo despliega y lo monitorea.

La distinción importa porque la infraestructura se acumula. Un hook que bloquea credenciales en comandos bash protege cada sesión, cada agente, cada ejecución autónoma. Un skill que codifica su rúbrica de evaluación de blog se aplica consistentemente ya sea que lo invoque usted o un agente. Un agente que revisa código por seguridad ejecuta las mismas verificaciones esté usted observando o no.

Simon Willison enmarca el momento actual en torno a una sola observación: escribir código es barato ahora.³ Correcto. Pero el corolario que nadie quiere escuchar es que la verificación es ahora la parte costosa. Código barato sin infraestructura de verificación produce errores a escala. La inversión que rinde frutos no es un mejor prompt. Es el sistema alrededor del modelo que atrapa lo que el modelo omite.

La capa de infraestructura

El sistema de hooks de Claude Code ejecuta comandos de shell en 17 eventos de ciclo de vida.² PreToolUse se activa antes de que una herramienta se ejecute y puede bloquearla. PostToolUse se activa después y puede proporcionar retroalimentación. UserPromptSubmit se activa cuando usted escribe y puede inyectar contexto. Stop se activa cuando el modelo intenta finalizar y puede forzarlo a continuar. Cada evento recibe JSON en stdin con contexto completo: ID de sesión, nombre de herramienta, entrada de herramienta, directorio de trabajo actual.

El sistema de hooks no es un sistema de plugins. Es una arquitectura orientada a eventos. La diferencia: los plugins extienden las funcionalidades de una herramienta. Los eventos le permiten interceptar, modificar y controlar cada acción que la herramienta ejecuta. Usted se convierte en el middleware.

Hooks: la capa determinista

Los hooks son scripts de shell. No pueden ser alucinados, manipulados ni eludidos mediante inyección de prompts. ¿El modelo quiere ejecutar rm -rf /? Un script bash de 10 líneas verifica el comando contra una lista de bloqueo y lo rechaza antes de que el shell siquiera lo vea. ¿El modelo intenta leer .env? Una expresión regular en la ruta del archivo intercepta la llamada a la herramienta Read. Nada de esto requiere la cooperación del modelo. El hook se activa lo quiera el modelo o no.

Ejecuto 84 hooks en 17 tipos de eventos. La distribución cuenta una historia: 35 imponen criterio (puertas, guardias, validadores) y 49 manejan automatización (inyectores, registradores, rastreadores). Esa proporción comenzó en 1:6. Dos meses de fallos en ejecuciones autónomas la llevaron a 4:5. Cada hook de criterio existe porque algo falló sin él. Un agente hizo commit de código con comentarios TODO. Un agente ejecutó un comando destructivo de git. Un agente filtró una ruta de credenciales en un archivo de registro. Cada fallo recibió una puerta.

La mayor lección: dispatchers en lugar de hooks independientes. Tenía siete hooks activándose todos en UserPromptSubmit, cada uno leyendo stdin de forma independiente, dos escribiendo en el mismo archivo de estado JSON. Las escrituras concurrentes truncaban el JSON. Cada hook posterior que analizaba ese archivo fallaba. Un dispatcher por evento ejecutando hooks secuencialmente desde stdin en caché lo resolvió. Sobrecarga invisible, 200ms por prompt.

Skills: la capa de conocimiento

Los skills son conjuntos de instrucciones en markdown que se activan bajo demanda o mediante hooks.⁴ Cada uno codifica experiencia de dominio que el modelo utiliza al invocarlo. Mi skill blog-evaluator define una rúbrica ponderada de 6 categorías con criterios de puntuación específicos, mínimos por categoría e interdependencias. Mi skill jiro codifica un ciclo de calidad de 7 pasos con una puerta de evidencia que requiere pruebas específicas para cada criterio.

Los skills se componen con los hooks. Un skill puede definir sus propios hooks en el frontmatter que se activan solo mientras el skill se ejecuta. Los skills de filosofía se autoactivan mediante hooks de SessionStart, inyectando restricciones de calidad en cada sesión sin invocación explícita.

48 skills que cubren: calidad de código (jiro, testing-philosophy, debugging-philosophy), contenido (blog-writer-core, blog-evaluator, citation-verifier), arquitectura (fastapi, swiftui, database, htmx-alpine), operaciones (deploy, cache, analytics, security) y meta-orquestación (deliberation, scan-intel, ralph). La investigación sobre las preferencias propias de Claude Code encontró que gravita hacia ciertos frameworks y patrones.⁹ Los skills le permiten anular esos valores predeterminados con los suyos propios.

Agentes: la capa de delegación

Los agentes son subagentes especializados con ventanas de contexto aisladas.⁵ Cada uno recibe una tarea enfocada y contexto limpio. Mi sistema de revisión de código genera tres agentes en paralelo: corrección, seguridad y convenciones. Cada uno revisa de forma independiente. Los desacuerdos entre revisores revelan exactamente los problemas que un solo revisor pasaría por alto.

La restricción crítica: un guardia de recursión. Un script de shell se activa antes de cada llamada a la herramienta Task, verifica un contador de profundidad de generación en un archivo de estado compartido y bloquea la llamada si la profundidad excede un umbral. Sin él, los agentes delegan a agentes que delegan a agentes, cada uno perdiendo contexto y quemando tokens. El límite predeterminado es 3 niveles. En la práctica, el trabajo útil ocurre en la profundidad 1 (agente principal más un subagente). Cualquier profundidad mayor a 2 generalmente significa que la descomposición de la tarea fue incorrecta.

19 agentes que abarcan: desarrollo (ios-developer, backend-architect), revisión (code-reviewer, security-reviewer, conventions-reviewer, yagni-reviewer), exploración (project-scout, code-explorer, code-architect) y validación (test-runner, correctness-reviewer).

Remote Control cambia la ecuación

El 25 de febrero de 2026, Anthropic lanzó Remote Control: la capacidad de conectarse a una sesión local de Claude Code desde cualquier navegador o la aplicación móvil de Claude.⁶ La función obtuvo 531 puntos y 313 comentarios en Hacker News, la mayoría quejas sobre errores. Las quejas son válidas. La función sigue siendo transformadora.

He aquí por qué. Antes de Remote Control, la infraestructura que describí tenía dos modos: supervisado (observo la terminal) o sin supervisión (me alejo y espero lo mejor). Ninguno es ideal. El supervisado limita el rendimiento a mi capacidad de atención. El no supervisado arriesga que el modelo tome malas decisiones que nadie detecta.

Remote Control crea un tercer modo: gobernanza asíncrona. Ejecuto ciclos autónomos que procesan PRDs de múltiples historias durante la noche. Las solicitudes de aprobación para acciones externas (git push, llamadas a API, cualquier cosa que salga de la máquina) llegan a mi teléfono. Apruebo, rechazo o redirijo desde cualquier lugar. La capa de gobernanza permanece igual. La latencia entre “el agente necesita aprobación” y “el humano la proporciona” baja de “cuando reviso mi laptop” a “10 segundos desde mi teléfono.”

El flujo de aprobación se potencia con la clasificación de radio de impacto de mis hooks. Las operaciones locales (escritura de archivos, ejecución de pruebas) se aprueban automáticamente. Las operaciones compartidas (commits de git) advierten. Las operaciones externas (pushes, llamadas a API, despliegues) se difieren a revisión humana. Remote Control convierte esa ruta de “diferir” de una espera bloqueante en una notificación asíncrona. El agente continúa trabajando en la siguiente historia mientras reviso la anterior.

Herramientas como Agent Multiplexer ya gestionan sesiones de Claude Code mediante tmux.¹⁰ Alternativas de código abierto como Emdash proporcionan entornos completos de desarrollo agéntico.¹¹ Las personas que sugieren SSH más tmux como alternativa tienen razón en que funciona para acceso por terminal. Ninguna de estas ofrece el enrutamiento de aprobaciones. Ese enrutamiento es lo que hace que la operación desatendida sea segura, no solo posible.

El costo como arquitectura

El artículo “Making MCP Cheaper via CLI” (304 puntos en HN) documentó un patrón: envolver llamadas de herramientas MCP en invocaciones de CLI para evitar la sobrecarga de mantener una conexión de servidor MCP.⁷ La perspectiva más amplia es que el costo es una decisión arquitectónica, no una consideración operativa posterior.

Mi infraestructura maneja el costo en tres niveles:

Nivel de tokens. Compresión de system prompt. Ejecuto ~3.500 tokens de system prompt entre un archivo CLAUDE.md y 8 archivos de reglas. Los recortes de alto rendimiento: eliminar ejemplos de código tutorial (el modelo ya conoce las APIs), consolidar reglas duplicadas entre archivos y reemplazar explicaciones con restricciones. “Rechazar llamadas a herramientas que coincidan con rutas sensibles” hace el mismo trabajo que una explicación de 15 líneas sobre por qué no se deben leer credenciales. Densidad semántica sobre compresión bruta.⁸

Nivel de agentes. Generaciones frescas en lugar de conversaciones largas. Cada historia en una ejecución autónoma obtiene un nuevo agente con una ventana de contexto limpia. Al momento de generación, el agente recibe un briefing: estado actual de git, qué lograron los agentes anteriores, qué necesita hacer. Briefing en lugar de memoria. Los modelos ejecutan un briefing claro mejor de lo que navegan 30 pasos de contexto acumulado. El contexto nunca se infla porque cada agente comienza desde cero. Geoffrey Huntley documentó un patrón similar en “The Ralph Loop,” ejecutando desarrollo autónomo a $10,42/hora con Sonnet.¹³ Orquestadores multi-agente como OpenSwarm formalizan el pipeline trabajador-revisor con escalamiento de modelos.¹⁴

Nivel de arquitectura. CLI primero sobre MCP cuando la operación no tiene estado. Una llamada claude --print para una evaluación puntual cuesta menos y no agrega sobrecarga de conexión. Un servidor MCP tiene sentido cuando la herramienta necesita estado persistente o streaming. Context Mode demostró lo inverso: comprimir 315 KB de salida MCP a 5,4 KB usando indexación FTS5 con ranking BM25.¹² Ambos enfoques reducen el gasto de tokens, desde direcciones diferentes. La mayoría de mis invocaciones de skills son puntuales. Mi análisis de caché de prompts encontró que el CLI de Claude Code almacena en caché los system prompts por defecto por encima de 4.096 tokens. Sin configuración necesaria.

Caso de estudio: cómo lucen 84 hooks en la práctica

Una traza concreta de sesión de una ejecución autónoma de la semana pasada, procesando un PRD con 5 historias:

1. SessionStart se activa. El dispatcher inyecta: fecha actual, detección de proyecto, restricciones de filosofía, verificación de rendimiento del sistema, inicialización de seguimiento de costos. Cinco hooks, 180ms en total.

2. El agente lee el PRD, planifica la primera historia. UserPromptSubmit se activa en el prompt interno. El dispatcher inyecta: contexto del proyecto activo, línea base de deriva de sesión (embedding Model2Vec del primer prompt para verificaciones posteriores de similitud). 120ms.

3. El agente llama a Bash para ejecutar pruebas. PreToolUse:Bash se activa. El dispatcher ejecuta: verificación de credenciales (sin rutas .env en el comando), validación de sandbox (comando no en lista de bloqueo), detección de proyecto. 90ms. La prueba se ejecuta. PostToolUse:Bash se activa: latido de actividad registrado, verificación de deriva contra la línea base (similitud coseno 0,63, muy por encima del umbral de 0,30).

4. El agente llama a Write para crear un archivo. PreToolUse:Write se activa: verificación de alcance de archivo (¿está esta ruta dentro del directorio del proyecto?). PostToolUse:Write se activa: verificación de lint en el archivo escrito, seguimiento de commit, latido de actividad.

5. El agente finaliza la historia. Stop se activa. El hook de puerta de calidad verifica: ¿citó el agente evidencia para cada criterio? ¿Usó lenguaje dubitativo (“debería”, “probablemente”)? ¿Hay comentarios TODO en el diff? Si alguna verificación falla, el hook retorna exit 2 y el agente continúa trabajando.

6. Verificación independiente: un agente nuevo ejecuta la suite de pruebas sin confiar en el autoreporte del agente anterior.

7. Tres agentes de revisión de código se generan en paralelo. Cada uno revisa el diff de forma independiente. Los hallazgos se fusionan. Si algún revisor marca un problema CRITICAL, la historia regresa a la cola.

8. La historia pasa. La siguiente historia se carga. El ciclo se repite para las 5 historias.

Total de hooks activados en 5 historias: ~340. Tiempo total en hooks: ~12 segundos. Sobrecarga invisible que previno tres fugas de credenciales, un comando destructivo y dos implementaciones incompletas en una sola ejecución nocturna.

Conclusiones clave

Claude Code es un runtime, no una herramienta. Los 17 eventos de ciclo de vida lo hacen programable. Los hooks, skills y agentes son el conjunto de instrucciones. El modelo es el motor de ejecución. Usted es el arquitecto de sistemas.

La gobernanza escala con la automatización. Cada hook que agrega una restricción reduce el riesgo de la operación desatendida. La proporción entre hooks de criterio y hooks de automatización es su margen de seguridad. La mía es 4:5 y sigue creciendo.

La infraestructura se acumula, los prompts no. Un buen prompt mejora una interacción. Un buen hook mejora cada interacción. Un buen skill mejora cada agente que lo invoca. Un buen agente mejora cada flujo de trabajo que le delega. Invierta en la capa que multiplica.

Remote Control hace la infraestructura portátil. El enrutamiento de aprobaciones convierte “sin supervisión” en “supervisión asíncrona.” Esa distinción es la diferencia entre esperar que el modelo tome buenas decisiones y verificar que lo haga.

El costo es arquitectura, no optimización. Generaciones frescas de agentes, invocaciones CLI primero, compresión de system prompt y caché de prompts son decisiones estructurales que se acumulan. Optimizar después del hecho cuesta más que diseñar para ello.

Cero frameworks requeridos. 84 hooks, 48 skills, 19 agentes, ~15.000 líneas de orquestación. Scripts bash en un directorio. Archivos de estado JSON. Sin dependencias de runtime. Puede adoptar un solo hook o la pila completa. La infraestructura crece orgánicamente al resolver problemas reales, no al implementar el framework de alguien más.

Este artículo es parte de la serie AI Engineering. Anteriormente: Why My AI Agent Has a Quality Philosophy. Vea también: Thinking With Ten Brains y The Blind Judge.