Pourquoi une exécution de style héréditaire convient mieux aux agents IA qu'un REPL en 2026

Les premiers agents de codage ont révélé quelque chose d'étonnamment puissant : donnez à un agent accès à Bash, et il peut faire presque tout : de l'écriture de code et la collecte de contexte à la gestion de flux de travail Git complets.

Cette idée a contribué à alimenter un mouvement plus large vers les logiciels CLI-first. Les interfaces de ligne de commande ont commencé à ressembler au moyen standard de rendre des applications complexes accessibles aux agents IA, donnant naissance à un slogan familier :

La CLI est tout ce dont vous avez besoin.

Mais il y a un coût caché. Les agents utilisent souvent un terminal un peu comme le ferait un humain : exécutez une commande courte, inspectez le résultat, puis décidez quoi faire ensuite. À mesure que les tâches deviennent plus complexes, cela crée davantage d'allers-retours entre le modèle et ses outils, ce qui signifie plus d'appels LLM, plus de contexte perdu et plus de temps passé à attendre.

Au lieu de demander aux agents d’assembler des scripts shell compliqués, nous préférerions qu’ils coordonnent les tâches dans un langage de programmation qu’ils comprennent déjà. Cela conduit à une architecture légèrement différente :

Conservez la CLI comme point d’entrée universel, mais utilisez le code comme moyen réel d’interagir avec le logiciel.

L'agent soumet un bloc de code contenant les opérations, les décisions et le traitement des données qui seraient autrement répartis sur plusieurs cycles d'interaction. Le runtime local exécute ensuite le flux de travail.

ego-browser a été construit autour de cette idée. Sa CLI lance un environnement programmable, le navigateur expose ses capacités à travers un petit ensemble de fonctions et l'agent utilise ses compétences en programmation existantes pour composer ces fonctions et les orchestrer.

Dans cet article, nous comparons Hérédoc et REPL, deux façons d'exécuter du code via une CLI, et partagez les résultats expérimentaux de ego-browser. Avec heredoc, l'agent a terminé les mêmes tâches en 44 % de cycles d'exécution en moins, avec 35,5 % d'appels d'outils en moins, pour un coût 21,6 % inférieur.

« La CLI est tout ce dont vous avez besoin » — et alors ?

L'affirmation selon laquelle « la CLI est tout ce dont vous avez besoin » suppose que le modèle sait déjà comment utiliser cette CLI.

Pour les outils connus tels que Git, Docker et FFmpeg, cela ne pose généralement pas de problème. Les modèles ont vu d'innombrables commandes, didacticiels, scripts et messages d'erreur au cours de la formation, et connaissent déjà les arguments et la manière dont les commandes s'articulent.

Mais lorsque nous construisons une toute nouvelle CLI pour les agents, la situation change. Chaque CLI possède ses propres sous-commandes, arguments, formats de sortie et sémantique d'erreur. Pour le modèle, il s’agit essentiellement d’un nouveau mini-langage. Même avec une documentation complète, le modèle doit d'abord apprendre les règles, puis comprendre, grâce à des appels répétés, comment les commandes s'emboîtent.

Exposez plutôt les mêmes fonctionnalités qu'une API JavaScript ou une API dans tout autre langage, et le modèle doit encore apprendre les nouveaux concepts de domaine, mais il n'a plus besoin de réapprendre le flux de contrôle, les structures de données ou la composition. Les boucles, les conditions, la gestion des exceptions et le traitement des données restent tous dans un langage de programmation qu'il connaît déjà.

Take a simple task: open a webpage and read its main heading. If ego-browser exposed a traditional command-style interface, the agent might need several steps to finish it:

# 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

Après chaque étape, l'agent attend l'outil, lit le résultat et décide quoi faire ensuite.

L'interface de code que ego-browser utilise lui permet en réalité d'exprimer l'ensemble du workflow en une seule fois :

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

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

Les deux approches obtiennent la même chose. L'interface de style commande divise le processus en plusieurs cycles d'interaction modèle-outil ; l'interface de code permet à l'agent d'écrire une seule fois le processus complet et de le transmettre au runtime local.

C'est exactement l'idée de conception mentionnée précédemment : conserver la CLI comme point d'entrée universel, mais utiliser le code comme interface réelle avec le logiciel. Il conserve l'avantage de la CLI d'être facile à appeler et à intégrer, tout en permettant au modèle d'utiliser les compétences de programmation dont il dispose déjà pour la composition et l'orchestration.

Quand la CLI devient une passerelle vers le code

Une fois qu'une CLI accepte le code, la question suivante est de savoir comment l'agent doit-il transmettre ce code à l'environnement d'exécution ?

