Contexte technique
Je me suis intéressé à ce cas non pas à cause du drame autour des outils, mais à cause d'un schéma très familier : dès que l'automatisation par l'IA dans le développement devient trop verbeuse, le compteur de jetons explose et le contrôle humain diminue. Ici, c'est visible presque au microscope.
Le scénario est simple. La tâche est locale : passer la sauvegarde dans un dépôt Elasticsearch à l'API bulk. Le dépôt lui-même fait environ 500 lignes, plus un peu de code autour. Ensuite, Superpowers transforme cela en une spécification de 2700 lignes, avec des exemples de code, des tests, des questions, un rituel TDD et 14 commits en environ 2 heures.
Et c'est là que je ferais une pause. Non pas parce que le TDD est mauvais, mais parce que relire 2700 lignes pour un changement de taille moyenne n'est, pour le moins, pas un cadeau. Formellement, l'agent a fait un excellent travail ; en pratique, je paie maintenant non seulement en jetons, mais aussi avec l'attention de mon équipe.
Dans l'approche alternative, que l'utilisateur a décrite en utilisant les compétences de Matt Pocock et en passant à Codex, le rythme est différent : un plan court, une itération courte, la relecture du code final et la discussion des parties peu claires avec l'agent. Je trouve personnellement ce mode plus durable lorsqu'il faut garder l'architecture en main, plutôt que d'accepter une autre boîte noire soigneusement emballée.
Oui, de l'extérieur, cela semble plus lent que de lancer une grosse spécification et d'aller prendre un café. Mais en pratique, un contexte court est presque toujours moins cher, plus prévisible et s'intègre mieux dans un projet réel, où le code a déjà accumulé de l'histoire, des compromis et des bords étranges.
Un point important à part : il n'y a pas de benchmarks directs ici, et je ne prétendrais pas que c'est une vérité de laboratoire. Pour l'instant, ce sont principalement des observations d'utilisateurs solides, mais elles correspondent bien à ce que je vois dans les pipelines d'agents réels.
Ce que cela change pour l'entreprise et l'automatisation
Les équipes qui ont besoin d'un développement de solutions d'IA géré — et non d'un « pilote automatique à tout prix » — sont gagnantes ici : moins de contexte, des revues plus rapides, un coût par cycle plus faible. C'est particulièrement vrai là où des modifications fréquentes et sûres sont plus importantes qu'un agent manifestement autonome.
Les scénarios où un agent reçoit trop de liberté sur de petites tâches sont perdants. La minutie coûteuse annule les avantages, et un humain doit quand même vérifier le résultat.
Je le formulerais ainsi : une approche TDD verbeuse est bonne lorsque la tâche est vraiment grande et doit être formalisée presque comme un mini-projet. Pour le développement de produits au quotidien, les itérations compactes sont souvent tout simplement plus rentables.
Chez Nahornyi AI Lab, nous analysons précisément ces goulots d'étranglement dans les équipes : où un agent est nécessaire, où un bon cycle avec un contexte court est suffisant, et où l'architecture de l'IA a commencé à brûler le budget sans raison. Si vous avez une histoire similaire avec des agents coûteux et peu maniables, examinons ensemble votre processus et construisons une automatisation IA adaptée à votre flux de travail réel, et non à une belle démo.