La tesis del CLI

Tres hilos de Hacker News en una semana. 1.638 puntos combinados. Una conclusión: el IDE es para humanos. El CLI es para agentes.¹²³

La separación planificación/ejecución de Boris Tane (716 puntos) se ejecuta completamente en la terminal.¹ El análisis “Making MCP Cheaper via CLI” (304 puntos) midió una reducción del 94% en tokens al reemplazar llamadas a herramientas MCP con claude --print.³ El proyecto just-bash de Vercel (87 puntos) demostró que eliminar el 80% de las herramientas de un agente hacía todo más rápido, más económico y más confiable.⁴ Un benchmark separado encontró que los enfoques CLI usan 35 veces menos tokens que MCP para tareas equivalentes.¹⁰

El patrón sigue apareciendo porque la arquitectura lo impone. Los agentes necesitan componibilidad, capacidad de scripting y sobrecarga mínima. Los CLIs proporcionan las tres. Los IDEs no proporcionan ninguna.

TL;DR

La arquitectura de agentes CLI-first cuesta un 94% menos en sobrecarga de tokens que los enfoques basados en MCP, se ejecuta 3,5 veces más rápido y se compone con herramientas Unix estándar. La separación planificación/ejecución funciona porque los artefactos CLI son archivos markdown portátiles, no estado del IDE. Remote Control hace que los agentes CLI sean supervisables remotamente sin sacrificar la ventaja de componibilidad. Todo sistema de agentes serio converge en la terminal porque la terminal es donde la automatización ya vive.

La separación planificación/ejecución

Boris Tane documentó un flujo de trabajo en tres fases que 454 comentaristas de HN validaron con sus propias variaciones: investigar, planificar, implementar.¹ La observación crítica: nunca deje que el agente escriba código hasta que usted haya revisado y aprobado un plan escrito.

El flujo de trabajo produce artefactos markdown en cada etapa. research.md captura el análisis del código base. plan.md captura la estrategia de implementación con fragmentos de código. El desarrollador revisa en su editor, añade anotaciones en línea y envía el plan anotado de vuelta con una instrucción explícita: “no implementes todavía.” El ciclo de anotación se repite de una a seis veces antes de que se escriba una sola línea de código.

Todo el ciclo se ejecuta a través de claude en la terminal. Sin plugin de IDE. Sin herramienta visual de diff. Archivos markdown de entrada, archivos markdown de salida. Los artefactos sobreviven a la compactación de la ventana de contexto porque existen como archivos, no como estado de conversación.

Mi bucle autónomo implementa la misma separación a escala de máquina. Un archivo PRD define historias con criterios de aceptación. Un agente nuevo se genera para cada historia, recibiendo un informe del estado actual de git y lo que los agentes anteriores lograron. El agente implementa, un verificador independiente ejecuta las pruebas (sin confiar nunca en el autoinforme del agente), y tres revisores de código evalúan el diff en paralelo. Toda la orquestación se ejecuta a través de llamadas claude --print en scripts bash. Sin framework, sin runtime, sin servidor.

La separación planificación/ejecución funciona en la terminal porque la terminal hace que la separación sea estructural. La planificación produce archivos. La ejecución consume archivos. El límite entre las dos fases es un archivo en disco, visible y auditable, no una transición de estado enterrada dentro de un plugin de IDE.

Por qué CLI supera al IDE para agentes

El argumento se sustenta en tres pilares: costo, componibilidad y eficiencia de contexto.

Costo: reducción del 94% en tokens

Kan Yilmaz midió la sobrecarga de tokens de MCP frente a CLI en cuatro escenarios.³ Los números cuentan la historia completa:

MCP inyecta esquemas de herramientas en cada conversación. Con 84 herramientas, la sobrecarga de esquemas por sí sola consume 15.540 tokens antes de que el agente haga cualquier trabajo. Las llamadas CLI no tienen sobrecarga de esquemas porque los modelos ya entienden las interfaces de línea de comandos estándar.¹⁰ Un usuario documentó que MCP_DOCKER consumía 125.964 tokens a través de 135 herramientas.¹⁴