À proprement parler, heredoc est la syntaxe d'entrée du shell et REPL est le mode d'exécution d'un interpréteur ; les deux ne sont pas sur la même couche d'abstraction. Ce que cet article compare en réalité, c'est l'exécution de code one-shot entrée via un hérédoc dans ego-browser, par rapport à une session interactive persistante construite sur un REPL. Par souci de concision, nous les appellerons simplement heredoc et REPL à partir de maintenant.

Une option est l'hérdoc. Dans ego-browser, l'agent soumet un bloc entier de JavaScript en une seule fois :

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

Le shell transmet le code à ego-browser, attend qu'il se termine, reçoit le résultat et se termine. Pour l’agent, cela se comporte comme un appel d’outil conventionnel :

Submit command → wait for process → receive result

A REPL works differently. L'interpréteur reste actif, permettant à l'agent de saisir du code à plusieurs reprises tout en conservant les variables et l'état de la session :

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

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

En termes de pouvoir expressif, les deux sont essentiellement équivalents. Un REPL peut exécuter un programme complet avec des boucles, des conditions et une gestion des exceptions en une seule fois, et un heredoc ne peut soumettre qu'une seule ligne.

La différence évidente réside dans le cycle de vie du processus. Avec un hérdoc, le processus se termine dès que le code termine son exécution ; un REPL maintient le processus d'interprétation en vie, en attendant d'autres entrées. Cela signifie également que les deux imposent des exigences différentes aux outils des agents. Un hérdoc s'exécute directement sur le modèle requête-réponse familier :

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

REPL demande plus à l'outil : processus persistants, gestion des sessions, saisie continue, interruption et récupération. La plupart des outils Bash intégrés à la plupart des agents ne disposent pas de ces fonctionnalités. Parmi les produits grand public d'aujourd'hui, seul Codex les prend en charge raisonnablement bien. Et la prise en charge des outils n'est qu'une condition nécessaire pour utiliser un REPL. Cela ne décide pas de la manière dont le modèle en utilisera réellement un. Même lorsque les deux environnements peuvent exécuter le même code, le modèle peut toujours écrire du code différemment dans chacun.

Comment les modèles écrivent le code dans chaque environnement

En théorie, un modèle a la même capacité de programmation dans les deux environnements. En pratique, nous avons observé une différence comportementale constante :

• Dans un REPL, le modèle a tendance à saisir le code de manière incrémentielle.
• Dans un hérdoc, il est plus probable de générer un programme complet en un seul passage.

Les logiciels destinés aux humains doivent tenir compte de l’ergonomie. Les logiciels pour agents nécessitent une discipline similaire : appelez-la ingénierie de l'expérience modèle. Une interface doit fonctionner avec les modèles de schémas comportementaux développés lors de la formation.

Le contraste entre REPL et Heredoc reflète la distribution de leurs données de formation.

Les exemples REPL proviennent généralement de didacticiels, de sessions de débogage et d'échanges de questions-réponses. Leur schéma typique est exploratoire :

> Get the page
< Return page information

> Find an element
< Return element information

> Read its contents
< Return the text

Les blocs de code Heredoc ressemblent davantage à des scripts ou à des fichiers sources. Ils ont des limites de début et de fin explicites, ce qui encourage le modèle à produire un flux de travail continu :

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

console.log(text);

Cela ne signifie pas qu'un REPL est incapable d'exécuter des programmes complets. Le modèle pourrait soumettre le même bloc de code à un REPL en une seule étape.

La distinction est contextuelle. Un REPL encourage un exécuter, observer, continuer modèle. Un hérdoc encourage un organiser d'abord, puis exécuter modèle.

Cette tendance détermine également où réside le flux de contrôle. Dans un REPL, le modèle est plus susceptible de diviser la tâche en plusieurs étapes et de décider quoi faire après chaque résultat. Dans un hérédoc, il est plus probable de placer les boucles, les conditions, le filtrage et le traitement des données directement dans le programme et de laisser le runtime local les gérer.

Ce que les expériences ont montré

Parmi les outils d'agent traditionnels que nous avons pu intégrer de manière fiable, Codex a fourni les capacités d'exécution requises par un REPL persistant. So we built an automated benchmark on the Codex SDK: the same agent completed four types of real browser tasks through both REPL and heredoc, and we aggregated the results across repeated runs for comparison.

Les tâches étaient :

