Llevo un tiempo dándole vueltas a una idea que, sinceramente, me parece cada vez más importante para cualquiera que construya software, APIs, herramientas de automatización o productos pensados para integrarse con Inteligencia Artificial: quizá no basta con tener una API bien documentada. Quizá tampoco basta con tener una CLI cómoda para humanos. Quizá estamos entrando en una etapa en la que habrá que diseñar muchas interfaces pensando, desde el principio, en que quien las va a usar no será una persona, sino un agente de IA. Y ese cambio, aunque parezca sutil, lo cambia todo.
Justin Poehnelt lo explica muy bien en su artículo “You Need to Rewrite Your CLI for AI Agents”, publicado el 4 de marzo de 2026. Su tesis es muy directa: la experiencia de desarrollador pensada para humanos y la experiencia de desarrollador pensada para agentes no son lo mismo. La primera prioriza descubrimiento, flexibilidad y perdón ante errores. La segunda necesita predictibilidad, estructuras claras y defensa en profundidad. Justin no lo plantea como teoría abstracta, sino desde la experiencia de haber construido una CLI para Google Workspace pensada para agentes desde el primer día. Además, acompaña esa idea con una skill pública instalable con este comando: npx skills install jpoehnelt/skills/agent-dx-cli-scale.
Lo interesante es que esta reflexión no se queda solo en “hagamos que la IA ejecute comandos”. Va mucho más allá. Lo que plantea es que muchas CLI tradicionales están diseñadas para una forma de uso humana que no encaja bien con los modelos de lenguaje. Un humano puede leer una tabla bonita, navegar por documentación externa, tolerar cierta ambigüedad o improvisar cuando algo falla. Un agente no funciona así. Un agente necesita salidas estructuradas, introspección en tiempo real, validación agresiva de entradas y barreras de seguridad frente a sus propias alucinaciones. Y, cuanto más lo pienso, más sentido me tiene.
También me parece especialmente valioso que Justin no se quede en la superficie y publique después un segundo texto, “The MCP Abstraction Tax”, donde añade un matiz muy relevante: cada capa que ponemos entre la intención del agente y el dato real introduce un coste de abstracción. En su esquema, el dato está en el fondo, encima está la API, y encima puede llegar MCP. Cada capa aporta cosas útiles —descubrimiento, seguridad, estandarización—, pero también pierde fidelidad. Y cuando trabajas con APIs complejas, ese coste acumulado puede importar mucho más de lo que parece.
Aquí es donde, personalmente, creo que se abre un debate muy interesante.
Porque durante mucho tiempo hemos asumido que una buena API era suficiente, y que una CLI era, básicamente, una capa de comodidad para personas. Pero si aceptamos que cada vez más tareas van a pasar por agentes, entonces una CLI deja de ser solo una herramienta de productividad humana y se convierte en una especie de interfaz operativa entre la IA y el sistema real. En ese contexto, ya no importa solo que el comando sea bonito o fácil de recordar. Importa que sea robusto ante entradas erróneas, que pueda devolver JSON limpio, que permita pedir solo los campos necesarios, que tenga dry-run, que exponga esquemas en tiempo de ejecución y que no obligue al agente a tragarse medio manual antes de empezar a trabajar.
Lo que más me ha hecho pensar de su planteamiento
Hay tres ideas del enfoque de Justin que me parecen especialmente acertadas.
La primera es dar prioridad a las cargas útiles completas en JSON frente a una maraña de flags pensados para humanos. Puede sonar incómodo para una persona, pero para un LLM tiene mucho sentido: reduce traducciones intermedias y permite expresar estructuras anidadas sin inventarse convenciones adicionales.
La segunda es convertir la propia CLI en una fuente de documentación viva e introspectable. En vez de obligar al agente a cargar documentación estática en el prompt, la idea es que pueda consultar esquemas, parámetros y tipos sobre la marcha. Esto no solo ahorra contexto, también reduce el riesgo de trabajar con documentación desactualizada.
La tercera, y quizá la más infravalorada, es la de no confiar en la entrada del agente. Justin lo dice de forma muy clara: los humanos cometen errores; los agentes alucinan. No es el mismo problema. Por eso propone endurecer la validación: rechazar caracteres de control, impedir rutas sospechosas, evitar parámetros incrustados en IDs, controlar codificación y asumir siempre que la entrada puede ser adversarial aunque no haya mala intención. Me parece una idea fundamental. En el fondo, se parece mucho a cómo deberíamos diseñar cualquier frontera seria entre software y mundo real.
El punto donde CLI y MCP no compiten, sino que se complementan
Otra parte que me parece muy útil del debate es que Justin no cae en el simplismo de presentar CLI vs MCP como si hubiera que elegir un ganador. En su artículo sobre el “abstraction tax”, lo que plantea es más interesante: cada enfoque optimiza cosas distintas. MCP favorece descubribilidad y estandarización. Una CLI bien diseñada para agentes puede preservar mejor la fidelidad y ofrecer más flexibilidad, sobre todo si se apoya en skills y carga contexto bajo demanda. El problema real no es cuál “gana”, sino dónde pagas el peaje de abstracción y si ese peaje te compensa.
Y esto me parece especialmente relevante ahora que tantas empresas están corriendo a “poner un MCP” encima de cualquier cosa, a veces sin revisar si la API subyacente ya era complicada, hostil o excesivamente abstracta. Si la base es mala, la capa superior no hace milagros. A veces ordena. A veces ayuda. Pero también puede ocultar problemas que luego reaparecen en producción de formas más difíciles de depurar. Esa es una conversación que, en mi opinión, todavía estamos empezando a tener.
Mi impresión personal
Mi sensación es que Justin está señalando algo muy importante: la Agent DX va a convertirse en una disciplina real. Igual que durante años hemos hablado de UX, DX, DevOps o platform engineering, vamos a empezar a hablar de herramientas, patrones y guardarraíles diseñados específicamente para agentes.
No creo que eso signifique reescribir de cero todas las CLI del mundo mañana. Tampoco creo que la respuesta sea abandonar APIs limpias o documentación buena. Pero sí creo que obliga a repensar prioridades. Añadir --output json, endurecer entradas, exponer esquemas, soportar dry-run, reducir salidas innecesarias, incorporar skills o contexto operativo específico… todo eso deja de ser “nice to have” y empieza a parecerme parte del diseño serio de cualquier herramienta que quiera convivir con agentes de IA de verdad.
Y aquí es donde me gustaría abrir el debate.
Porque no tengo claro que el futuro pase por una única respuesta. Habrá casos donde una CLI agent-first tenga todo el sentido. Habrá otros donde una API directa más una buena librería sea mejor. Y habrá escenarios donde MCP aporte una capa útil de estandarización. Lo que sí me parece evidente es que seguir pensando únicamente en interfaces para humanos empieza a quedarse corto.
Preguntas frecuentes
¿Qué propone exactamente Justin Poehnelt?
Propone que muchas CLI dejen de diseñarse solo para humanos y adopten patrones pensados para agentes de IA: JSON como entrada de primera clase, introspección de esquemas, validación dura de entradas, salida estructurada, dry-run y skills para aportar contexto operativo.
¿Qué es npx skills install jpoehnelt/skills/agent-dx-cli-scale?
Es el comando de instalación de una skill pública del repositorio personal de Justin Poehnelt, descrita como una escala para evaluar hasta qué punto una CLI está bien diseñada para agentes de IA.
¿Qué añade su artículo sobre MCP?
En “The MCP Abstraction Tax”, Justin sostiene que cada capa entre la intención del agente y los datos reales —por ejemplo API y MCP— introduce un coste de abstracción y pérdida de fidelidad, algo especialmente importante en APIs empresariales complejas.
¿CLI y MCP compiten entre sí?
Según el planteamiento de Justin, no necesariamente. MCP y CLI optimizan cosas distintas: descubrimiento y estandarización en un caso, fidelidad y flexibilidad en el otro. La cuestión clave es entender los costes y beneficios de cada capa.
Más referencias: Noticias.AI