La thèse du CLI

Trois fils Hacker News en une semaine. 1 638 points cumulés. Une seule conclusion : l’IDE est fait pour les humains. Le CLI est fait pour les agents.¹²³

La séparation planification/exécution de Boris Tane (716 points) s’exécute entièrement dans le terminal.¹ L’analyse « Making MCP Cheaper via CLI » (304 points) a mesuré une réduction de 94 % des tokens en remplaçant les appels d’outils MCP par claude --print.³ Le projet just-bash de Vercel (87 points) a démontré que supprimer 80 % des outils d’un agent rendait tout plus rapide, moins cher et plus fiable.⁴ Un benchmark distinct a révélé que les approches CLI utilisaient 35 fois moins de tokens que MCP pour des tâches équivalentes.¹⁰

Ce schéma revient sans cesse parce que l’architecture l’impose. Les agents ont besoin de composabilité, de scriptabilité et d’un overhead minimal. Les CLI offrent ces trois qualités. Les IDE n’en offrent aucune.

TL;DR

L’architecture agent CLI-first coûte 94 % de moins en overhead de tokens que les approches basées sur MCP, s’exécute 3,5 fois plus vite et se compose avec les outils Unix standard. La séparation planification/exécution fonctionne parce que les artefacts CLI sont des fichiers markdown portables, et non de l’état IDE. Remote Control rend les agents CLI supervisables à distance sans sacrifier l’avantage de composabilité. Tout système d’agents sérieux converge vers le terminal parce que le terminal est là où l’automatisation vit déjà.

La séparation planification/exécution

Boris Tane a documenté un workflow en trois phases que 454 commentateurs HN ont validé avec leurs propres variantes : recherche, planification, implémentation.¹ L’observation cruciale : ne jamais laisser l’agent écrire du code tant que vous n’avez pas examiné et approuvé un plan écrit.

Le workflow produit des artefacts markdown à chaque étape. research.md capture l’analyse du codebase. plan.md capture la stratégie d’implémentation avec des extraits de code. Le développeur examine dans son éditeur, ajoute des annotations en ligne, et renvoie le plan annoté avec une instruction explicite : « n’implémente pas encore ». Le cycle d’annotation se répète une à six fois avant qu’une seule ligne de code ne soit écrite.

La boucle entière passe par claude dans le terminal. Pas de plugin IDE. Pas d’outil de diff visuel. Des fichiers markdown en entrée, des fichiers markdown en sortie. Les artefacts survivent à la compaction de la fenêtre de contexte parce qu’ils existent sous forme de fichiers, et non d’état de conversation.

Ma boucle autonome implémente la même séparation à l’échelle machine. Un fichier PRD définit des stories avec des critères d’acceptation. Un agent frais est généré pour chaque story, recevant un briefing sur l’état git actuel et ce que les agents précédents ont accompli. L’agent implémente, un vérificateur indépendant lance les tests (sans jamais faire confiance à l’auto-évaluation de l’agent), et trois reviewers de code évaluent le diff en parallèle. L’orchestration entière passe par des appels claude --print dans des scripts bash. Pas de framework, pas de runtime, pas de serveur.

La séparation planification/exécution fonctionne dans le terminal parce que le terminal rend la séparation structurelle. La planification produit des fichiers. L’exécution consomme des fichiers. La frontière entre les deux phases est un fichier sur le disque, visible et auditable, et non une transition d’état enfouie dans un plugin IDE.

Pourquoi le CLI surpasse l’IDE pour les agents

L’argument repose sur trois piliers : le coût, la composabilité et l’efficacité contextuelle.

Coût : réduction de 94 % des tokens

Kan Yilmaz a mesuré l’overhead en tokens de MCP par rapport au CLI dans quatre scénarios.³ Les chiffres parlent d’eux-mêmes :

MCP injecte les schémas d’outils dans chaque conversation. Avec 84 outils, l’overhead des schémas seul consomme 15 540 tokens avant que l’agent ne fasse quoi que ce soit. Les appels CLI ne comportent aucun overhead de schéma parce que les modèles comprennent déjà les interfaces en ligne de commande standard.¹⁰ Un utilisateur a documenté MCP_DOCKER consommant 125 964 tokens pour 135 outils.¹⁴

