Por qué la ejecución estilo Heredoc se adapta mejor a los agentes de IA que un REPL en 2026

Los primeros agentes de codificación revelaron algo sorprendentemente poderoso: dale a un agente acceso a Bash y podrá hacer casi cualquier cosa, desde escribir código y recopilar contexto hasta administrar flujos de trabajo completos de Git.

Esa idea ayudó a impulsar un movimiento más amplio hacia el software CLI-first. Las interfaces de línea de comandos comenzaron a parecer la forma estándar de hacer que aplicaciones complejas fueran accesibles para los agentes de IA, lo que dio lugar a un eslogan familiar:

CLI es todo lo que necesita.

Pero hay un costo oculto. Los agentes suelen utilizar una terminal de forma muy parecida a como lo haría un humano: ejecutan un comando breve, inspeccionan el resultado y luego deciden qué hacer a continuación. A medida que las tareas se vuelven más complejas, esto crea más intercambios entre el modelo y sus herramientas, lo que significa más llamadas de LLM, más contexto desperdiciado y más tiempo de espera.

En lugar de pedirles a los agentes que armen complicados scripts de shell, preferiríamos que coordinaran las tareas en un lenguaje de programación que ya entiendan. Esto lleva a una arquitectura ligeramente diferente:

Mantenga la CLI como punto de entrada universal, pero utilice el código como 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 distribuirían en varias rondas de interacción. Luego, el tiempo de ejecución local ejecuta el flujo de trabajo.

ego-browser se construyó en torno a esta idea. Su CLI lanza un entorno programable, el navegador expone sus capacidades a través de un pequeño conjunto de funciones y el agente utiliza sus habilidades de programación existentes para componer esas funciones y orquestarlos.

En este artículo comparamos heredoc y REPL, dos formas de ejecutar código a través de una CLI y compartir los resultados experimentales de ego-browser. Con heredoc, el agente terminó las mismas tareas en un 44 % menos de rondas de ejecución, con un 35,5 % menos de llamadas a herramientas y con un costo un 21,6 % menor.

“CLI es todo lo que necesitas”, ¿y luego qué?

La afirmación de que "CLI es todo lo que necesita" supone que el modelo ya sabe cómo utilizar esa CLI.

Para herramientas conocidas como Git, Docker y FFmpeg, esto no suele ser un problema. Los modelos han visto innumerables comandos, tutoriales, scripts y mensajes de error durante el entrenamiento, y ya conocen los argumentos y cómo encajan los comandos.

Pero cuando creamos una CLI nueva para agentes, el panorama cambia. Cada CLI tiene sus propios subcomandos, argumentos, formatos de salida y semántica de errores. Para el modelo, se trata esencialmente de un nuevo minilenguaje. Incluso con la documentación completa, el modelo todavía tiene que aprender las reglas primero y luego descubrir, mediante llamadas repetidas, cómo encajan los comandos.

En su lugar, exponga las mismas capacidades que una API de JavaScript, o una API en cualquier otro lenguaje, y el modelo aún tiene que aprender los nuevos conceptos de dominio, pero ya no necesita volver a aprender el flujo de control, las estructuras de datos o la composición. Los bucles, las condiciones, el manejo de excepciones y el procesamiento de datos permanecen en un lenguaje de programación que ya conoce.

Realice una tarea sencilla: abra una página web y lea su encabezado principal. Si ego-browser expusiera una interfaz de estilo de comando tradicional, es posible que el agente necesite varios pasos para finalizarla:

# 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 heading

Después de cada paso, el agente espera la herramienta, lee el resultado y decide qué hacer a continuación.

La interfaz de código que ego-browser realmente usa le permite expresar todo el flujo de trabajo a la 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);

Ambos enfoques consiguen lo mismo. La interfaz de estilo comando divide el proceso en múltiples rondas de interacción modelo-herramienta; la interfaz de código permite al agente escribir el proceso completo una vez y entregarlo al tiempo de ejecución local.

Esta es exactamente la idea de diseño mencionada anteriormente: mantener la CLI como punto de entrada universal, pero usar el código como interfaz real para el software. Mantiene la ventaja de la CLI de ser fácil de llamar e integrar, al tiempo que permite que el modelo utilice las habilidades de programación que ya tiene para composición y orquestación.

