Por que a execução no estilo heredoc é mais adequada para agentes de IA do que um REPL em 2026

Os primeiros agentes de codificação revelaram algo surpreendentemente poderoso: dar a um agente acesso ao Bash, e ele pode fazer quase tudo – desde escrever código e coletar contexto até gerenciar fluxos de trabalho Git completos.

Essa percepção ajudou a alimentar um movimento mais amplo em direção ao software CLI-first. As interfaces de linha de comando começaram a parecer a forma padrão de tornar aplicações complexas acessíveis aos agentes de IA, dando origem a um slogan familiar:

CLI é tudo que você precisa.

Mas há um custo oculto. Os agentes costumam usar um terminal da mesma forma que um ser humano faria: execute um comando curto, inspecione o resultado e decida o que fazer a seguir. À medida que as tarefas se tornam mais complexas, isso cria mais idas e vindas entre o modelo e suas ferramentas, o que significa mais chamadas LLM, mais desperdício de contexto e mais tempo gasto em espera.

Em vez de pedir aos agentes que montem scripts de shell complicados, preferiríamos que eles coordenassem tarefas em uma linguagem de programação que já entendessem. Isso leva a uma arquitetura ligeiramente diferente:

Mantenha a CLI como ponto de entrada universal, mas use o código como a forma real de interagir com o software.

O agente envia um bloco de código que contém as operações, decisões e processamento de dados que, de outra forma, seriam espalhados por várias rodadas de interação. O tempo de execução local executa o fluxo de trabalho.

ego-browser foi construído em torno desta ideia. Sua CLI lança um ambiente programável, o navegador expõe suas capacidades através de um pequeno conjunto de funções, e o agente usa suas habilidades de programação existentes para compor essas funções e orquestrá-los.

Neste artigo, comparamos heredoc e REPL, duas maneiras de executar código por meio de uma CLI e compartilhar os resultados experimentais de ego-browser. Com o heredoc, o agente concluiu as mesmas tarefas em 44% menos rodadas de execução, com 35,5% menos chamadas de ferramentas, a um custo 21,6% menor.

“CLI é tudo que você precisa” - e daí?

A afirmação de que “CLI é tudo que você precisa” pressupõe que o modelo já sabe como usar essa CLI.

Para ferramentas conhecidas como Git, Docker e FFmpeg, isso geralmente não é um problema. Os modelos viram inúmeros comandos, tutoriais, scripts e mensagens de erro durante o treinamento e já conhecem os argumentos e como os comandos se encaixam.

Mas quando construímos uma CLI totalmente nova para agentes, o cenário muda. Cada CLI possui seus próprios subcomandos, argumentos, formatos de saída e semântica de erro. Para o modelo, é essencialmente uma nova minilinguagem. Mesmo com a documentação completa, o modelo ainda precisa aprender primeiro as regras e depois descobrir, por meio de chamadas repetidas, como os comandos se encaixam.

Exponha os mesmos recursos de uma API JavaScript ou de uma API em qualquer outra linguagem, e o modelo ainda terá que aprender os novos conceitos de domínio, mas não precisará mais reaprender o fluxo de controle, estruturas de dados ou composição. Loops, condições, tratamento de exceções e processamento de dados permanecem em uma linguagem de programação que ele já conhece.

Faça uma tarefa simples: abra uma página da web e leia seu título principal. Se ego-browser expôs uma interface de estilo de comando tradicional, o agente poderá precisar de várias etapas para concluí-la:

# 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

Após cada etapa, o agente aguarda a ferramenta, lê o resultado e decide o que fazer a seguir.

A interface de código que ego-browser realmente usa permite expressar todo o fluxo de trabalho de uma só 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);

Ambas as abordagens realizam a mesma coisa. A interface de estilo de comando divide o processo em múltiplas rodadas de interação modelo-ferramenta; a interface de código permite que o agente escreva o processo completo uma vez e o entregue ao tempo de execução local.

Esta é exatamente a ideia de design mencionada anteriormente: manter a CLI como ponto de entrada universal, mas usar o código como interface real para o software. Ele mantém a vantagem da CLI de ser fácil de chamar e integrar, ao mesmo tempo que permite que o modelo use as habilidades de programação que já possui para composição e orquestração.

Quando a CLI se torna uma porta de entrada para código

Depois que uma CLI aceita o código, a próxima questão é como o agente deve entregar esse código ao ambiente de execução?