Jannik Reinhard a réalisé un benchmark parallèle sur une tâche de conformité Intune : 145 000 tokens via MCP contre 4 150 tokens via CLI pour un résultat équivalent.¹⁰ L’agent CLI avait 95 % de sa fenêtre de contexte disponible pour le raisonnement. L’agent MCP dépensait la majorité de son budget en définitions d’outils.

Composabilité : les pipes Unix fonctionnent déjà

L’équipe v0 de Vercel a supprimé 80 % des outils de leur agent et les a remplacés par un simple environnement bash.⁹ Les résultats :

Andrew Qu a expliqué le raisonnement : « Nous résolvions des problèmes que le modèle pouvait gérer seul. » Les systèmes de fichiers, grep, les pipes et les redirections se composent déjà. Les modèles les comprennent. Construire des outils MCP personnalisés pour des opérations que cat | grep | jq gère nativement ajoute de l’overhead sans ajouter de capacité.¹³

La propre documentation de Anthropic confirme ce schéma. Claude Code suit la philosophie Unix : redirigez-y des logs, exécutez-le en CI, chaînez-le avec d’autres outils.⁵ Le mode headless (claude -p) prend en charge la sortie structurée JSON, l’application de schémas et la reprise de session via des identifiants de session capturés. Anthropic positionne le mode headless comme la voie d’intégration principale pour les workflows CI/CD et scriptés.⁵

Simon Willison formule l’implication : écrire du code est désormais peu coûteux.⁶ Le corollaire que personne ne veut entendre, c’est que la vérification est désormais la partie coûteuse. Les agents CLI se composent avec l’infrastructure de vérification existante. Les lanceurs de tests, les linters, les vérificateurs de types, les scanners de sécurité, les pipelines de déploiement : tous des outils en ligne de commande. Un agent IDE a besoin d’un plugin pour chacun. Un agent CLI redirige vers eux via des pipes.

Efficacité contextuelle : raisonner sur le signal, pas le bruit

La fenêtre de contexte est finie. Chaque token dépensé en schémas d’outils, historique de conversation et overhead MCP est un token indisponible pour le raisonnement. L’architecture CLI maintient le budget de contexte léger par conception.

Un appel frais claude --print reçoit un prompt ciblé (~2K tokens) au lieu d’hériter d’un contexte de conversation complet (~100K+ tokens). Chaque opération démarre proprement. Pas d’état accumulé. Pas de définitions d’outils obsolètes. Pas de dérive conversationnelle.

Mon infrastructure exécute 84 hooks sur 17 événements de cycle de vie, le tout orchestré par des appels CLI. Chaque génération d’agent reçoit un briefing : l’état git actuel, un résumé de ce que les agents précédents ont accompli, et les critères d’acceptation pour sa tâche unique. Du briefing plutôt que de la mémoire. Les modèles exécutent un briefing clair mieux qu’ils ne naviguent dans 30 étapes de contexte accumulé.

Une analyse académique de la philosophie Unix dans les systèmes agentiques a formalisé le principe : réduire les interfaces diverses en une abstraction uniforme, en acceptant une certaine perte de spécialisation en échange de composabilité et de tractabilité.¹¹ Les abstractions de type fichier et les spécifications basées sur le code réduisent la charge cognitive et d’ingénierie. Les agents CLI héritent de 50 ans de ce travail de conception.

Remote Control change la donne

L’objection évidente aux agents CLI-first : vous perdez le retour visuel d’un IDE. Anthropic a livré une réponse le 25 février 2026. Remote Control se connecte à une session Claude Code locale depuis n’importe quel navigateur ou l’application mobile Claude.² La fonctionnalité a recueilli 531 points et 313 commentaires sur Hacker News.

Remote Control ne déplace rien vers le cloud. L’agent continue de s’exécuter localement. La session terminal s’enregistre auprès de l’API de Anthropic via TLS et interroge pour du travail. Tout le trafic passe par du HTTPS sortant. Aucun port entrant ouvert.²

