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:

La CLI es todo lo que necesitas.

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 pedir a los agentes que armen scripts de shell complicados, preferimos que coordinen las tareas en un lenguaje de programación que ya entiendan. Esto lleva a una arquitectura ligeramente diferente:

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

ego-browser se creó en torno a esta idea. Su CLI inicia un entorno programable, el navegador expone sus capacidades mediante un pequeño conjunto de funciones y el agente utiliza sus conocimientos de programación para combinar esas funciones y 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 completó las mismas tareas con un 44 % menos de rondas de ejecución, un 35,5 % menos de llamadas a herramientas y un costo un 21,6 % menor.

«La CLI es todo lo que necesitas»: ¿y luego qué?

La afirmación de que «la CLI es todo lo que necesitas» 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.

Si expones las mismas capacidades como una API de JavaScript, o como una API en cualquier otro lenguaje, el modelo aún tiene que aprender los nuevos conceptos del dominio, pero ya no necesita volver a aprender el flujo de control, las estructuras de datos ni 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.

Realiza una tarea sencilla: abre una página web y lee su encabezado principal. Si ego-browser expusiera una interfaz tradicional basada en 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 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 de la actualidad, solo Codex las admite razonablemente bien. Además, la compatibilidad de la herramienta es solo una condición necesaria para usar un REPL; no determina cómo lo utilizará realmente el modelo. Incluso cuando ambos entornos pueden ejecutar el mismo código, el modelo puede escribirlo de forma 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 experiencia del modelo. 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:

• Análisis de publicaciones en tendencia en X (un tipo típico de scraping de redes sociales carga de trabajo): Recopila las publicaciones originales de OpenAI de los últimos siete días, excluye publicaciones fijadas, republicaciones y respuestas, clasifica las cinco primeras por vistas y calcula sus tasas de interacción y el promedio general.
• Solicitud de empleo en OpenAI: Encuentra el puesto correcto de infraestructura en la nube en San Francisco, carga 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 después de ordenar, cambia el pago inicial al 20 % y recupera el pago mensual estimado actualizado.
• Búsqueda de vuelos en Expedia: Encuentra un vuelo de ida y sin escalas de JFK a MIA, selecciona la opción más barata de una aerolínea específica, ingresa la información del pasajero y detente antes del pago.

Estas tareas abarcaron mucho más que abrir páginas y leer texto. Incluyeron extracción estructurada, filtrado condicional, navegación entre páginas, carga de archivos, llenado de formularios, cambios en el estado de las páginas y cálculos, cubriendo la mayoría de las operaciones habituales realizadas por 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 promedio de finalización se redujo en 35.0%.
• La mediana del tiempo de finalización se redujo en 30.7%.
• Las llamadas a herramientas cayeron 35.5%.
• El consumo de tokens cayó 29.8%.
• El costo promedio se redujo en 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, examinar el resultado y decidir qué hacer a continuación. Los bucles, filtros y decisiones que podrían haberse manejado dentro de un solo programa se distribuían en varios intercambios entre el modelo y la 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, de la distribución de sus datos de entrenamiento y del diseño de las herramientas de los agentes tal como existen 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 ofrecer sesiones persistentes confiables, resultados estructurados y una recuperación sólida del estado. Es posible que los agentes ya no necesiten gestionar por sí mismos los prompts del REPL, el estado del proceso ni las sesiones interrumpidas. La capacitación específica también podría enseñar a los modelos a enviar programas completos de forma proactiva dentro de un REPL, en lugar de caer en interacciones paso a paso innecesarias.

Si eso sucede, los REPL podrían conservar las ventajas de reutilizar el estado y recibir retroalimentación inmediata sin requerir más llamadas al modelo. Incluso podrían convertirse en la mejor opción para tareas con una inicialización costosa, un estado de larga duración o un flujo de trabajo realmente 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 concreto, basado en los modelos y las herramientas de agentes disponibles en la actualidad.