A rigor, heredoc é a sintaxe de entrada do shell e REPL é o modo de execução de um interpretador; os dois não estão na mesma camada de abstração. O que este artigo realmente compara é a execução de código único inserida por meio de um heredoc em ego-browser, versus uma sessão interativa persistente construída em um REPL. Por questões de brevidade, iremos chamá-los apenas de heredoc e REPL daqui em diante.

Uma opção é o heredoc. Em ego-browser, o agente envia um bloco inteiro de JavaScript de uma só 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

O shell passa o código para ego-browser, espera que ele termine, recebe o resultado e sai. Para o agente, isso se comporta como uma chamada de ferramenta convencional:

Submit command → wait for process → receive result

Um REPL funciona de maneira diferente. O intérprete permanece ativo, permitindo que o agente insira o código repetidamente enquanto retém as variáveis e o estado da sessão:

> await browser.openOrReuseTab("https://example.com", { wait: true })
< Tab {...}

> await page.getByRole("heading").textContent()
< "Example Domain"

Em termos de poder expressivo, os dois são essencialmente equivalentes. Um REPL pode executar um programa completo com loops, condições e tratamento de exceções de uma só vez, e um heredoc pode enviar apenas uma única linha.

A diferença clara é o ciclo de vida do processo. Com um heredoc, o processo é encerrado assim que a execução do código termina; um REPL mantém o processo do interpretador ativo, aguardando novas entradas. Isso também significa que os dois impõem demandas diferentes às ferramentas dos agentes. Um heredoc é executado diretamente no modelo familiar de solicitação-resposta:

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

O REPL exige mais da ferramenta: processos persistentes, gerenciamento de sessões, entrada contínua, interrupção e recuperação. A maioria das ferramentas Bash integradas dos agentes não possui esses recursos. Entre os produtos convencionais de hoje, apenas Codex os suporta razoavelmente bem. E o suporte da ferramenta é apenas uma condição necessária para usar um REPL. Ele não decide como o modelo realmente usará um. Mesmo quando ambos os ambientes podem executar o mesmo código, o modelo ainda pode escrever código de forma diferente em cada um.

Como os modelos escrevem código em cada ambiente

Em teoria, um modelo possui a mesma capacidade de programação em ambos os ambientes. Na prática, observamos uma diferença comportamental consistente:

• Em um REPL, o modelo tende a inserir o código de forma incremental.
• Em um heredoc, é mais provável gerar um programa completo de uma só vez.

O software para humanos deve levar em conta a ergonomia. O software para agentes precisa de uma disciplina semelhante: chame-a engenharia de experiência de modelo. Uma interface deve funcionar com os modelos de padrões comportamentais desenvolvidos durante o treinamento.

O contraste entre REPL e Heredoc reflete a distribuição de seus dados de treinamento.

Os exemplos de REPL geralmente vêm de tutoriais, sessões de depuração e trocas de perguntas e respostas. Seu padrão típico é exploratório:

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Os blocos de código Heredoc se parecem mais com scripts ou arquivos de origem. Eles têm limites iniciais e finais explícitos, o que incentiva o modelo a produzir um fluxo de trabalho contínuo:

const page = await openPage();
const element = await findElement(page);
const text = await readText(element);

console.log(text);

Isso não significa que um REPL seja incapaz de executar programas completos. O modelo poderia enviar o mesmo bloco de código para um REPL em uma única etapa.

A distinção é contextual. Um REPL incentiva um executar, observar, continuar padrão. Um heredoc encoraja uma organize primeiro e depois execute padrão.

Essa tendência também determina onde reside o fluxo de controle. Em um REPL, é mais provável que o modelo divida a tarefa em vários estágios e decida o que fazer após cada resultado. Em um heredoc, é mais provável colocar loops, condições, filtragem e processamento de dados diretamente no programa e deixar o tempo de execução local lidar com eles.

O que os experimentos mostraram

Entre as principais ferramentas de agente que poderíamos integrar de forma confiável, Codex forneceu os recursos de execução que um REPL persistente requer. Portanto, criamos um benchmark automatizado no Codex SDK: o mesmo agente concluiu quatro tipos de tarefas reais do navegador por meio do REPL e do heredoc, e agregamos os resultados em execuções repetidas para comparação.

As tarefas eram:

• Análise de pós-tendência X: Colete as postagens originais de OpenAI dos últimos sete dias, exclua postagens fixadas, republicações e respostas, classifique as cinco primeiras por visualizações e calcule suas taxas de engajamento e média geral.
• OpenAI formulário de emprego: Encontre a posição correta de infraestrutura em nuvem em São Francisco, carregue um currículo, preencha o formulário de inscrição e pare antes do envio final.
• Redfin cálculo da hipoteca: Filtre as propriedades em Austin por tipo de casa e preço, abra o primeiro resultado após a classificação, altere o pagamento inicial para 20% e recupere o pagamento mensal estimado atualizado.
• Expedia pesquisa de voo: Encontre um voo só de ida sem escalas de JFK para MIA, selecione a opção mais barata de uma companhia aérea específica, insira as informações do passageiro e pare antes do pagamento.

Essas tarefas abrangiam mais do que abrir páginas e ler textos. Eles incluíram extração estruturada, filtragem condicional, navegação entre páginas, uploads de arquivos, preenchimento de formulários, alterações no estado da página e cálculos, cobrindo a maioria das operações comuns executadas por agentes de navegador.

Ambas as abordagens completaram a maioria das tarefas. O Heredoc obteve uma taxa de sucesso de 77,5%, em comparação com 75,0% do REPL. A diferença na confiabilidade foi modesta.

A maior diferença foi a eficiência:

• O tempo médio de conclusão caiu 35.0%.
• O tempo médio de conclusão caiu 30.7%.
• As chamadas de ferramentas caíram 35.5%.
• O consumo de tokens caiu 29.8%.
• O custo médio caiu 21.6%.

Embora um REPL possa reutilizar o estado de tempo de execução, essa vantagem não produziu menos interações. Na prática, o agente heredoc fez menos chamadas de ferramentas.

Os resultados corresponderam às nossas observações anteriores. Uma vez dentro de um REPL, o agente geralmente executava um pequeno trecho de código, examinava o resultado e então decidia o que fazer a seguir. Loops, filtros e decisões que poderiam ter sido tratados dentro de um único programa foram distribuídos em várias trocas de modelo-ferramenta.

Os dois ambientes oferecem poder expressivo semelhante. Sua diferença de eficiência vem principalmente de como seus padrões de interação moldam o comportamento do agente. Pelo menos para essas quatro tarefas do agente do navegador, o heredoc encorajou de forma mais consistente o modelo a organizar um programa completo, empurrar loops, filtragem e decisões no código, e evitar as viagens extras de ida e volta da tomada de decisões passo a passo.

Também examinamos se o mesmo padrão se mantinha em uma escala maior, comparando ego-browser com um produto de automação de navegador baseado em REPL semelhante no conjunto de dados Odysseys. Ao contrário da experiência controlada acima, esta comparação envolveu dois produtos completos, em vez do mesmo modelo operando através de duas interfaces. É, portanto, útil como uma comparação global de eficiência, mas as suas diferenças não podem ser atribuídas inteiramente ao Heredoc versus REPL.

Esta não é uma vitória permanente para Heredoc

Não acreditamos que o Heredoc seja inerentemente superior ao REPL.

Nossa conclusão depende das capacidades dos modelos, da distribuição de seus dados de treinamento e do design das ferramentas dos agentes tal como existem em 2026.

Os agentes de hoje geralmente são melhores na produção de um bloco completo de código em uma única passagem. Suas ferramentas shell também são projetadas em torno de um ciclo de vida simples: enviar um comando, aguardar sua saída e retornar o resultado. Nessas condições, o heredoc torna mais fácil reduzir as rodadas de interação e mover o fluxo de controle para o código executado localmente.

Essas condições podem mudar rapidamente.

As futuras ferramentas de agente poderão fornecer sessões persistentes confiáveis, resultados estruturados e recuperação robusta de estado. Os agentes podem não precisar mais lidar com prompts REPL, estado de processo e sessões interrompidas. O treinamento direcionado também poderia ensinar modelos a enviar programas completos de forma proativa dentro de um REPL, em vez de cair em uma interação passo a passo desnecessária.

Se isso acontecer, os REPLs poderão preservar os benefícios da reutilização do estado e do feedback imediato sem exigir mais chamadas de modelo. Eles podem até se tornar a melhor escolha para tarefas com inicialização cara, estado de longa duração ou fluxo de trabalho genuinamente exploratório.

É por isso que o título especifica 2026. Não estamos afirmando ter descoberto uma lei permanente. Este é um julgamento de engenharia pontual baseado nos modelos e ferramentas de agente disponíveis atualmente.