Jannik Reinhard ejecutó un benchmark paralelo en una tarea de cumplimiento de Intune: 145.000 tokens vía MCP frente a 4.150 tokens vía CLI para una salida equivalente.¹⁰ El agente CLI tenía el 95% de su ventana de contexto disponible para razonamiento. El agente MCP gastó la mayor parte de su presupuesto en definiciones de herramientas.

Componibilidad: los pipes de Unix ya funcionan

El equipo v0 de Vercel eliminó el 80% de las herramientas de su agente y las reemplazó con un único entorno bash.⁹ Los resultados:

Andrew Qu explicó el razonamiento: “Estábamos resolviendo problemas que el modelo podía manejar por sí solo.” Los sistemas de archivos, grep, pipes y redirecciones ya se componen. Los modelos los entienden. Construir herramientas MCP personalizadas para operaciones que cat | grep | jq maneja de forma nativa añade sobrecarga sin añadir capacidad.¹³

La propia documentación de Anthropic confirma el patrón. Claude Code sigue la filosofía Unix: envíe logs por pipe, ejecútelo en CI, encadénelo con otras herramientas.⁵ El modo headless (claude -p) soporta salida JSON estructurada, aplicación de esquemas y reanudación de sesiones mediante IDs de sesión capturados. Anthropic posiciona el modo headless como la ruta principal de integración para CI/CD y flujos de trabajo con scripts.⁵

Simon Willison enmarca la implicación: escribir código es barato ahora.⁶ El corolario que nadie quiere escuchar es que la verificación es ahora la parte costosa. Los agentes CLI se componen con la infraestructura de verificación existente. Ejecutores de pruebas, linters, verificadores de tipos, escáneres de seguridad, pipelines de despliegue: todas son herramientas de línea de comandos. Un agente IDE necesita un plugin para cada una. Un agente CLI les envía datos por pipe.

Eficiencia de contexto: razonar sobre señal, no ruido

La ventana de contexto es finita. Cada token gastado en esquemas de herramientas, historial de conversación y sobrecarga MCP es un token no disponible para razonamiento. La arquitectura CLI mantiene el presupuesto de contexto ajustado por diseño.

Una llamada claude --print nueva recibe un prompt enfocado (~2K tokens) en lugar de heredar un contexto completo de conversación (~100K+ tokens). Cada operación comienza limpia. Sin estado acumulado. Sin definiciones de herramientas obsoletas. Sin deriva conversacional.

Mi infraestructura ejecuta 84 hooks a través de 17 eventos de ciclo de vida, todos orquestados mediante llamadas CLI. Cada generación de agente recibe un informe: estado actual de git, un resumen de lo que los agentes anteriores lograron y los criterios de aceptación para su única tarea. Informe en lugar de memoria. Los modelos ejecutan un informe claro mejor de lo que navegan 30 pasos de contexto acumulado.

Un análisis académico de la filosofía Unix en sistemas agénticos formalizó el principio: colapsar interfaces diversas en una abstracción uniforme, aceptando cierta pérdida de especialización a cambio de componibilidad y tratabilidad.¹¹ Las abstracciones tipo archivo y las especificaciones basadas en código reducen la carga cognitiva y de ingeniería. Los agentes CLI heredan 50 años de ese trabajo de diseño.

Remote Control cambia la ecuación

La objeción obvia a los agentes CLI-first: se pierde la retroalimentación visual de un IDE. Anthropic presentó una respuesta el 25 de febrero de 2026. Remote Control se conecta 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.

Remote Control no mueve nada a la nube. El agente sigue ejecutándose localmente. La sesión de terminal se registra con la API de Anthropic a través de TLS y consulta por trabajo pendiente. Todo el tráfico pasa por HTTPS saliente. No se abren puertos entrantes.²