La fonctionnalité comble le déficit de supervision. Avant Remote Control, les agents CLI avaient deux modes : supervisé (rester devant le terminal) ou non supervisé (partir et espérer). Remote Control crée un troisième : la gouvernance asynchrone. Les demandes d’approbation arrivent sur votre téléphone. Vous approuvez, rejetez ou redirigez depuis n’importe où.

Mon système de hooks classifie les opérations par rayon d’impact. Les opérations locales (écritures de fichiers, lancements de tests) s’auto-approuvent. Les opérations partagées (commits git) avertissent. Les opérations externes (push, déploiements) sont déférées à la revue humaine. Remote Control transforme ce chemin de « déférence » d’une attente bloquante en une notification asynchrone. L’agent continue de travailler sur la story suivante pendant que j’examine la précédente depuis mon téléphone.

L’IDE devient une couche d’affichage, et non l’environnement d’exécution. Vous suivez la progression via Remote Control. Vous intervenez quand les portes de qualité signalent un problème. L’agent CLI fait le travail. L’IDE vous montre le résultat.

Le pattern de l’agent Bash

just-bash de Vercel est un environnement bash simulé avec un système de fichiers virtuel en mémoire, conçu spécifiquement pour les agents IA.⁴ La conception encode trois convictions sur l’architecture des agents :

L’isolation plutôt que le sandboxing. Chaque appel s’exécute de manière isolée. Les variables d’environnement, les fonctions et le répertoire de travail se réinitialisent entre les appels. Le système de fichiers persiste. Le chargement paresseux signifie que les fichiers se chargent à la première lecture et sont mis en cache, ne chargeant jamais les fichiers que l’agent écrit avant de les lire. L’agent ne peut pas contaminer son propre environnement d’une opération à l’autre.

Les outils existants plutôt que les outils personnalisés. Grep a 50 ans et gère exactement ce que les outils de recherche MCP personnalisés répliquent. jq analyse le JSON. curl récupère des URL. Le modèle connaît ces interfaces grâce aux données d’entraînement. Les outils personnalisés nécessitent l’injection de schémas et de la documentation. Les outils standard ne nécessitent ni l’un ni l’autre.

L’architecture minimale plutôt que l’architecture framework. Andrew Qu a capturé le principe : « Les modèles deviennent plus intelligents et les fenêtres de contexte s’agrandissent, donc peut-être que la meilleure architecture d’agent n’est presque pas d’architecture du tout. »¹³

Mon harness valide ce pattern à l’échelle production. Environ 15 000 lignes de bash orchestrant Claude Code. 84 hooks sur 17 types d’événements. Des dispatchers, des portes de qualité, de l’intégration de recherche sémantique, des boucles autonomes. Pas de runtime Python, pas de dépendance framework. Les aspérités de bash (pas de JSON natif, pas d’async, pas de structures de données propres) sont réelles mais résolubles. jq gère le JSON. Le traitement séquentiel est en fait une fonctionnalité : les portes doivent s’exécuter dans l’ordre, pas en concurrence.

Le pattern fonctionne parce que l’orchestration d’agents consiste fondamentalement à lire stdin, prendre une décision et écrire sur stdout. Cette description correspond exactement au dessein de bash. Tout ce qui est plus complexe indique que la décomposition de la tâche était erronée, pas l’outillage.

Le coût comme décision architecturale

Les décisions de coût se composent. Choisir le CLI plutôt que MCP pour les opérations sans état économise 94 % par invocation.³ À 100 opérations par jour, les économies atteignent 228 $/mois rien que sur l’overhead des définitions d’outils.³ Ces économies libèrent du budget pour plus d’opérations, ce qui génère plus d’économies. L’architecture se rentabilise d’elle-même.

Trois couches de coûts se composent indépendamment :