Cuando la CLI se convierte en una puerta de entrada al código

Una vez que una CLI acepta el código, la siguiente pregunta es ¿cómo debe el agente entregar ese código al entorno de ejecución?

Estrictamente hablando, heredoc es la sintaxis de entrada del shell y REPL es el modo de ejecución de un intérprete; los dos no están en la misma capa de abstracción. Lo que realmente compara este artículo es la ejecución de código de una sola vez ingresada a través de un documento heredoc en ego-browser, versus una sesión interactiva persistente creada en un REPL. Para abreviar, los llamaremos heredoc y REPL de ahora en adelante.

Una opción es el heredoc. En ego-browser, el agente envía un bloque completo 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);
EOF

El shell pasa el código a ego-browser, espera a que finalice, recibe el resultado y sale. Para el agente, esto se comporta como una llamada a una herramienta convencional:

Submit command → wait for process → receive result

Un REPL funciona de manera diferente. El intérprete permanece vivo, lo que permite al agente ingresar código repetidamente mientras conserva las 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 términos de poder expresivo, los dos son esencialmente equivalentes. Un REPL puede ejecutar un programa completo con bucles, condiciones y manejo de excepciones de una sola vez, y un heredoc puede enviar solo una línea.

La clara diferencia es el ciclo de vida del proceso. Con un heredoc, el proceso sale tan pronto como el código termina de ejecutarse; un REPL mantiene vivo el proceso del intérprete, esperando más entradas. Esto también significa que ambos imponen demandas diferentes a las herramientas de los agentes. Un heredoc se ejecuta directamente en el conocido modelo de solicitud-respuesta:

submit the command → wait for the process to exit → get the result

REPL exige más de la herramienta: procesos persistentes, gestión de sesiones, entrada continua, interrupción y recuperación. Las herramientas Bash integradas de la mayoría de los agentes no tienen estas capacidades. Entre los productos más populares hoy en día, sólo Codex los admite razonablemente bien. Y el soporte de herramientas es solo una condición necesaria para usar un REPL. No decide cómo el modelo realmente utilizará uno. Incluso cuando ambos entornos pueden ejecutar el mismo código, el modelo aún puede escribir código de manera diferente en cada uno.

Cómo los modelos escriben código en cada entorno

En teoría, un modelo tiene la misma capacidad de programación en ambos entornos. En la práctica, observamos una diferencia de comportamiento consistente:

• En un REPL, el modelo tiende a ingresar código de forma incremental.
• En un heredoc, es más probable que se genere un programa completo de una sola vez.

El software para humanos debe tener en cuenta la ergonomía. El software para agentes necesita una disciplina similar: llámelo ingeniería de modelo-experiencia. Una interfaz debería funcionar con los modelos de patrones de comportamiento desarrollados durante el entrenamiento.

El contraste entre REPL y heredoc refleja la distribución de sus datos de entrenamiento.

Los ejemplos de REPL generalmente provienen 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 text

Los bloques de código Heredoc se parecen más a scripts o archivos fuente. Tienen límites iniciales y finales 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 en un solo paso.

La distinción es contextual. Un REPL fomenta una ejecutar, observar, continuar patrón. Un heredoc alienta a un organizar primero, luego ejecutar patrón.

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 después de cada resultado. En un heredoc, es más probable colocar bucles, condiciones, filtrado y procesamiento de datos directamente en el programa y dejar que el tiempo de ejecución local los maneje.

Lo que mostraron los experimentos

Entre las principales herramientas de agentes que pudimos integrar de manera confiable, Codex proporcionó las capacidades de ejecución que requiere un REPL persistente. Así que creamos un punto de referencia automatizado en el SDK de Codex: el mismo agente completó cuatro tipos de tareas reales del navegador a través de REPL y heredoc, y agregamos los resultados en ejecuciones repetidas para comparar.

Las tareas fueron:

• X análisis de publicaciones de tendencias: Recopile las publicaciones originales de OpenAI de los últimos siete días, excluya publicaciones fijadas, reenvíos y respuestas, clasifique las cinco primeras por vistas y calcule sus tasas de participación y su promedio general.
• OpenAI solicitud de empleo: Encuentre el puesto correcto de infraestructura de nube en San Francisco, cargue un currículum, complete el formulario de solicitud y deténgase antes del envío final.
• Cálculo de la hipoteca Redfin: Filtre propiedades en Austin por tipo de vivienda y precio, abra el primer resultado después de ordenar, cambie el pago inicial al 20% y recupere el pago mensual estimado actualizado.
• Búsqueda de vuelos de Expedia: Encuentre un vuelo de ida y sin escalas desde JFK a MIA, seleccione la opción más barata de una aerolínea específica, ingrese la información del pasajero y haga la parada antes del pago.

Estas tareas abarcaron más que abrir páginas y leer texto. Incluían extracción estructurada, filtrado condicional, navegación entre páginas, carga de archivos, finalización de formularios, cambios de estado de página y cálculos, cubriendo la mayoría de las operaciones comunes realizadas por los agentes de navegador.

Ambos enfoques completaron la mayoría de las tareas. Heredoc logró una tasa de éxito del 77,5%, en comparación con el 75,0% de REPL. La diferencia en confiabilidad fue modesta.

La mayor diferencia fue la eficiencia:

• El tiempo medio de finalización se redujo en 35.0%.
• El tiempo medio de finalización se redujo en 30.7%.
• Las llamadas a herramientas cayeron 35.5%.
• El consumo de tokens cayó 29.8%.
• El coste medio cayó 21.6%.

Aunque un REPL puede reutilizar el estado del tiempo de ejecución, esa ventaja no produjo menos interacciones. En la práctica, el agente heredoc hizo menos llamadas a herramientas.

Los resultados coincidieron con nuestras observaciones anteriores. Una vez dentro de un REPL, el agente solía ejecutar un pequeño fragmento de código, examinaba el resultado y luego decidía qué hacer a continuación. Los bucles, filtros y decisiones que podrían haberse manejado dentro de un solo programa se distribuyeron en varios intercambios de modelo-herramienta.

Los dos entornos ofrecen un poder expresivo similar. Su diferencia de eficiencia proviene principalmente de cómo sus patrones de interacción moldean el comportamiento de los agentes. Al menos para estas cuatro tareas de agente de navegador, heredoc alentó de manera más consistente al modelo a organizar un programa completo, insertar bucles, filtrado y decisiones en el código, y evitar los viajes de ida y vuelta adicionales de la toma de decisiones paso a paso.

También examinamos 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 en el conjunto de datos de Odysseys. A diferencia del experimento controlado anterior, esta comparación involucró dos productos completos en lugar del mismo modelo operando a través de dos interfaces. Por lo tanto, es útil como comparación de eficiencia general, pero sus diferencias no pueden atribuirse completamente a heredoc versus REPL.

Esta 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 los agentes tal como existirán en 2026.

Los agentes actuales generalmente son mejores a la hora de producir un bloque completo de código en una sola pasada. Sus herramientas de shell también están diseñadas en torno a un ciclo de vida simple: envía un comando, espera a que salga y devuelve el resultado. En esas condiciones, heredoc facilita la reducción de las rondas de interacción y el traslado del flujo de control al código ejecutado localmente.

Esas condiciones pueden cambiar rápidamente.

Las futuras herramientas de agentes pueden proporcionar sesiones persistentes confiables, resultados estructurados y una recuperación de estado sólida. Es posible que los agentes ya no necesiten manejar ellos mismos las indicaciones de REPL, el estado del proceso y las sesiones interrumpidas. La capacitación dirigida también podría enseñar a los modelos a enviar programas completos de manera proactiva dentro de un REPL en lugar de caer en una interacción innecesaria paso a paso.

Si eso sucede, los REPL podrían preservar los beneficios de la reutilización estatal y la retroalimentación inmediata sin requerir más llamadas modelo. Incluso pueden convertirse en la mejor opción para tareas con una inicialización costosa, un estado de larga duración o un flujo de trabajo genuinamente exploratorio.

Por eso el título especifica 2026. No pretendemos haber descubierto una ley permanente. Este es un juicio de ingeniería de un momento determinado basado en los modelos y las herramientas de agentes disponibles en la actualidad.