La llegada de los agentes de Inteligencia Artificial está obligando a replantear una pieza clásica del software que parecía ya resuelta: la línea de comandos. Durante años, la mayoría de herramientas CLI se diseñaron para personas, con atajos cómodos, mensajes tolerantes a errores y salidas pensadas para ser leídas rápidamente en pantalla. Pero ese modelo empieza a quedarse corto cuando quien ejecuta los comandos no es un administrador, un desarrollador o un usuario avanzado, sino un agente basado en modelos de lenguaje.
Esa es la idea central que plantea Justin Poehnelt en un artículo reciente: muchas empresas no deberían limitarse a adaptar sus CLI actuales para que “más o menos” funcionen con IA, sino que tendrían que rediseñarlas con una lógica distinta. La razón es sencilla. Lo que facilita la vida a un humano no siempre ayuda a un agente. Y, en algunos casos, puede incluso volverlo más propenso a equivocarse.
La diferencia no es menor. Según esta visión, la experiencia para humanos se basa en la tolerancia, la flexibilidad y la facilidad de descubrimiento. La experiencia para agentes, en cambio, necesita predictibilidad, estructuras rígidas, validación agresiva y defensa frente a errores que no se parecen a los errores humanos. No se trata solo de que los agentes ejecuten comandos más deprisa, sino de que fallan de una forma distinta: inventan parámetros, mezclan rutas, arrastran caracteres invisibles o confunden identificadores con URLs completas.
De los flags cómodos al JSON completo
Uno de los cambios más llamativos tiene que ver con la propia forma de introducir datos. Para una persona, una CLI ideal suele ofrecer comandos cortos y flags claros, algo como --title, --locale o --timezone. Para un agente de IA, sin embargo, ese enfoque puede quedarse corto rápidamente, sobre todo cuando hay que trabajar con estructuras anidadas o con esquemas complejos.
La alternativa que se propone es dar prioridad a cargas útiles completas en JSON, porque los modelos de lenguaje generan ese formato con mucha más naturalidad y con menos pérdida de información. En lugar de obligar al agente a traducir una estructura compleja a diez flags distintos, la CLI debería aceptar el payload casi tal como lo espera la API.
El cambio parece pequeño, pero tiene una consecuencia importante: reduce la distancia entre lo que la IA quiere hacer y lo que la herramienta realmente ejecuta. Cuantas menos capas intermedias haya, menos oportunidades existen para que el agente alucine, simplifique en exceso o rompa la semántica de una operación.
La documentación ya no puede vivir solo en una web
Otro de los puntos clave es la documentación. Una persona puede abrir varias pestañas, leer ejemplos y volver a intentarlo. Un agente de IA no siempre puede permitirse ese lujo sin consumir demasiados tokens o sin trabajar con información obsoleta. Por eso, el planteamiento de Poehnelt es que la propia CLI debería convertirse en una fuente de documentación viva y consultable en tiempo real.
Eso implica exponer esquemas, parámetros válidos, estructuras esperadas, cuerpos de petición, tipos de respuesta y permisos necesarios directamente desde el binario. En otras palabras, en lugar de depender de manuales externos o prompts kilométricos, el agente podría preguntarle al propio programa qué acepta y cómo debe usarlo.
Es una idea especialmente relevante para herramientas que encapsulan APIs complejas. Si el agente puede inspeccionar el esquema actual del comando en tiempo de ejecución, se reduce el riesgo de trabajar con documentación antigua o incompleta. También baja el coste operativo de mantener largas instrucciones dentro del contexto del modelo.
El gran problema: los agentes no se equivocan como los humanos
Donde el artículo resulta más interesante es en la seguridad de entrada. Un usuario humano puede escribir mal una opción, olvidar un parámetro o poner una ruta incorrecta. Un agente puede hacer algo bastante más extraño: introducir caracteres de control invisibles, colar parámetros dentro de un ID, pre-codificar cadenas que luego se codifican por segunda vez o generar rutas con intención aparentemente válida pero peligrosas en ejecución.
Por eso la tesis de fondo es clara: una CLI moderna no puede tratar al agente como un operador de confianza. Tiene que asumir que la entrada puede ser errónea, ambigua o incluso adversarial, aunque no exista mala intención. De ahí que se recomiende validar nombres de recursos, rechazar ciertos caracteres, impedir rutas sospechosas y limitar al máximo la interpretación flexible de argumentos.
En la práctica, esto acerca el diseño de una CLI al de una API pública: todo input debe validarse, sanearse y limitarse, porque el problema ya no es solo la comodidad del usuario, sino evitar que una alucinación acabe en una acción destructiva o en un acceso indebido.
Menos contexto inútil, más disciplina
El texto también subraya una cuestión que muchas empresas todavía infravaloran: el coste del contexto. Las APIs devuelven con frecuencia enormes blobs JSON, perfectamente asumibles para un humano que hace scroll, pero muy caros para una IA que paga cada campo en tokens y capacidad de razonamiento.
Por eso se propone incorporar mecanismos como máscaras de campos, salidas acotadas, paginación en formatos que puedan procesarse por streaming y, en general, una filosofía de mínima respuesta necesaria. No es solo una optimización de rendimiento. Es una forma de hacer que el agente conserve foco, reduzca su coste y tenga menos probabilidades de perderse entre datos irrelevantes.
Dry-run, skill files y MCP: el nuevo paquete mínimo
Poehnelt plantea además un conjunto de elementos que, en su opinión, deberían formar parte del kit básico de cualquier CLI preparada para agentes.
El primero es un modo dry-run, para validar localmente una acción antes de tocar la API o el sistema real. El segundo son archivos de contexto o “skills” que expliquen de forma explícita reglas que el agente no puede deducir solo a partir de --help, como confirmar borrados antes de ejecutarlos, usar siempre filtros de campos o preferir validaciones previas en operaciones de escritura.
El tercero es ofrecer una superficie MCP o equivalente, de modo que el agente no tenga que construir una cadena shell frágil, sino llamar a herramientas tipadas y estructuradas. Ese punto es especialmente relevante porque conecta con una tendencia cada vez más visible: la transición desde el simple “ejecutar comandos” hacia capas de integración más robustas entre agentes y software externo.
Un cambio de paradigma que apenas empieza
La idea de fondo no es que las CLI tradicionales hayan muerto, sino que ya no basta con diseñarlas pensando solo en personas. A medida que los agentes de IA ganan presencia en flujos de trabajo reales, desde productividad hasta administración de sistemas o integración con servicios cloud, las herramientas de línea de comandos tendrán que responder a un usuario nuevo: rápido, obediente, aparentemente seguro de sí mismo y, al mismo tiempo, capaz de equivocarse de formas inéditas.
Para muchas empresas, eso significa revisar cómo generan salida, cómo validan entrada, cómo exponen esquemas y cómo añaden barreras de seguridad antes de que el agente llegue a producción. Lo que antes era una utilidad para desarrolladores se está convirtiendo en una capa crítica entre los modelos y los sistemas reales.
Y ahí es donde empieza la nueva discusión: no si una CLI funciona con IA, sino si está realmente diseñada para sobrevivir a ella.
Preguntas frecuentes
¿Por qué una CLI pensada para humanos no siempre funciona bien con agentes de IA?
Porque los agentes no interactúan como una persona. Necesitan salidas estructuradas, validaciones estrictas y menos ambigüedad. Una interfaz cómoda para humanos puede ser demasiado permisiva o poco precisa para un modelo de lenguaje.
¿Qué formato prefieren normalmente los agentes para trabajar con una CLI?
En muchos casos, JSON. Permite expresar estructuras complejas sin perder semántica y se ajusta mejor a cómo generan información los modelos.
¿Qué es lo más importante para hacer una CLI más segura para agentes?
Validar entradas de forma agresiva, limitar salidas innecesarias, ofrecer modo dry-run y asumir que el agente puede equivocarse de maneras poco intuitivas.
¿Tiene sentido añadir soporte MCP a una CLI existente?
Sí, especialmente si la herramienta envuelve una API estructurada. MCP reduce ambigüedad, evita problemas de shell escaping y facilita llamadas más seguras y tipadas desde agentes.
Referencia: Artículo de Justin Poehnelt
