Os primeiros agentes de programação revelaram algo surpreendentemente poderoso: dá a um agente acesso a Bash e ele consegue fazer quase tudo — desde escrever código e reunir contexto até gerir fluxos de trabalho completos no Git.
Essa perceção ajudou a alimentar um movimento mais amplo em direção ao software CLI-first. As interfaces de linha de comandos começaram a parecer a forma padrão de tornar aplicações complexas acessíveis a agentes de IA, dando origem a um slogan conhecido:
Uma CLI é tudo o que precisas.
Mas há um custo escondido. Os agentes costumam usar um terminal quase como uma pessoa faria: correr um comando curto, inspecionar o resultado e depois decidir o que fazer a seguir. À medida que as tarefas se tornam mais complexas, isto gera mais idas e voltas entre o modelo e as suas ferramentas, ou seja, mais chamadas ao LLM, mais contexto desperdiçado e mais tempo de espera.
Em vez de pedir aos agentes para montarem scripts de shell complicados, preferimos que coordenem tarefas numa linguagem de programação que já conhecem. Isto leva a uma arquitetura ligeiramente diferente:
Manter a CLI como ponto de entrada universal, mas usar código como a forma real de interagir com o software.
O agente submete um bloco de código que contém as operações, decisões e o processamento de dados que, de outra forma, estariam espalhados por várias rondas de interação. O runtime local executa depois o fluxo de trabalho.
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 orquestrá-las.
Neste artigo, comparamos heredoc e REPL, duas formas de executar código através de uma CLI, e partilhamos os resultados experimentais do ego-browser. Com heredoc, o agente terminou as mesmas tarefas com menos 44% de rondas de execução, menos 35.5% de chamadas a ferramentas e um custo 21.6% mais baixo.
“Uma CLI é tudo o que precisas” — e depois?
A afirmação de que “uma CLI é tudo o que precisas” assume que o modelo já sabe usar essa CLI.
Para ferramentas conhecidas como Git, Docker e FFmpeg, isto normalmente não é um problema. Os modelos viram inúmeros comandos, tutoriais, scripts e mensagens de erro durante o treino, e já sabem os argumentos e como os comandos se encaixam.
Mas quando construímos uma CLI totalmente nova para agentes, o cenário muda. Cada CLI tem os seus próprios subcomandos, argumentos, formatos de saída e semântica de erros. Para o modelo, é essencialmente uma nova mini-linguagem. Mesmo com documentação completa, o modelo ainda tem de aprender primeiro as regras e só depois, através de chamadas repetidas, perceber como os comandos se encaixam.
Ao expor as mesmas capacidades como uma API de JavaScript, ou numa API em qualquer outra linguagem, o modelo ainda tem de aprender os novos conceitos de domínio, mas já não precisa de reaprender controlo de fluxo, estruturas de dados ou composição. Ciclos, condições, tratamento de exceções e processamento de dados ficam todos numa linguagem de programação que já conhece.
Repara numa tarefa simples: abrir uma página web e ler o seu título principal. Se o ego-browser expusesse uma interface tradicional em estilo comando, o agente poderia precisar de vários passos para a concluir:
# 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 headingDepois de cada passo, o agente espera pela ferramenta, lê o resultado e decide o que fazer a seguir.
A interface de código que o ego-browser realmente usa permite-lhe exprimir o fluxo de trabalho inteiro 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);As duas abordagens fazem o mesmo trabalho. A interface em estilo comando divide o processo em várias rondas de interação entre modelo e ferramenta; a interface em código deixa o agente escrever o processo completo de uma vez e entregá-lo ao runtime local.
É exatamente a ideia de design mencionada antes: manter a CLI como ponto de entrada universal, mas usar código como a interface real para o software. Mantém a vantagem da CLI de ser fácil de chamar e integrar, ao mesmo tempo que deixa o modelo usar as competências de programação que já tem para compor e orquestrar.
Quando a CLI se torna uma porta de entrada para código
Depois de uma CLI aceitar código, a próxima questão é: como deve o agente entregar esse código ao ambiente de execução?
Rigorosamente falando, heredoc é sintaxe de input de shell e REPL é um modo de execução de interpretador; os dois não estão ao mesmo nível de abstração. O que este artigo realmente compara é a execução de código de uma só vez, introduzido através de um heredoc no ego-browser, contra uma sessão interativa persistente construída sobre um REPL. Por brevidade, chamamos-lhes simplesmente heredoc e REPL a partir daqui.
Uma opção é o heredoc. No ego-browser, o agente submete 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);
EOFA shell passa o código ao ego-browser, espera que termine, recebe o resultado e sai. Para o agente, isto comporta-se como uma chamada a ferramenta convencional:
Submit command → wait for process → receive resultUm REPL funciona de forma diferente. O interpretador mantém-se ativo, permitindo ao agente introduzir código repetidamente enquanto mantém 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 consegue correr um programa completo com ciclos, condições e tratamento de exceções de uma só vez, e um heredoc pode submeter apenas uma linha.
A diferença clara está no ciclo de vida do processo. Com um heredoc, o processo termina assim que o código acaba de correr; um REPL mantém o processo do interpretador vivo, à espera de mais input. Isto também significa que os dois impõem exigências diferentes às ferramentas do agente. Um heredoc corre diretamente sobre o modelo familiar de pedido-resposta:
submit the command → wait for the process to exit → get the resultUm REPL exige mais da ferramenta: processos persistentes, gestão de sessão, input contínuo, interrupção e recuperação. A maioria das ferramentas Bash integradas nos agentes não tem estas capacidades. De entre os produtos mais usados hoje, só o Codex as suporta razoavelmente bem. E o suporte da ferramenta é apenas uma condição necessária para usar um REPL — não decide como o modelo o vai realmente usar. Mesmo quando os dois ambientes conseguem correr o mesmo código, o modelo pode continuar a escrevê-lo de forma diferente em cada um.
Como os modelos escrevem código em cada ambiente
Em teoria, um modelo tem a mesma capacidade de programação nos dois ambientes. Na prática, observámos uma diferença de comportamento consistente:
- Num REPL, o modelo tende a introduzir código de forma incremental.
- Num heredoc, é mais provável que gere um programa completo de uma só vez.
O software para pessoas tem de ter em conta a ergonomia. O software para agentes precisa de uma disciplina semelhante: chama-lhe engenharia de experiência do modelo. Uma interface deve funcionar com os padrões de comportamento que os modelos desenvolveram durante o treino.
O contraste entre REPL e heredoc reflete a distribuição dos respetivos dados de treino.
Os exemplos de REPL costumam vir de tutoriais, sessões de depuração e trocas de perguntas e respostas. O seu padrão típico é exploratório:
> Get the page
< Return page information
> Find an element
< Return element information
> Read its contents
< Return the textOs blocos de código em heredoc parecem-se mais com scripts ou ficheiros-fonte. Têm um início e um fim explícitos, o que leva 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);Isto não significa que um REPL seja incapaz de correr programas completos. O modelo podia submeter o mesmo bloco de código a um REPL num só passo.
A distinção é contextual. Um REPL incentiva um padrão de executar, observar, continuar padrão. Um heredoc incentiva um padrão de organizar primeiro, executar depois padrão.
Essa tendência também determina onde vive o controlo de fluxo. Num REPL, o modelo tende a dividir a tarefa em várias etapas e a decidir o que fazer depois de cada resultado. Num heredoc, tende a colocar ciclos, condições, filtragem e processamento de dados diretamente no programa e a deixar o runtime local tratar deles.
O que as experiências mostraram
De entre as ferramentas de agentes mais usadas que conseguimos integrar de forma fiável, o Codex foi a que ofereceu as capacidades de execução que um REPL persistente exige. Por isso construímos um benchmark automatizado sobre o SDK do Codex: o mesmo agente completou quatro tipos de tarefas reais de navegador através de REPL e de heredoc, e agregámos os resultados de várias execuções repetidas para comparação.
As tarefas foram:
- X trending-post analysis (a typical social media scraping workload): Recolhe as publicações originais da OpenAI dos últimos sete dias, exclui publicações fixadas, republicações e respostas, ordena as cinco melhores por visualizações e calcula as suas taxas de interação e a média geral.
- Candidatura a emprego na OpenAI: Encontra a vaga certa de Cloud Infrastructure em São Francisco, carrega um currículo, preenche o formulário de candidatura e para antes da submissão final.
- Cálculo de hipoteca no Redfin: Filtra imóveis em Austin por tipo de casa e preço, abre o primeiro resultado depois de ordenar, muda a entrada inicial para 20% e obtém a prestação mensal estimada atualizada.
- Pesquisa de voos na Expedia: Encontra um voo só de ida, sem escalas, de JFK para MIA, seleciona a opção mais barata de uma companhia aérea específica, insere os dados do passageiro e para antes do pagamento.
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.
As duas abordagens concluíram a maioria das tarefas. O heredoc atingiu uma taxa de sucesso de 77.5%, contra 75.0% do REPL. A diferença de fiabilidade foi modesta.
A diferença maior estava na eficiência:
- O tempo médio de conclusão caiu 35.0%.
- O tempo mediano de conclusão caiu 30.7%.
- As chamadas a 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 do runtime, essa vantagem não se traduziu em menos interações. Na prática, o agente em heredoc fez menos chamadas a ferramentas.
Os resultados coincidiram com as nossas observações anteriores. Dentro de um REPL, o agente costumava correr um pequeno pedaço de código, examinar o resultado e só depois decidir o que fazer a seguir. Ciclos, filtros e decisões que podiam ter sido tratados dentro de um único programa acabavam, em vez disso, distribuídos por várias trocas entre modelo e ferramenta.
Os dois ambientes oferecem um poder expressivo semelhante. A diferença de eficiência entre eles vem sobretudo de como os seus padrões de interação moldam o comportamento do agente. Pelo menos nestas quatro tarefas de agente-navegador, o heredoc incentivou de forma mais consistente o modelo a organizar um programa completo, a colocar ciclos, filtragem e decisões dentro do código, e a evitar as idas e voltas extra da tomada de decisão passo a passo.
Também examinámos se o mesmo padrão se mantinha a maior escala, comparando o ego-browser com um produto semelhante de automação de navegador baseado em REPL no dataset Odysseys. Ao contrário da experiência controlada acima, esta comparação envolveu dois produtos completos, e não o mesmo modelo a operar através de duas interfaces. É por isso útil como comparação geral de eficiência, mas as suas diferenças não podem ser atribuídas inteiramente a heredoc versus REPL.
Isto não é uma vitória permanente para o heredoc
Não acreditamos que o heredoc seja inerentemente superior ao REPL.
A nossa conclusão depende das capacidades dos modelos, da distribuição dos seus dados de treino e do desenho das ferramentas de agentes tal como existem em 2026.
Os agentes de hoje são, em geral, melhores a produzir um bloco de código completo de uma só vez. As suas ferramentas de shell também são concebidas em torno de um ciclo de vida simples: submeter um comando, esperar que termine e devolver o resultado. Nessas condições, o heredoc facilita reduzir o número de rondas de interação e mover o controlo de fluxo para código executado localmente.
Essas condições podem mudar rapidamente.
As futuras ferramentas de agentes poderão oferecer sessões persistentes fiáveis, outputs estruturados e recuperação robusta de estado. Os agentes poderão deixar de ter de gerir prompts de REPL, estado de processo e sessões interrompidas por conta própria. Um treino direcionado também poderia ensinar os modelos a submeter programas completos de forma proativa dentro de um REPL, em vez de cair numa interação passo a passo desnecessária.
Se isso acontecer, os REPLs poderão preservar as vantagens da reutilização de estado e do feedback imediato sem exigir mais chamadas ao modelo. Podem até tornar-se a melhor escolha para tarefas com inicialização dispendiosa, estado de longa duração ou um fluxo de trabalho genuinamente exploratório.
É por isso que o título especifica 2026. Não estamos a afirmar ter descoberto uma lei permanente. É um juízo de engenharia válido para este momento, baseado nos modelos e nas ferramentas de agentes disponíveis hoje.