La recherche en IA te passionne ?
Les papers et avancées qui comptent, expliqués simplement, chaque soir. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
Dans des workflows dopés aux LLM, le temps estimé passé à tester a à peu près doublé, tandis que la programmation recule. Pour tenir le rythme, une méthode est proposée: planifier finement, déclencher une vérification d’achèvement avec la commande /goal et confier aux agents des tests automatisés côté navigateur via Playwright MCP.
Les tests deviennent le goulet : charge accrue et codage en recul
Le temps estimé consacré aux tests a à peu près doublé, signe d’une charge de validation bien plus lourde. Avec des LLM qui écrivent du code, la part de tests augmente sensiblement, pendant que la programmation recule. Les tests sont présentés comme le nouveau goulet d’étranglement et la priorité devient d’en réduire la durée. Ce déplacement de charge libère par ailleurs du temps pour d’autres tâches, mais impose une organisation différente.
Automatiser la validation : Playwright MCP et agents au navigateur
Une configuration opérationnelle consiste à mettre Playwright MCP à disposition de tous les agents, dont Claude Code et Codex. Les agents peuvent alors lancer des serveurs en local et exercer des scénarios de test dans Chrome. Cette boucle leur permet de détecter eux-mêmes les erreurs introduites par leur propre code et de gagner beaucoup de temps. L’autonomie ainsi obtenue s’inscrit dans une logique plus large : réduire les interactions humaines en renforçant l’exécution automatique.
Anticiper les tâches pour limiter l’ambiguïté des agents
Davantage de temps est désormais investi en amont pour planifier le travail. Les tâches naissent le plus souvent d’un message de type retour produit ou bogue, ou s’inscrivent dans un projet en cours, puis font l’objet d’une préparation détaillée. Avant de déléguer aux agents, les ambiguïtés sont clarifiées autant que possible. À défaut, les agents reviennent rapidement avec des questions jugées coûteuses. Cette clarification s’obtient en réfléchissant au périmètre attendu ou en discutant avec un LLM pour faire émerger les zones d’ombre.
Assurer l’achèvement : /goal comme déclencheur de vérification
L’usage actif de la commande /goal est présenté comme un levier clé. Elle amorce chez l’agent une vérification de l’achèvement de la demande et, si nécessaire, l’incite à poursuivre jusqu’à correction complète. Il est rapporté que, récemment et notamment avec Opus 5, l’absence de /goal s’accompagne souvent d’un travail inachevé. La commande est présentée comme un correctif rapide en attendant mieux, une interprétation reliant ces manquements à une forme de paresse des agents.
Réallocation du temps : parts indiquées et nouvelles priorités
Des parts de temps sont avancées : 70% pour l’écriture de code, 30% pour l’interaction avec des agents, 10% pour les réunions — un niveau indiqué comme stable —, 30% pour les tests et 30% de temps supplémentaire pour d’autres tâches. Le temps supplémentaire débloqué est décrit comme une estimation, mobilisable pour se former, créer davantage d’agents ou accomplir plus de travail. Plus largement, l’arrivée des LLM est liée à une évolution profonde des pratiques de gestion de projet et à un besoin d’optimisations nouvelles. Les techniques proposées sont à adapter, avec l’invitation à les généraliser prudemment selon chaque domaine d’application.
