La première génération de CLIs AI pour devs te donnait une boucle de chat et du tool-use. La deuxième génération se consolide autour d'une primitive spécifique suivante : le sous-agent. Claude Code a embarqué son outil Agent plus tôt cette année avec des configs en markdown plus YAML, une délégation explicite via la syntaxe d'appel d'outil, l'invocation parallèle, pis des contextes isolés. Le Gemini CLI de Google vient d'embarquer essentiellement la même primitive. InfoQ a le récap, et la forme est assez proche pour que les utilisateurs de Claude Code la reconnaissent d'un coup d'œil.
Les sous-agents dans Gemini CLI sont définis dans des fichiers markdown avec frontmatter YAML, spécifiant rôles, outils, et lignes directrices comportementales. Ça matche le pattern que les utilisateurs de Claude Code utilisent déjà sous `.claude/agents/`. La délégation est explicite : les utilisateurs assignent des tâches à des agents spécifiques via la syntaxe de prompt, miroir de comment Claude Code invoque l'outil Agent. L'exécution parallèle est supportée. Les exemples de Google incluent l'analyse de différentes parties d'un codebase ou l'exécution de plusieurs tâches de recherche en même temps, et InfoQ note le risque évident : des changements de code en conflit et des limites d'usage accrues par des requêtes concurrentes. Chaque sous-agent roule dans un environnement isolé et retourne un résultat résumé à la session principale, ce qui est la même architecture que Claude Code utilise pour garder le contexte parent léger. Gemini CLI embarque trois sous-agents built-in d'emblée : un assistant general-purpose, un helper CLI, et un agent d'investigation de codebase.
Ce n'est pas une convergence coïncidente — c'est la forme que le problème t'impose. Une fois que t'as construit des sessions CLI agentiques qui ont besoin de faire de la recherche long-terme, de l'investigation de code, ou de la modification de fichiers en masse, tu frappes deux contraintes vite : le budget de contexte parent et le parallélisme. Les configs markdown plus YAML gèrent l'axe « comment cet agent devrait se comporter ». Les environnements isolés avec retours résumés gèrent l'axe budget de contexte. La délégation explicite via syntaxe de prompt garde le modèle de programmation simple pour les utilisateurs CLI qui veulent pas un framework d'orchestration complet. Gemini CLI qui atterrit cette primitive veut dire que le pattern est maintenant le standard industriel pour les outils de dev agentiques, pas une idiosyncrasie de Claude Code.
Si tu construis de l'outillage d'agent par-dessus l'un ou l'autre CLI, l'implication pratique est que tes configs de sous-agent peuvent être écrites une fois et presque-réutilisées à travers les deux. Les différences de schéma sont gérables ; le modèle mental est identique. À noter que les deux camps avertissent au sujet des sous-agents parallèles produisant des éditions en conflit, un problème résolu en théorie (contrôle de version, vérifier-avant-écrire, merge) mais un problème non résolu en UX. Celui qui crackera le flow « spawn cinq sous-agents éditant le même repo pis merge proprement » en premier aura un vrai différenciateur. D'ici là, la primitive convergente est là, pis ton playbook d'agent peut être écrit contre elle peu importe quel CLI ton équipe utilise.