Couche tokens. Compression du prompt système. J’exécute environ 3 500 tokens de prompt système répartis sur un fichier CLAUDE.md et 8 fichiers de règles. Les contraintes surpassent les explications. « Rejeter les appels d’outils correspondant à des chemins sensibles » fait le même travail qu’une explication de 15 lignes sur la raison pour laquelle les identifiants doivent rester protégés. La documentation des bonnes pratiques de Anthropic souligne le même point : les performances de la fenêtre de contexte se dégradent à mesure qu’elle se remplit.⁷ Chaque token gaspillé coûte deux fois : une fois en charges directes d’API, et une fois en qualité de raisonnement dégradée.

Couche agents. Des générations fraîches plutôt que de longues conversations. Chaque story dans une exécution autonome obtient un nouvel agent avec une fenêtre de contexte propre. Geoffrey Huntley a documenté un pattern similaire appelé « The Ralph Loop », exécutant du développement autonome à 10,42 $/heure sur Sonnet.¹² Le contexte ne s’emballe jamais parce que chaque agent démarre à neuf. Les hits de cache sur le prompt système coûtent 90 % de moins (0,50 $ contre 5,00 $ par million de tokens sur Opus 4.6), donc le prompt système répété entre les générations fraîches engendre un overhead minimal.⁸

Couche architecture. CLI pour les opérations sans état, MCP pour celles avec état. Un appel claude --print pour une évaluation ponctuelle n’ajoute aucun overhead de connexion. MCP a du sens quand l’outil a besoin d’un état persistant ou de streaming. La plupart des opérations d’agents sont des évaluations ponctuelles, des classifications ou des tâches de génération de code. Le CLI les gère toutes à moindre coût avec un débogage plus simple.

Un exemple concret de ma boucle autonome la semaine dernière : cinq stories PRD traitées pendant la nuit.¹⁵ Chaque story a généré un agent frais (~2K tokens de briefing), exécuté l’implémentation (~15K tokens en moyenne), puis généré trois agents de revue (~2K tokens chacun). Total par story : ~23K tokens. Le même workflow dans une longue conversation MCP porterait ~100K+ tokens de contexte accumulé par story dès la troisième story. Cinq stories via CLI : ~115K tokens au total. Cinq stories via conversation MCP : ~500K+ tokens au total. Le ratio de coût se compose avec chaque story supplémentaire.

Quand MCP l’emporte encore

La thèse du CLI ne s’oppose pas universellement à MCP. MCP l’emporte dans des scénarios spécifiques où le CLI est en défaut.

Serveurs d’outils avec état. Un navigateur de base de données qui maintient un pool de connexions entre les appels bénéficie du modèle de serveur persistant de MCP. Se reconnecter à chaque appel CLI ajoute de la latence et de l’overhead d’authentification. Si l’outil a besoin d’état entre les invocations, MCP est le choix approprié.

Validation structurée. Les schémas d’outils MCP imposent des contrats entrée/sortie. Un appel CLI accepte du texte arbitraire. Quand l’agent doit fournir une entrée structurée correspondant à un schéma précis (format de clé API, plages de dates, options énumérées), le schéma MCP détecte les entrées malformées avant que l’outil ne les traite. La validation CLI nécessite que l’outil lui-même ou un script wrapper impose les contraintes.

Contrôle d’accès multi-tenant. Les serveurs MCP peuvent imposer des permissions par utilisateur de manière centralisée. Les outils CLI héritent des permissions de l’utilisateur du système d’exploitation. Dans les environnements d’équipe où différents agents ont besoin de différents niveaux d’accès, MCP fournit une autorisation plus granulaire.

Réponses en streaming. Les opérations de longue durée qui produisent une sortie incrémentale (suivi de logs, progression de build, exports de base de données) fonctionnent mieux via le protocole de streaming de MCP qu’avec un appel CLI qui bloque jusqu’à la fin.

La règle de décision : si l’opération est sans état et ponctuelle, utilisez le CLI. Si l’opération nécessite un état persistant, des contrats structurés ou du streaming, utilisez MCP. Dans mon harness, environ 90 % des opérations sont sans état. Les 10 % qui ont besoin de MCP en bénéficient véritablement. Optimiser les 90 % produit le meilleur retour.