La función resuelve la brecha de supervisión. Antes de Remote Control, los agentes CLI tenían dos modos: supervisado (sentarse frente a la terminal) o no supervisado (alejarse y esperar lo mejor). Remote Control crea un tercero: gobernanza asíncrona. Las solicitudes de aprobación se envían a su teléfono. Usted aprueba, rechaza o redirige desde cualquier lugar.

Mi sistema de hooks clasifica las operaciones por radio de impacto. 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, despliegues) se derivan a revisión humana. Remote Control convierte esa ruta de “derivar” de una espera bloqueante en una notificación asíncrona. El agente sigue trabajando en la siguiente historia mientras yo reviso la anterior desde mi teléfono.

El IDE se convierte en una capa de visualización, no en el entorno de ejecución. Usted monitorea el progreso a través de Remote Control. Usted interviene cuando las puertas de calidad señalan un problema. El agente CLI hace el trabajo. El IDE le muestra el resultado.

El patrón del agente Bash

just-bash de Vercel es un entorno bash simulado con un sistema de archivos virtual en memoria, construido específicamente para agentes de IA.⁴ El diseño codifica tres convicciones sobre la arquitectura de agentes:

Aislamiento sobre sandboxing. Cada llamada se ejecuta en aislamiento. Las variables de entorno, funciones y directorio de trabajo se reinician entre llamadas. El sistema de archivos persiste. La carga diferida de archivos significa que los archivos se cargan en la primera lectura y se almacenan en caché, sin cargar nunca archivos que el agente escribe antes de leer. El agente no puede contaminar su propio entorno a través de las operaciones.

Herramientas existentes sobre herramientas personalizadas. Grep tiene 50 años y maneja exactamente lo que las herramientas MCP de búsqueda personalizadas replican. jq parsea JSON. curl obtiene URLs. El modelo conoce estas interfaces desde los datos de entrenamiento. Las herramientas personalizadas requieren inyección de esquemas y documentación. Las herramientas estándar no requieren ninguna de las dos.

Arquitectura mínima sobre arquitectura de framework. Andrew Qu capturó el principio: “Los modelos se están volviendo más inteligentes y las ventanas de contexto se están haciendo más grandes, así que quizás la mejor arquitectura de agentes es casi ninguna arquitectura en absoluto.”¹³

Mi harness valida el patrón a escala de producción. Aproximadamente 15.000 líneas de bash orquestando Claude Code. 84 hooks a través de 17 tipos de eventos. Dispatchers, puertas de calidad, integración de búsqueda semántica, bucles autónomos. Sin runtime Python, sin dependencia de framework. Las asperezas de bash (sin JSON nativo, sin async, sin estructuras de datos propias) son reales pero solucionables. jq maneja JSON. El procesamiento secuencial es en realidad una ventaja: las puertas deben ejecutarse en orden, no competir.

El patrón funciona porque la orquestación de agentes se reduce fundamentalmente a leer stdin, tomar una decisión y escribir stdout. Esa descripción coincide exactamente con el propósito de diseño de bash. Cualquier cosa más compleja indica que la descomposición de la tarea estaba equivocada, no las herramientas.

El costo como decisión de arquitectura

Las decisiones de costo se acumulan. Elegir CLI sobre MCP para operaciones sin estado ahorra un 94% por invocación.³ Con 100 operaciones por día, el ahorro alcanza $228/mes solo en sobrecarga de definición de herramientas.³ Esos ahorros liberan presupuesto para más operaciones, lo que genera más ahorros. La arquitectura se paga sola.

Tres capas de costo se acumulan independientemente:

Capa de tokens. Compresión del system prompt. Ejecuto ~3.500 tokens de system prompt a través de un archivo CLAUDE.md y 8 archivos de reglas. Las restricciones superan a las explicaciones. “Rechazar llamadas a herramientas que coincidan con rutas sensibles” hace el mismo trabajo que una explicación de 15 líneas sobre por qué las credenciales deben permanecer protegidas. La documentación de mejores prácticas de Anthropic enfatiza el mismo punto: el rendimiento de la ventana de contexto se degrada a medida que se llena.⁷ Cada token desperdiciado cuesta el doble: una vez en cargos directos de API, otra vez en calidad de razonamiento degradada.

Capa de agentes. Generaciones nuevas sobre conversaciones largas. Cada historia en una ejecución autónoma obtiene un nuevo agente con una ventana de contexto limpia. Geoffrey Huntley documentó un patrón similar llamado “The Ralph Loop,” ejecutando desarrollo autónomo a $10,42/hora en Sonnet.¹² El contexto nunca se infla porque cada agente comienza limpio. Los cache hits en el system prompt cuestan un 90% menos ($0,50 vs $5,00 por millón de tokens en Opus 4.6), por lo que el system prompt repetido a través de generaciones nuevas tiene una sobrecarga mínima.⁸

Capa de arquitectura. CLI para operaciones sin estado, MCP para las que tienen estado. Una llamada claude --print para una evaluación única no añade sobrecarga de conexión. MCP tiene sentido cuando la herramienta necesita estado persistente o streaming. La mayoría de las operaciones de agentes son evaluaciones únicas, clasificaciones o tareas de generación de código. CLI maneja todas ellas a menor costo con depuración más simple.

Un ejemplo concreto de mi bucle autónomo la semana pasada: cinco historias PRD procesadas durante la noche.¹⁵ Cada historia generó un agente nuevo (~2K tokens de informe), ejecutó la implementación (~15K tokens en promedio), luego generó tres agentes de revisión (~2K tokens cada uno). Total por historia: ~23K tokens. El mismo flujo de trabajo en una conversación MCP de larga duración cargaría ~100K+ tokens de contexto acumulado por historia para la tercera historia. Cinco historias vía CLI: ~115K tokens en total. Cinco historias vía conversación MCP: ~500K+ tokens en total. La proporción de costos se acumula con cada historia adicional.

Cuándo MCP sigue ganando

La tesis del CLI no argumenta en contra de MCP universalmente. MCP gana en escenarios específicos donde CLI se queda corto.

Servidores de herramientas con estado. Un explorador de base de datos que mantiene un pool de conexiones entre llamadas se beneficia del modelo de servidor persistente de MCP. Reconectarse en cada llamada CLI añade latencia y sobrecarga de autenticación. Si la herramienta necesita estado entre invocaciones, MCP es la elección correcta.

Validación estructurada. Los esquemas de herramientas MCP aplican contratos de entrada/salida. Una llamada CLI acepta texto arbitrario. Cuando el agente debe proporcionar entrada estructurada que coincida con un esquema preciso (formato de clave API, rangos de fechas, opciones enumeradas), el esquema MCP captura la entrada malformada antes de que la herramienta la procese. La validación CLI requiere que la propia herramienta o un script envolvente aplique las restricciones.

Control de acceso multi-tenant. Los servidores MCP pueden aplicar permisos por usuario de forma centralizada. Las herramientas CLI heredan los permisos del usuario del sistema operativo. En entornos de equipo donde diferentes agentes necesitan diferentes niveles de acceso, MCP proporciona una autorización más granular.

Respuestas en streaming. Las operaciones de larga duración que producen salida incremental (seguimiento de logs, progreso de compilación, exportaciones de base de datos) funcionan mejor a través del protocolo de streaming de MCP que a través de una llamada CLI que se bloquea hasta completarse.

La regla de decisión: si la operación es sin estado y de un solo uso, utilice CLI. Si la operación requiere estado persistente, contratos estructurados o streaming, utilice MCP. En mi harness, aproximadamente el 90% de las operaciones son sin estado. El 10% que necesita MCP genuinamente se beneficia de ello. Optimizar el 90% produce el mayor retorno.