• Analyse du post de tendance X : Collectez les publications originales de OpenAI des sept derniers jours, excluez les publications épinglées, les republications et les réponses, classez les cinq premiers par vues et calculez leurs taux d'engagement et leur moyenne globale.
• OpenAI demande d'emploi : Trouvez le bon poste d'infrastructure cloud à San Francisco, téléchargez un CV, remplissez le formulaire de candidature et arrêtez-vous avant la soumission finale.
• Redfin calcul hypothécaire : Filtrez les propriétés à Austin par type de maison et prix, ouvrez le premier résultat après le tri, modifiez l'acompte à 20 % et récupérez le paiement mensuel estimé mis à jour.
• Expedia recherche de vol : Trouvez un vol aller simple sans escale de JFK à MIA, sélectionnez l'option la moins chère auprès d'une compagnie aérienne spécifiée, saisissez les informations du passager et arrêtez-vous avant le paiement.

Ces tâches couvraient bien plus que l’ouverture de pages et la lecture de texte. Ils comprenaient l'extraction structurée, le filtrage conditionnel, la navigation entre les pages, le téléchargement de fichiers, le remplissage de formulaires, les modifications de l'état des pages et les calculs, couvrant la plupart des opérations courantes effectuées par les agents de navigation.

Les deux approches ont réalisé la plupart des tâches. Heredoc a obtenu un taux de réussite de 77,5 %, contre 75,0 % pour REPL. La différence de fiabilité était modeste.

La plus grande différence était l’efficacité :

• Le délai de réalisation moyen a diminué 35.0%.
• Le délai médian d’achèvement a diminué 30.7%.
• Les appels d’outils ont échoué 35.5%.
• La consommation de tokens a diminué de 29.8%.
• Le coût moyen a diminué 21.6%.

Bien qu'un REPL puisse réutiliser l'état d'exécution, cet avantage n'a pas produit moins d'interactions. En pratique, l’agent héréditaire faisait moins d’appels d’outils.

Les résultats correspondent à nos observations précédentes. Une fois dans un REPL, l'agent exécutait souvent un petit morceau de code, examinait le résultat, puis décidait quoi faire ensuite. Les boucles, les filtres et les décisions qui auraient pu être gérés dans un seul programme étaient plutôt répartis sur plusieurs échanges modèle-outil.

Les deux environnements offrent une puissance expressive similaire. Leur différence d’efficacité vient principalement de la façon dont leurs modèles d’interaction façonnent le comportement des agents. Au moins pour ces quatre tâches d'agent de navigateur, Heredoc encourageait plus systématiquement le modèle à organiser un programme complet, à pousser les boucles, le filtrage et les décisions dans le code, et à éviter les allers-retours supplémentaires liés à la prise de décision étape par étape.

Nous avons également examiné si le même modèle se maintenait à plus grande échelle en comparant ego-browser avec un produit similaire d'automatisation de navigateur basé sur REPL sur l'ensemble de données Odysseys. Contrairement à l’expérience contrôlée ci-dessus, cette comparaison impliquait deux produits complets plutôt que le même modèle fonctionnant via deux interfaces. Il est donc utile comme comparaison d'efficacité globale, mais ses différences ne peuvent pas être entièrement attribuées à Heredoc par rapport à REPL.

Ce n'est pas une victoire permanente pour Heredoc

Nous ne pensons pas qu'Heredoc soit intrinsèquement supérieur à REPL.

Notre conclusion dépend des capacités des modèles, de la distribution de leurs données de formation et de la conception des outils d'agent tels qu'ils existent en 2026.

Les agents d'aujourd'hui sont généralement plus doués pour produire un bloc complet de code en un seul passage. Leurs outils shell sont également conçus autour d'un cycle de vie simple : soumettre une commande, attendre qu'elle se termine et renvoyer le résultat. Dans ces conditions, heredoc facilite la réduction des cycles d'interaction et le déplacement du flux de contrôle vers du code exécuté localement.

Ces conditions peuvent changer rapidement.

Les futurs outils d'agent pourraient fournir des sessions persistantes fiables, des sorties structurées et une récupération d'état robuste. Les agents n’auront peut-être plus besoin de gérer eux-mêmes les invites REPL, l’état du processus et les sessions interrompues. Une formation ciblée pourrait également apprendre aux modèles à soumettre des programmes complets de manière proactive dans un REPL au lieu de tomber dans une interaction étape par étape inutile.

Si cela se produit, les REPL pourraient préserver les avantages de la réutilisation de l’état et du retour immédiat sans nécessiter davantage d’appels de modèles. Ils peuvent même devenir le meilleur choix pour les tâches nécessitant une initialisation coûteuse, un état de longue durée ou un flux de travail véritablement exploratoire.

C'est pourquoi le titre précise 2026. Nous ne prétendons pas avoir découvert une loi permanente. Il s’agit d’un jugement technique ponctuel basé sur les modèles et les outils d’agent disponibles aujourd’hui.