Ce que vous pouvez construire aujourd’hui

Trois patterns, chacun réalisable en un après-midi, chacun se composant avec les autres.

Pattern 1 : séparation planification/exécution

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

Chaque phase reçoit des permissions d’outils délimitées. L’agent de planification ne peut pas modifier le code. L’agent d’implémentation ne peut pas naviguer sur le web. Les frontières de fichiers imposent la séparation. Le flag --allowedTools fait l’application au niveau du CLI. Pas de fichier de configuration. Pas de paramètres de plugin. Un flag par invocation, délimité aux permissions exactes requises par cette phase.

Le cycle d’annotation est le différenciateur clé par rapport au simple fait de « mieux prompter ». Vous examinez le plan dans votre éditeur. Vous barrez les parties avec lesquelles vous n’êtes pas d’accord. Vous ajoutez des notes en marge. L’agent lit votre fichier annoté et révise. Le plan s’améliore à chaque passage parce que deux intelligences différentes (la connaissance de domaine humaine, la génération de code du modèle) convergent sur le même document.

Pattern 2 : génération fraîche par tâche

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

Pas de contexte accumulé. Pas de dérive conversationnelle. Chaque agent obtient une fenêtre propre avec un briefing ciblé. Le flag --output-format json capture une sortie structurée incluant les identifiants de session, permettant la reprise déterministe de la conversation si une story nécessite un travail de suivi.

L’étape de vérification indépendante compte plus que l’étape d’implémentation. Les agents présentent ce que j’appelle la vérification fantôme : affirmer que les tests passent sans les exécuter. Lancer pytest en dehors de la fenêtre de contexte de l’agent élimine entièrement ce mode de défaillance. L’agent ne peut pas déformer des résultats qu’il n’a jamais produits.

Pattern 3 : pipeline de revue parallèle

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

Trois agents. Trois perspectives. Zéro état partagé. Les désaccords entre reviewers mettent en lumière exactement les problèmes qu’un seul reviewer manque. L’opérateur & et la commande intégrée wait gèrent le parallélisme. Pas de runtime async. Pas de pool de threads. Pas de framework d’orchestration. Le contrôle de jobs bash fait le travail.

La puissance du pattern : chaque reviewer obtient la fenêtre de contexte complète pour sa seule préoccupation. Un seul reviewer partageant son attention entre la correction, la sécurité et le style performe moins bien que trois spécialistes avec un contexte dédié. Le CLI rend la séparation triviale parce que chaque appel est un processus indépendant avec sa propre mémoire.

Points clés à retenir

Pour les développeurs qui construisent des systèmes d’agents : - Commencez par claude -p pour toute génération d’agents. Ajoutez MCP uniquement quand un état persistant est requis. - Délimitez les permissions d’outils par phase. Les agents de planification lisent. Les agents d’implémentation écrivent. Les agents de revue lisent les diffs. - Budgétisez 94 % de moins pour l’overhead en tokens en choisissant le CLI plutôt que MCP pour les opérations sans état.³

Pour les équipes qui montent en charge sur des workflows autonomes : - Les générations d’agents fraîches préviennent la dérive de contexte et plafonnent les coûts en tokens par opération. - Remote Control transforme le « non supervisé » en « supervisé de manière asynchrone » sans changer l’architecture CLI.² - Les données de Vercel prouvent le résultat contre-intuitif : moins d’outils signifie des taux de réussite plus élevés, pas plus bas.⁴

Pour les architectes qui choisissent une infrastructure d’agents : - Les agents CLI se composent avec les outils CI/CD, de test et de déploiement existants. Aucun travail d’intégration nécessaire. - La philosophie Unix (composer de petits outils via des pipes) précède et surpasse chaque framework spécifique aux agents.¹¹ - Le mur des 10 % de productivité se brise quand vous cessez de traiter l’agent comme un outil de chat et commencez à le traiter comme une infrastructure.

Fait partie de la série AI Engineering. Voir aussi : Claude Code as Infrastructure, Anatomy of a Claw, The Autonomous Loop, et The 10% Wall.