Perché l'esecuzione in stile heredoc è più adatta per gli agenti AI rispetto a un REPL nel 2026

I primi agenti di codifica hanno rivelato qualcosa di sorprendentemente potente: fornire a un agente l'accesso a Bash e può fare quasi qualsiasi cosa, dalla scrittura di codice e la raccolta di contesto alla gestione di flussi di lavoro Git completi.

Questa intuizione ha contribuito ad alimentare un movimento più ampio verso il software CLI-first. Le interfacce della riga di comando iniziarono ad assomigliare al modo standard per rendere accessibili applicazioni complesse agli agenti AI, dando origine a uno slogan familiare:

La CLI è tutto ciò di cui hai bisogno.

Ma c’è un costo nascosto. Gli agenti spesso utilizzano un terminale proprio come farebbe un essere umano: eseguono un breve comando, esaminano il risultato e poi decidono cosa fare dopo. Man mano che le attività diventano più complesse, si creano più scambi tra il modello e i suoi strumenti, il che significa più chiamate LLM, più spreco di contesto e più tempo trascorso in attesa.

Invece di chiedere agli agenti di assemblare complicati script di shell, preferiremmo che coordinassero le attività in un linguaggio di programmazione che già comprendono. Ciò porta a un'architettura leggermente diversa:

Mantieni la CLI come punto di ingresso universale, ma utilizza il codice come modo effettivo per interagire con il software.

L'agente invia un blocco di codice che contiene le operazioni, le decisioni e l'elaborazione dei dati che altrimenti sarebbero distribuite in diversi cicli di interazione. Il runtime locale esegue quindi il flusso di lavoro.

ego-browser è stato costruito attorno a questa idea. La sua CLI avvia un ambiente programmabile, il browser espone le sue capacità attraverso un piccolo insieme di funzioni e l'agente utilizza le sue capacità di programmazione esistenti per comporre tali funzioni e orchestrarli.

In questo articolo confrontiamo quidoc e REPL, due modi di eseguire il codice tramite una CLI e condividere i risultati sperimentali di ego-browser. Con Heredoc, l'agente ha completato le stesse attività con il 44% in meno di cicli di esecuzione, con il 35,5% in meno di chiamate allo strumento, a un costo inferiore del 21,6%.

“La CLI è tutto ciò di cui hai bisogno” – e allora?

L'affermazione che "la CLI è tutto ciò di cui hai bisogno" presuppone che il modello sappia già come utilizzare quella CLI.

Per strumenti noti come Git, Docker e FFmpeg questo di solito non è un problema. I modelli hanno visto innumerevoli comandi, tutorial, script e messaggi di errore durante l'addestramento e conoscono già gli argomenti e il modo in cui i comandi si incastrano tra loro.

Ma quando creiamo una nuovissima CLI per gli agenti, il quadro cambia. Ogni CLI ha i propri sottocomandi, argomenti, formati di output e semantica degli errori. Per il modello, si tratta essenzialmente di un nuovo mini-linguaggio. Anche con una documentazione completa, il modello deve prima apprendere le regole, quindi capire attraverso ripetute chiamate come i comandi si incastrano tra loro.

Esponi invece le stesse funzionalità di un'API JavaScript o di un'API in qualsiasi altro linguaggio e il modello deve ancora apprendere i nuovi concetti di dominio, ma non ha più bisogno di apprendere nuovamente il flusso di controllo, le strutture dei dati o la composizione. I cicli, le condizioni, la gestione delle eccezioni e l'elaborazione dei dati rimangono tutti in un linguaggio di programmazione che già conosce.

Svolgi un compito semplice: apri una pagina web e leggi il suo titolo principale. Se ego-browser espone un'interfaccia in stile comando tradizionale, l'agente potrebbe richiedere diversi passaggi per 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

Dopo ogni passaggio, l'agente attende lo strumento, legge il risultato e decide cosa fare dopo.

L'interfaccia del codice effettivamente utilizzata da ego-browser consente di esprimere l'intero flusso di lavoro in una sola volta:

await taskSpaces.useOrCreate("read example page");
await browser.openOrReuseTab("https://example.com", { wait: true });

const heading = await page.getByRole("heading").textContent();
console.log(heading);

Entrambi gli approcci ottengono la stessa cosa. L'interfaccia in stile comando suddivide il processo in più cicli di interazione modello-strumento; l'interfaccia del codice consente all'agente di scrivere il processo completo una volta e di trasmetterlo al runtime locale.

Questa è esattamente l'idea progettuale menzionata in precedenza: mantenere la CLI come punto di ingresso universale, ma utilizzare il codice come interfaccia effettiva per il software. Mantiene il vantaggio della CLI di essere facile da richiamare e integrare, consentendo al tempo stesso al modello di utilizzare le competenze di programmazione di cui già dispone per la composizione e l'orchestrazione.

