Contexte et distinction modèle/agent
Le texte sépare clairement modèle (ex. GPT‑Astra, Claude Sonnet, GLM‑5.3) et agent (ex. Claude Code, OpenAI Codex). Le modèle génère du texte, dont le code, tandis que l’agent traduit ce texte en actions système : création de fichiers, exécution de tests, mise à jour du dépôt git. Cette architecture en deux couches explique pourquoi les performances du modèle ne se traduisent pas automatiquement en productivité : les goulets d’étranglement se situent dans le logiciel d’orchestration.
Gestion des tâches et parallélisation
L’auteur signale qu’un changement de 1,5 k lignes a été découpé en 10 sous‑tâches, mais que l’agent les exécute séquentiellement, alors que le matériel dispose de plusieurs cœurs. Cette approche contredit l’avantage inhérent du processeur, qui peut effectuer des commutations de contexte à la microseconde. De plus, l’agent attend la fin de tests end‑to‑end avant de générer le message de commit, introduisant des minutes d’inactivité. Le manque de parallélisme provient d’une logique d’attente bloquante dans le code de l’agent, qui ne crée pas de sous‑agents capables de travailler en parallèle de façon asynchrone.
Manque d’autonomie et de mémoire
Deux limites sont illustrées par des chiffres précis : lors d’une recherche de motif sur 50 000 lignes, l’agent persiste à utiliser le modèle le plus coûteux, même si une version plus légère aurait suffi. Inversement, il ne délègue jamais à un modèle plus performant, obligeant l’utilisateur à intervenir manuellement. Un autre exemple montre le téléchargement de 13 GB de fichiers pour activer une fonction jamais utilisée, alors que le même agent ne conserve même pas 50 KB de documentation interne. Cette asymétrie révèle une absence de cache de métadonnées et de mécanisme de sélection dynamique des modèles, ce qui alourdit le coût opérationnel et augmente le temps de latence.
Communication des plans et comportements d’attente
Le mode « Plan / Execute » est critiqué parce que les plans sont présentés comme un « hodgepodge de décisions de bas niveau », rendant la relecture fastidieuse. L’article cite un cas où l’agent s’arrête deux minutes après le lancement pour demander le nom d’une branche git, puis reste inactif toute la nuit en attente d’une réponse. Ce comportement indique que le moteur de décision de l’agent ne possède pas de timeout ou de stratégie de reprise, ce qui bloque le pipeline CI/CD. En l’absence de mémoire contextuelle, chaque interaction est traitée comme isolée, empêchant l’agent de capitaliser sur les réponses précédentes.
