Tout ce que je savais sur le codage IA était faux

Le présentateur introduit le problème des frameworks d'IA pour le code (Beemad, Speckit) qui ne tiennent pas toujours leurs promesses. Il explique que l'échec n'est pas dû à de mauvaises méthodes, mais au fait que ces workflows préfabriqués ne correspondent pas aux cas d'usage spécifiques de chaque développeur. La solution consiste à créer ses propres workflows personnalisés adaptés au projet plutôt que de s'appuyer sur des solutions génériques. Pour y parvenir, il est nécessaire de comprendre certains principes fondamentaux que tous les frameworks utilisent d'une manière ou d'une autre.

La fenêtre de contexte représente la quantité d'informations que le modèle peut retenir simultanément en mémoire de travail. Les modèles Anthropic disposent de 200 000 tokens tandis que Gemini en a 1 million, mais ces chiffres ne sont pas aussi importants qu'ils le semblent. La fenêtre contient non seulement les prompts système et messages utilisateur, mais également les messages précédents, fichiers de mémoire, outils, appels MCP, etc. Gérer efficacement ce contexte est essentiellement ce que font les frameworks d'IA, et il faut apprendre à tirer le meilleur parti de cet espace de travail limité pour que le modèle fasse exactement ce qu'on attend de lui.

La divulgation progressive est le principe le plus important de la conception de workflow : ne révéler au LLM que ce qui compte maintenant plutôt que de remplir la fenêtre avec tout ce dont il pourrait avoir besoin plus tard. Les modèles avancés comme Sonnet 4.5 ont une fonctionnalité d'édition de contexte intégrée qui filtre automatiquement les informations superflues, mais cela ne suffit pas. Au lieu de demandes vagues comme "corriger l'erreur dans le backend", il vaut mieux demander de vérifier les endpoints un par un. Les compétences (skills) incarnent ce principe en fournissant juste assez d'informations pour que l'outil sache quand les utiliser sans tout charger dans le contexte, et elles doivent être utilisées pour tout sauf les données externes qui nécessitent des MCP.

Le deuxième principe clé stipule que les informations non nécessaires maintenant ne doivent pas se trouver dans la fenêtre de contexte. Les outils utilisent une prise de notes structurée dans des fichiers externes pour documenter décisions, problèmes et dette technique. Cette approche permet de maintenir le contexte critique lors de la construction de projets complexes, surtout quand le contexte se réinitialise via la compaction. Les agents peuvent consulter ces notes pour comprendre ce qui a été fait et ce qui reste à faire. Le fichier agent.md (ou claud.md selon l'outil) est un fichier de contexte standard que tous les agents lisent au démarrage de la session pour comprendre comment structurer et utiliser ces fichiers externes.

Les agents se mettent parfois en pause au hasard lors de tâches longues, généralement quand le contexte dépasse 70% de sa limite. C'est le concept de budget d'attention : au-delà de 70%, le modèle doit se concentrer davantage avec un risque accru d'hallucinations, ce qui empêche les agents d'utiliser leurs outils efficacement et les pousse à les ignorer. Pour résoudre ce problème, il faut utiliser la compaction qui permet au modèle de repartir à zéro avec un résumé approprié. Plutôt que d'attendre que la fenêtre atteigne 90% et déclenche la compaction automatique, il vaut mieux surveiller activement le contexte et le faire manuellement. Le rembobinage intégré de Claude permet aussi de supprimer les parties inutiles, et il faut démarrer une nouvelle fenêtre pour chaque nouvelle tâche.

Les sous-agents exécutent des tâches en arrière-plan dans leur propre fenêtre de contexte isolée sans polluer la fenêtre principale. Ils ne rapportent que la sortie finale à l'agent principal, ce qui est particulièrement utile pour des tâches isolées les unes des autres. La fenêtre de contexte principale reste protégée contre l'encombrement avec les appels d'outils et recherches effectués par le sous-agent. Ces agents s'exécutant en arrière-plan, on peut continuer à interagir avec l'agent principal sur des tâches nécessitant réellement notre attention. L'exemple donné est l'utilisation de sous-agents pour rechercher les règles d'un nouveau framework : leurs appels d'outils et recherches restent isolés et ils renvoient simplement la réponse à l'agent principal.

Les différents formats de fichiers affectent le nombre de tokens et donc l'efficacité du workflow. YAML est le plus efficace en tokens et convient pour les schémas de base de données, configurations de sécurité et détails d'API grâce à son indentation qui aide à structurer les informations. Markdown est meilleur pour la documentation comme claud.md car les niveaux de titres facilitent la navigation du modèle entre sections. XML est spécifiquement optimisé pour les modèles Claude car Anthropic les a affinés pour reconnaître ces balises comme conteneurs et séparateurs, utile pour sections distinctes comme contraintes, résumés ou détails visuels (les autres modèles préfèrent Markdown et YAML). JSON est le moins efficace à cause des accolades et guillemets supplémentaires, donc à utiliser seulement pour de petites choses comme les états de tâches.

Git est fondamental et peut être utilisé de manière innovante dans les workflows d'IA : l'historique des commits sert de rappel au modèle des progrès réalisés sur le projet ou une tâche. Les workflows d'ingénierie de contexte doivent être utilisés dans un dépôt git initialisé car ils impliquent que le modèle agit selon des étapes planifiées une par une plutôt que tout faire d'un coup. Git permet de contrôler vers quelle version revenir en cas de problème et d'évaluer quel changement cause des issues. Des personnes ont également implémenté le parallélisme avec les git worktrees, où des sous-agents travaillent dans des worktrees dédiés pour un travail en parallèle, ce qui a été montré dans de nombreux workflows présentés précédemment.

Il y aura toujours des cas où on répète des instructions pour des procédures courantes comme les commits git ou la mise à jour de documentation. Les outils d'IA proposent des moyens de réutiliser les prompts les plus répétés via des custom/commands qui donnent à Claude un guide réutilisable. L'exemple de la commande "catchup" contient des instructions sur la structuration de la mémoire hors contexte pour que Claude se mette à jour avec le projet sans lire chaque fichier. Les commands sont également efficaces pour faire respecter la structure : une "commit/command" suit une structure spécifique pour les messages de commit et les vérifications pré-commit à effectuer avant validation. Cela maintient tout standardisé sans avoir à réinstruire Claude constamment sur la manière préférée d'effectuer les tâches.

Les MCP doivent être utilisés uniquement quand des données externes sont requises, contrairement aux compétences pour les tâches internes. Jira est le logiciel de gestion d'équipe le plus utilisé et le MCP Jira permet d'accéder directement aux tickets pour implémenter des changements. De même, le MCP Figma fournit le guide de style de l'application que Claude utilise pour construire le design. Pour les tâches où les capacités intégrées du modèle sont insuffisantes, les MCP sont essentiels pour interagir efficacement avec des sources externes. Il est possible d'inclure ces MCP directement dans les /commands pour les intégrer à l'ensemble du workflow de manière cohérente.

Le présentateur conclut la vidéo en invitant les spectateurs à soutenir la chaîne pour continuer à créer des vidéos de ce type, notamment en utilisant le bouton super merci disponible sous la vidéo. Il remercie les spectateurs d'avoir regardé cette présentation des principes fondamentaux pour créer des workflows d'IA personnalisés efficaces. La vidéo se termine avec l'annonce du rendez-vous pour la prochaine vidéo, maintenant la continuité avec l'audience qui suit régulièrement le contenu de la chaîne.