Lo que puede construir hoy

Tres patrones, cada uno construible en una tarde, cada uno acumulándose con los demás.

Patrón 1: Separación planificación/ejecución

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

Cada fase obtiene permisos de herramientas delimitados. El agente de planificación no puede editar código. El agente de implementación no puede navegar la web. Los límites de archivos aplican la separación. El flag --allowedTools hace la aplicación a nivel CLI. Sin archivo de configuración. Sin configuración de plugin. Un flag por invocación, delimitado exactamente a los permisos que esa fase requiere.

El ciclo de anotación es el diferenciador clave respecto a “simplemente hacer mejores prompts.” Usted revisa el plan en su editor. Tacha las partes con las que no está de acuerdo. Añade notas al margen. El agente lee su archivo anotado y revisa. El plan mejora con cada pasada porque dos inteligencias diferentes (conocimiento de dominio humano, generación de código del modelo) convergen en el mismo documento.

Patrón 2: Generación nueva por tarea

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

Sin contexto acumulado. Sin deriva conversacional. Cada agente obtiene una ventana limpia con un informe enfocado. El flag --output-format json captura salida estructurada incluyendo IDs de sesión, habilitando la reanudación determinista de conversaciones si una historia necesita trabajo de seguimiento.

El paso de verificación independiente importa más que el paso de implementación. Los agentes exhiben lo que llamo Verificación Fantasma: afirman que las pruebas pasan sin ejecutarlas. Ejecutar pytest fuera de la ventana de contexto del agente elimina el modo de fallo por completo. El agente no puede tergiversar resultados que nunca produjo.

Patrón 3: Pipeline de revisión paralela

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

Tres agentes. Tres perspectivas. Cero estado compartido. Los desacuerdos entre revisores revelan exactamente los problemas que un solo revisor pasa por alto. El operador & y el builtin wait manejan el paralelismo. Sin runtime async. Sin pool de hilos. Sin framework de orquestación. El control de trabajos de bash hace el trabajo.

El poder del patrón: cada revisor obtiene la ventana de contexto completa para su única preocupación. Un solo revisor dividiendo la atención entre corrección, seguridad y estilo rinde menos que tres especialistas con contexto dedicado. CLI hace que la separación sea trivial porque cada llamada es un proceso independiente con memoria independiente.

Conclusiones clave

Para desarrolladores que construyen sistemas de agentes: - Comience con claude -p para toda generación de agentes. Añada MCP solo cuando se requiera estado persistente. - Delimite los permisos de herramientas por fase. Los agentes de planificación leen. Los agentes de implementación escriben. Los agentes de revisión leen diffs. - Presupueste un 94% menos para sobrecarga de tokens eligiendo CLI sobre MCP para operaciones sin estado.³

Para equipos que escalan flujos de trabajo autónomos: - Las generaciones nuevas de agentes previenen la deriva de contexto y limitan los costos de tokens por operación. - Remote Control convierte “no supervisado” en “supervisado asincrónicamente” sin cambiar la arquitectura CLI.² - Los datos de Vercel demuestran el resultado contraintuitivo: menos herramientas significa tasas de éxito más altas, no más bajas.⁴

Para arquitectos que eligen infraestructura de agentes: - Los agentes CLI se componen con herramientas existentes de CI/CD, pruebas y despliegue. No se necesita trabajo de integración. - La filosofía Unix (componer herramientas pequeñas vía pipes) precede y supera a todo framework específico para agentes.¹¹ - El muro del 10% de productividad se rompe cuando usted deja de tratar al agente como una herramienta de chat y comienza a tratarlo como infraestructura.

Parte de la serie AI Engineering. Vea también: Claude Code as Infrastructure, Anatomy of a Claw, The Autonomous Loop, y The 10% Wall.