Los primeros agentes de código revelaron algo sorprendentemente potente: dale a un agente acceso a Bash y puede hacer casi cualquier cosa, desde escribir código y recopilar contexto hasta gestionar flujos de Git completos.
Esa idea alimentó un movimiento más amplio hacia el software "CLI-first". Las interfaces de línea de comandos empezaron a parecer la forma estándar de hacer que aplicaciones complejas fueran accesibles a los agentes de IA, dando lugar a un eslogan conocido:
La CLI es todo lo que necesitas.
Pero hay un coste oculto. Los agentes suelen usar una terminal de forma parecida a como lo haría una persona: ejecutar un comando corto, revisar el resultado, y decidir qué hacer a continuación. A medida que las tareas se complican, esto genera más idas y vueltas entre el modelo y sus herramientas, lo que significa más llamadas al LLM, más contexto desperdiciado, y más tiempo de espera.
En vez de pedirle a los agentes que ensamblen scripts de shell complicados, preferimos que coordinen las tareas en un lenguaje de programación que ya conocen. Eso lleva a una arquitectura ligeramente distinta:
Mantener la CLI como el punto de entrada universal, pero usar el código como la forma real de interactuar con el software.
El agente envía un bloque de código que contiene las operaciones, decisiones y procesamiento de datos que de otro modo se repartirían en varias rondas de interacción. El entorno de ejecución local ejecuta entonces el flujo de trabajo.
ego-browser was built around this idea. Its CLI launches a programmable environment, the browser exposes its capabilities through a small set of functions, and the agent uses its existing programming skills to compose those functions and orquestarlas.
En este artículo comparamos heredoc y REPL, dos formas de ejecutar código a través de una CLI, y compartimos los resultados experimentales de ego-browser. Con heredoc, el agente terminó las mismas tareas con un 44% menos de rondas de ejecución, un 35,5% menos de llamadas a herramientas, y un 21,6% menos de coste.
"La CLI es todo lo que necesitas": ¿y después qué?
La afirmación de que "la CLI es todo lo que necesitas" asume que el modelo ya sabe usar esa CLI.
Para herramientas conocidas como Git, Docker o FFmpeg, esto no suele ser un problema. Los modelos han visto incontables comandos, tutoriales, scripts y mensajes de error durante su entrenamiento, y ya saben cómo encajan los argumentos y los comandos.
Pero cuando construimos una CLI completamente nueva para agentes, el panorama cambia. Cada CLI tiene sus propios subcomandos, argumentos, formatos de salida y semántica de errores. Para el modelo, es esencialmente un mini-lenguaje nuevo. Incluso con documentación completa, el modelo primero tiene que aprender las reglas, y luego averiguar a base de llamadas repetidas cómo encajan los comandos entre sí.
Expón esas mismas capacidades como una API de JavaScript, o una API en cualquier otro lenguaje, y el modelo sigue teniendo que aprender los conceptos nuevos del dominio, pero ya no necesita reaprender el flujo de control, las estructuras de datos ni la composición. Los bucles, condicionales, manejo de excepciones y procesamiento de datos se quedan en un lenguaje de programación que ya conoce.
Toma una tarea sencilla: abrir una página web y leer su encabezado principal. Si ego-browser expusiera una interfaz tradicional de comandos, el agente podría necesitar varios pasos para completarla:
# First call: open the page
ego-browser open https://example.com
# Tool response: the page is open
# Second call: locate the main heading
ego-browser find --role heading
# Tool response: a heading was found
# Third call: read the heading
ego-browser read --role headingTras cada paso, el agente espera a la herramienta, lee el resultado, y decide qué hacer a continuación.
La interfaz de código que usa realmente ego-browser le permite expresar todo el flujo de trabajo de una vez:
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);Los dos enfoques logran lo mismo. La interfaz de comandos divide el proceso en varias rondas de interacción entre modelo y herramienta; la interfaz de código deja que el agente escriba todo el proceso de una vez y se lo entregue al entorno de ejecución local.
Esta es exactamente la idea de diseño mencionada antes: mantener la CLI como el punto de entrada universal, pero usar el código como la interfaz real con el software. Conserva la ventaja de la CLI de ser fácil de invocar e integrar, y a la vez deja que el modelo use las habilidades de programación que ya tiene para componer y orquestar.
Cuando la CLI se convierte en una puerta de entrada al código
Una vez que una CLI acepta código, la siguiente pregunta es: ¿cómo debería el agente entregar ese código al entorno de ejecución?
Estrictamente hablando, heredoc es una sintaxis de entrada de shell y REPL es un modo de ejecución de un intérprete; los dos no están en el mismo nivel de abstracción. Lo que este artículo compara en realidad es la ejecución de código de una sola vez mediante heredoc en ego-browser, frente a una sesión interactiva persistente construida sobre un REPL. Por brevedad, a partir de aquí los llamaremos simplemente heredoc y REPL.
Una opción es el heredoc. En ego-browser, el agente envía un bloque entero de JavaScript de una sola vez:
ego-browser nodejs <<'EOF'
await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });
const heading = await page.getByRole("heading").textContent();
console.log(heading);
EOFEl shell le pasa el código a ego-browser, espera a que termine, recibe el resultado, y sale. Para el agente, esto se comporta como una llamada a herramienta convencional:
Submit command → wait for process → receive resultUn REPL funciona de otra forma. El intérprete se mantiene vivo, lo que permite al agente introducir código repetidamente conservando variables y el estado de la sesión:
> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}
> await page.getByRole("heading").textContent()
< "Example Domain"En cuanto a capacidad expresiva, los dos son esencialmente equivalentes. Un REPL puede ejecutar un programa completo con bucles, condicionales y manejo de excepciones de una vez, y un heredoc puede enviar una sola línea.
La diferencia clara está en el ciclo de vida del proceso. Con un heredoc, el proceso termina en cuanto acaba de ejecutarse el código; un REPL mantiene vivo el proceso del intérprete, esperando más entrada. Eso también significa que los dos exigen cosas distintas a las herramientas del agente. Un heredoc funciona directamente sobre el conocido modelo de petición-respuesta:
submit the command → wait for the process to exit → get the resultUn REPL le exige más a la herramienta: procesos persistentes, gestión de sesión, entrada continua, interrupción y recuperación. La mayoría de herramientas Bash integradas en los agentes no tienen estas capacidades. Entre los productos habituales de hoy, solo Codex las soporta razonablemente bien. Y el soporte de la herramienta solo es una condición necesaria para usar un REPL. No decide cómo lo usará realmente el modelo. Incluso cuando los dos entornos pueden ejecutar el mismo código, el modelo puede escribirlo de forma distinta en cada uno.
Cómo escriben código los modelos en cada entorno
En teoría, un modelo tiene la misma capacidad de programación en los dos entornos. En la práctica, observamos una diferencia de comportamiento constante:
- En un REPL, el modelo tiende a introducir código de forma incremental.
- En un heredoc, es más probable que genere un programa completo de una sola vez.
El software para personas tiene que tener en cuenta la ergonomía. El software para agentes necesita una disciplina parecida: llamémosla ingeniería de experiencia para modelos. Una interfaz debería encajar con los patrones de comportamiento que los modelos desarrollaron durante su entrenamiento.
El contraste entre REPL y heredoc refleja la distribución de sus datos de entrenamiento.
Los ejemplos de REPL suelen venir de tutoriales, sesiones de depuración e intercambios de preguntas y respuestas. Su patrón típico es exploratorio:
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textLos bloques de código heredoc se parecen más a scripts o archivos fuente. Tienen un inicio y un final explícitos, lo que anima al modelo a producir un flujo de trabajo continuo:
const page = await openPage();
const element = await findElement(page);
const text = await readText(element);
console.log(text);Esto no significa que un REPL sea incapaz de ejecutar programas completos. El modelo podría enviar el mismo bloque de código a un REPL de un solo paso.
La distinción es contextual. Un REPL fomenta un ejecutar, observar, continuar ". Un heredoc fomenta un organizar primero, ejecutar después ".
Esa tendencia también determina dónde vive el flujo de control. En un REPL, es más probable que el modelo divida la tarea en varias etapas y decida qué hacer tras cada resultado. En un heredoc, es más probable que ponga los bucles, condicionales, filtros y procesamiento de datos directamente en el programa y deje que el entorno de ejecución local se encargue.
Lo que mostraron los experimentos
Entre las herramientas de agentes habituales que pudimos integrar de forma fiable, Codex ofrecía las capacidades de ejecución que necesita un REPL persistente. Así que construimos un benchmark automatizado sobre el SDK de Codex: el mismo agente completó cuatro tipos de tareas reales de navegador tanto con REPL como con heredoc, y agregamos los resultados de ejecuciones repetidas para comparar.
Las tareas fueron:
- X trending-post analysis (a typical social media scraping workload): Recopila las publicaciones originales de OpenAI de los últimos siete días, excluye las fijadas, los repost y las respuestas, ordena las cinco con más visualizaciones, y calcula su tasa de interacción y la media general.
- Solicitud de empleo en OpenAI: Encuentra el puesto correcto de infraestructura en la nube en San Francisco, sube un currículum, completa el formulario de solicitud, y detente antes del envío final.
- Cálculo de hipoteca en Redfin: Filtra propiedades en Austin por tipo de vivienda y precio, abre el primer resultado tras ordenar, cambia la entrada al 20% y obtén la cuota mensual estimada actualizada.
- Búsqueda de vuelos en Expedia: Busca un vuelo directo y solo ida de JFK a MIA, elige la opción más barata de una aerolínea concreta, introduce los datos del pasajero, y detente antes del pago.
These tasks covered more than opening pages and reading text. They included structured extraction, conditional filtering, navigation across pages, file uploads, form completion, page-state changes, and calculations, covering most of the common operations performed by browser agents.
Los dos enfoques completaron la mayoría de las tareas. Heredoc logró una tasa de éxito del 77,5%, frente al 75,0% del REPL. La diferencia en fiabilidad fue modesta.
La diferencia mayor fue la eficiencia:
- El tiempo medio de finalización cayó un 35.0%.
- El tiempo mediano de finalización cayó un 30.7%.
- Las llamadas a herramientas cayeron un 35.5%.
- El consumo de tokens cayó un 29.8%.
- El coste medio cayó un 21.6%.
Aunque un REPL puede reutilizar el estado de ejecución, esa ventaja no se tradujo en menos interacciones. En la práctica, el agente con heredoc hizo menos llamadas a herramientas.
Los resultados coincidieron con nuestras observaciones anteriores. Dentro de un REPL, el agente solía ejecutar un pequeño fragmento de código, examinar el resultado, y decidir qué hacer a continuación. Los bucles, filtros y decisiones que podrían haberse gestionado dentro de un único programa se repartían en cambio en varios intercambios entre modelo y herramienta.
Los dos entornos ofrecen una capacidad expresiva parecida. Su diferencia de eficiencia viene principalmente de cómo sus patrones de interacción moldean el comportamiento del agente. Al menos para estas cuatro tareas de agente de navegador, heredoc animó de forma más consistente al modelo a organizar un programa completo, meter los bucles, filtros y decisiones dentro del código, y evitar las idas y vueltas extra de la toma de decisiones paso a paso.
También comprobamos si el mismo patrón se mantenía a mayor escala, comparando ego-browser con un producto de automatización de navegador similar basado en REPL, sobre el dataset Odysseys. A diferencia del experimento controlado anterior, esta comparación involucró dos productos completos en vez del mismo modelo operando a través de dos interfaces. Por eso es útil como comparación de eficiencia general, pero sus diferencias no pueden atribuirse por completo a heredoc frente a REPL.
Esto no es una victoria permanente para heredoc
No creemos que heredoc sea inherentemente superior a REPL.
Nuestra conclusión depende de las capacidades de los modelos, la distribución de sus datos de entrenamiento, y el diseño de las herramientas de agentes tal como existen en 2026.
Los agentes de hoy suelen ser mejores produciendo un bloque de código completo de una sola pasada. Sus herramientas de shell también están diseñadas con un ciclo de vida simple: enviar un comando, esperar a que termine, y devolver el resultado. Bajo esas condiciones, heredoc facilita reducir las rondas de interacción y trasladar el flujo de control a código ejecutado localmente.
Esas condiciones pueden cambiar rápido.
Las herramientas de agentes del futuro podrían ofrecer sesiones persistentes fiables, salidas estructuradas y una recuperación de estado robusta. Puede que los agentes ya no tengan que gestionar ellos mismos los prompts de un REPL, el estado del proceso y las sesiones interrumpidas. Un entrenamiento específico también podría enseñar a los modelos a enviar programas completos de forma proactiva dentro de un REPL, en vez de caer en una interacción paso a paso innecesaria.
Si eso ocurre, los REPL podrían conservar las ventajas de reutilizar el estado y de la respuesta inmediata sin necesitar más llamadas al modelo. Incluso podrían convertirse en la mejor opción para tareas con una inicialización costosa, estado de larga duración, o un flujo de trabajo genuinamente exploratorio.
Por eso el título especifica 2026. No decimos haber descubierto una ley permanente. Es un criterio de ingeniería válido en este momento, basado en los modelos y las herramientas de agentes disponibles hoy.