Quando la CLI diventa un gateway per il codice

Una volta che una CLI accetta il codice, la domanda successiva è: come dovrebbe l'agente consegnare quel codice all'ambiente di esecuzione?

A rigor di termini, heredoc è la sintassi di input della shell e REPL è la modalità di esecuzione di un interprete; i due non sono allo stesso livello di astrazione. Ciò che questo articolo mette effettivamente a confronto è l'esecuzione di codice one-shot immesso tramite un heredoc in ego-browser, rispetto a una sessione interattiva persistente basata su un REPL. Per brevità, da qui in poi li chiameremo semplicemente heredoc e REPL.

Un'opzione è Heredoc. In ego-browser, l'agente invia un intero blocco di JavaScript in una volta sola:

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

La shell passa il codice a ego-browser, attende che finisca, riceve il risultato ed esce. Per l'agente, questo si comporta come una chiamata a uno strumento convenzionale:

Submit command → wait for process → receive result

Un REPL funziona diversamente. L'interprete rimane vivo, consentendo all'agente di inserire ripetutamente il codice mantenendo le variabili e lo stato della sessione:

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

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

In termini di forza espressiva, i due sono sostanzialmente equivalenti. Un REPL può eseguire un programma completo con cicli, condizioni e gestione delle eccezioni in un colpo solo, mentre un heredoc può inviare solo una singola riga.

La chiara differenza è il ciclo di vita del processo. Con un heredoc, il processo termina non appena il codice termina l'esecuzione; un REPL mantiene attivo il processo dell'interprete, in attesa di ulteriori input. Ciò significa anche che i due pongono esigenze diverse sugli strumenti degli agenti. Un heredoc funziona direttamente sul modello richiesta-risposta familiare:

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

REPL richiede di più allo strumento: processi persistenti, gestione delle sessioni, input continuo, interruzione e ripristino. La maggior parte degli strumenti Bash integrati negli agenti non dispone di queste funzionalità. Tra i prodotti tradizionali oggi, solo Codex li supporta ragionevolmente bene. E il supporto dello strumento è solo una condizione necessaria per l'utilizzo di un REPL. Non decide come il modello ne utilizzerà effettivamente uno. Anche quando entrambi gli ambienti possono eseguire lo stesso codice, il modello potrebbe comunque scrivere codice in modo diverso in ciascuno.

Come i modelli scrivono il codice in ogni ambiente

In teoria, un modello ha la stessa capacità di programmazione in entrambi gli ambienti. In pratica, abbiamo osservato una differenza comportamentale consistente:

• In un REPL, il modello tende a inserire il codice in modo incrementale.
• In un heredoc, è più probabile che generi un programma completo in un unico passaggio.

Il software per gli esseri umani deve tenere conto dell’ergonomia. Il software per agenti ha bisogno di una disciplina simile: chiamala ingegneria dell'esperienza del modello. Un'interfaccia dovrebbe funzionare con i modelli di modelli comportamentali sviluppati durante la formazione.

Il contrasto tra REPL e heredoc rispecchia la distribuzione dei loro dati di addestramento.

Gli esempi REPL provengono solitamente da tutorial, sessioni di debug e scambi di domande e risposte. Il loro modello tipico è esplorativo:

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

I blocchi di codice Heredoc assomigliano più a script o file sorgente. Hanno confini iniziali e finali espliciti, che incoraggiano il modello a produrre un flusso di lavoro continuo:

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

console.log(text);

Ciò non significa che un REPL non sia in grado di eseguire programmi completi. Il modello potrebbe inviare lo stesso blocco di codice a un REPL in un unico passaggio.

La distinzione è contestuale. Una REPL incoraggia un eseguire, osservare, continuare modello. Un eredoco incoraggia un prima organizzare, poi eseguire modello.

Questa tendenza determina anche dove risiede il flusso di controllo. In un REPL, è più probabile che il modello divida l'attività in più fasi e decida cosa fare dopo ogni risultato. In un heredoc, è più probabile inserire cicli, condizioni, filtri ed elaborazione dei dati direttamente nel programma e lasciare che sia il runtime locale a gestirli.

Cosa hanno mostrato gli esperimenti

Tra gli strumenti principali dell'agente che abbiamo potuto integrare in modo affidabile, Codex ha fornito le capacità di esecuzione richieste da un REPL persistente. Abbiamo quindi creato un benchmark automatizzato sull'SDK Codex: lo stesso agente ha completato quattro tipi di attività del browser reali sia tramite REPL che tramite heredoc e abbiamo aggregato i risultati di esecuzioni ripetute per il confronto.

I compiti erano:

• X analisi post trend: Raccogli i post originali di OpenAI degli ultimi sette giorni, escludi post fissati, ripubblicazioni e risposte, classifica i primi cinque in base alle visualizzazioni e calcola i tassi di coinvolgimento e la media complessiva.
• OpenAI domanda di lavoro: Trova la posizione corretta nell'infrastruttura cloud a San Francisco, carica un curriculum, completa il modulo di domanda e fermati prima dell'invio finale.
• Calcolo mutuo Redfin: Filtra le proprietà ad Austin per tipo di casa e prezzo, apri il primo risultato dopo l'ordinamento, modifica l'acconto al 20% e recupera il pagamento mensile stimato aggiornato.
• Ricerca voli Expedia: Trova un volo diretto di sola andata da JFK a MIA, seleziona l'opzione più economica di una compagnia aerea specifica, inserisci le informazioni del passeggero e fermati prima del pagamento.

Queste attività riguardavano qualcosa di più dell'apertura di pagine e della lettura del testo. Includevano estrazione strutturata, filtraggio condizionale, navigazione tra le pagine, caricamento di file, completamento di moduli, modifiche dello stato della pagina e calcoli, coprendo la maggior parte delle operazioni comuni eseguite dagli agenti del browser.

Entrambi gli approcci hanno completato la maggior parte dei compiti. Heredoc ha ottenuto una percentuale di successo del 77,5%, rispetto al 75,0% di REPL. La differenza di affidabilità era modesta.

La differenza più grande era l’efficienza:

• Il tempo medio di completamento è diminuito 35.0%.
• Il tempo medio di completamento è diminuito 30.7%.
• Le chiamate agli strumenti sono diminuite 35.5%.
• Il consumo di token è diminuito 29.8%.
• Il costo medio è diminuito 21.6%.

Sebbene un REPL possa riutilizzare lo stato di runtime, questo vantaggio non ha prodotto meno interazioni. In pratica, l'agente heredoc ha effettuato meno chiamate allo strumento.

I risultati corrispondevano alle nostre osservazioni precedenti. Una volta all'interno di un REPL, l'agente spesso eseguiva un piccolo pezzo di codice, esaminava il risultato e poi decideva cosa fare dopo. Loop, filtri e decisioni che avrebbero potuto essere gestiti all'interno di un singolo programma sono stati invece distribuiti su diversi scambi modello-strumento.

I due ambienti offrono una potenza espressiva simile. La loro differenza di efficienza deriva principalmente dal modo in cui i loro modelli di interazione modellano il comportamento degli agenti. Almeno per queste quattro attività dell'agente browser, heredoc ha incoraggiato in modo più coerente il modello a organizzare un programma completo, inserire cicli, filtri e decisioni nel codice ed evitare i viaggi di andata e ritorno aggiuntivi del processo decisionale passo dopo passo.

Abbiamo anche esaminato se lo stesso modello fosse valido su scala più ampia confrontando ego-browser con un prodotto di automazione del browser simile basato su REPL sul set di dati Odysseys. A differenza dell'esperimento controllato di cui sopra, questo confronto ha coinvolto due prodotti completi anziché lo stesso modello funzionante attraverso due interfacce. È quindi utile come confronto dell'efficienza complessiva, ma le sue differenze non possono essere attribuite interamente a Heredoc rispetto a REPL.

Questa non è una vittoria permanente per Heredoc

Non crediamo che Heredoc sia intrinsecamente superiore a REPL.

La nostra conclusione dipende dalle capacità dei modelli, dalla distribuzione dei dati di addestramento e dalla progettazione degli strumenti degli agenti così come esistono nel 2026.

Gli agenti di oggi sono generalmente più bravi a produrre un blocco completo di codice in un unico passaggio. Anche i loro strumenti di shell sono progettati attorno a un ciclo di vita semplice: inviare un comando, attendere che venga terminato e restituire il risultato. In queste condizioni, heredoc semplifica la riduzione dei cicli di interazione e lo spostamento del flusso di controllo nel codice eseguito localmente.

Tali condizioni potrebbero cambiare rapidamente.

I futuri strumenti degli agenti potrebbero fornire sessioni persistenti affidabili, output strutturati e un robusto ripristino dello stato. Potrebbe non essere più necessario che gli agenti gestiscano da soli i prompt REPL, lo stato dei processi e le sessioni interrotte. Una formazione mirata potrebbe anche insegnare ai modelli a presentare programmi completi in modo proattivo all’interno di un REPL invece di cadere in inutili interazioni passo-passo.

Se ciò accadesse, i REPL potrebbero preservare i vantaggi del riutilizzo statale e del feedback immediato senza richiedere ulteriori chiamate a modello. Potrebbero persino diventare la scelta migliore per attività con inizializzazione costosa, stato di lunga durata o un flusso di lavoro realmente esplorativo.

Ecco perché il titolo lo specifica 2026. Non stiamo affermando di aver scoperto una legge permanente. Si tratta di un giudizio tecnico puntuale basato sui modelli e sugli strumenti degli agenti oggi disponibili.