Utiliser l'IA dans VS Code

VS Code avec l'IA semble sans effort jusqu'à ce que, pour la première fois, il fasse discrètement la mauvaise chose à grande échelle. Le danger, c'est que l'assistant prédit un code plausible, et plausible est exactement le genre qui passe un coup d'œil rapide et échoue en production.

Imaginez un développeur qui ouvre la vue Chat, tape « ajouter la mise en cache à la recherche d'utilisateur », et le laisse en mode agent avec les approbations terminales désactivées. L'agent décide que la solution la plus propre est une nouvelle bibliothèque de mise en cache, exécute npm install sur un package qu'il a choisi, modifie quatre fichiers et rapporte le succès. Le code compile. La construction est réussie. Deux jours plus tard, un collègue remarque que la nouvelle dépendance n'est pas maintenue, le cache ne s'invalide jamais, et la recherche renvoie maintenant des profils obsolètes après un changement de mot de passe. Rien de tout cela n'était visible sur le moment, car le développeur n'a rien approuvé et n'a rien lu. Ils ont traité la boucle de l'agent comme un distributeur automatique au lieu d'un junior qui a besoin d'une révision.

La leçon coûteuse ici est que l'éditeur n'a pas échoué. Il a fait exactement ce qu'on lui a dit, c'est-à-dire rien de particulier. Le contrôle qu'un développeur a dans VS Code est structurel, et il repose sur trois éléments : le contexte que vous chargez avant que l'assistant ne prédise, le mode que vous choisissez pour la taille du changement, et les diff et les commandes que vous lisez avant que quoi que ce soit ne soit conservé. Lorsque ces trois éléments sont utilisés, la même tâche devient un plan révisé, un petit diff, et un npm install refusé qui incite à une conversation sur la nécessité de la dépendance.

Cela compte plus en 2026 qu'il y a un an, car l'éditeur propose maintenant un réglage Autopilot qui répond automatiquement aux invites d'outils et continue de fonctionner jusqu'à ce que la tâche soit terminée. Plus l'agent peut se déplacer rapidement, plus le fardeau se déplace vers le réviseur. Le mécanisme qui vous permet de garder ce fardeau gérable est l'ensemble des modes et des approbations, que la section suivante décompose.

Deux systèmes distincts fonctionnent sous le même éditeur, et les confondre est la source de la plupart des frustrations. Nommer les parties rend le reste de la page concret.

• Complétions en ligne. Au fur et à mesure que vous tapez, un modèle de complétion rapide propose les prochaines lignes sous forme de texte fantôme gris. Il n'y a pas de boucle et pas d'utilisation d'outil. Vous acceptez avec Tab ou continuez à taper. C'est pour la vitesse de frappe à l'intérieur d'un fichier, et la seule révision est vos yeux avant d'appuyer sur Tab.
• La vue Chat. Un modèle de raisonnement qui lit le contexte, peut appeler des outils, et fonctionne dans une boucle à plusieurs étapes. C'est là que se déroulent les tâches réelles, et il a trois modes.
• Mode Demande. Répond aux questions et explique le code. Il n'édite jamais un fichier. Utilisez-le pour comprendre une fonction, une trace de pile, ou une bibliothèque avant de changer quoi que ce soit.
• Mode Édition. Vous nommez les fichiers et décrivez le changement. L'assistant propose des modifications sur ces fichiers et montre toujours un diff en premier, que vous appliquez ou rejetez. Utilisez-le pour un changement ciblé que vous pouvez déjà décrire précisément.
• Mode Agent. Vous donnez un objectif de haut niveau. L'agent trouve les fichiers lui-même, planifie les étapes, modifie le projet, exécute des commandes terminales, et itère lorsque quelque chose échoue. Utilisez-le pour des tâches où vous ne savez pas encore quels fichiers doivent être modifiés.

La distinction qui décide du succès est la portée. Le mode Édition vous garde en contrôle par construction, car il ne touche que les fichiers que vous avez nommés et vous attend sur chaque diff. Le mode Agent échange cela pour la portée : il peut découvrir les bons fichiers et corriger le code connexe auquel vous n'avez pas pensé, au prix d'une plus grande surface à réviser et de la capacité à exécuter des commandes. Une règle utile est de choisir le plus petit mode qui peut faire le travail. Un renommage est Édition. Un « connecter ce nouvel endpoint à travers le service, la route, et les tests » est Agent.

Le deuxième mécanisme est la porte d'approbation en mode agent. Les modifications de fichiers apparaissent sous forme de diff, et les commandes terminales s'arrêtent à une invite où vous choisissez d'autoriser une fois, d'autoriser pour cette session, ou de refuser. Vous pouvez élargir cela avec le paramètre chat.tools.terminal.autoApprove, un objet qui associe les noms de commande ou les clés /regex/ à vrai ou faux, de sorte que les commandes sûres en lecture seule (git status, npm test) sautent l'invite tandis que tout ce qui ne correspond pas s'arrête toujours pour confirmation. Définir le booléen global chat.tools.global.autoApprove à vrai ouvre la porte à tous les outils à la fois. Le niveau Autopilot 2026 va plus loin et répond automatiquement aux invites pour fonctionner sans interruption. Chaque étape que vous faites vers l'auto-approbation est un pas loin de la révision, alors élargissez la porte étroitement et uniquement pour les commandes que vous auriez approuvées de toute façon.

Le troisième mécanisme est le contexte. L'assistant prédit à partir de ce qui se trouve dans sa fenêtre, donc un AGENTS.md versionné à la racine du dépôt, lu à chaque demande, est la façon dont vos conventions l'atteignent sans que vous ayez à les retaper. Les fichiers *.instructions.md à portée de chemin s'appliquent uniquement là où leur glob applyTo correspond. Avec ces parties nommées, la section suivante parcourt une tâche à travers les trois leviers de bout en bout.

Maya, une développeuse dans une équipe de paiement, doit ajouter une validation côté serveur au formulaire d'inscription pour que deux champs, courriel et code de référence, soient vérifiés avant la création du compte. Elle ne connaît pas encore tous les fichiers impliqués, donc c'est une tâche d'agent, et elle l'exécute délibérément.

1. Charger le contexte d'abord. Le dépôt a déjà un AGENTS.md à la racine avec la stack (TypeScript, React, Vitest), la commande de test (npm test), et une règle qui dit pas de nouvelles dépendances sans demander. Parce que le fichier est lu à chaque demande de chat, Maya n'a pas à répéter quoi que ce soit.
2. Demander un plan, pas un correctif. Elle passe à un agent personnalisé Planner, une persona .agent.md limitée aux outils en lecture seule, et écrit un prompt : « Planifier la validation côté serveur pour le formulaire d'inscription. Le courriel doit être un format valide et unique ; le code de référence doit exister et être inutilisé. Lister les fichiers que vous toucherez et les tests que vous ajouterez. Ne pas écrire de code pour l'instant. » L'agent retourne un plan en six étapes nommant signup.controller.ts, un nouveau validators/referral.ts, et deux fichiers de test.
3. Corriger le plan. Le plan propose une nouvelle bibliothèque de validation. Maya rejette cette ligne, car AGENTS.md interdit les nouvelles dépendances, et lui dit d'utiliser le schéma zod existant déjà dans le dépôt. Corriger une phrase dans un plan est bien moins coûteux que de défaire un package installé plus tard.
4. Passer à l'agent. Elle passe en mode Agent et dit « Implémentez le plan corrigé. » L'agent modifie trois fichiers et écrit les tests.
5. Réviser le diff et les commandes. Le changement est d'environ 80 lignes, suffisamment petit pour être lu ligne par ligne. Lorsque l'agent atteint npm test à l'invite terminale, elle choisit d'autoriser pour cette session, car les tests sont sûrs à relancer. Elle n'active pas l'autoApprove global.
6. Vérifier le comportement. Les tests passent, mais Maya soumet manuellement un courriel en double dans l'application en cours d'exécution pour confirmer que la vérification d'unicité fonctionne, car une suite de tests verte ne prouve que ce que les tests affirment.

L'ensemble de la tâche a pris une courte révision de plan, une lecture de diff de 80 lignes, et une approbation de commande ciblée. Comparez cela à l'histoire d'ouverture : même objectif, mais révisé à chaque levier au lieu de rien. Maya continue dans la section suivante, où le même flux de travail rencontre les pièges qui le font glisser.

Chacun de ces pièges semble être un progrès sur le moment tout en annulant discrètement le contrôle que les modes sont censés vous donner.

• Accepter avec Tab par réflexe. Les longues complétions de texte fantôme sont faciles à accepter sans lire, donc les suppositions s'accumulent dans un fichier. La solution est de traiter Tab comme une décision : lisez la suggestion, et rejetez-la dès qu'elle diverge de ce que vous aviez prévu. Les complétions sont pour la vitesse de frappe, pas pour la conception.
• AutoApprove global. Définir chat.tools.global.autoApprove à vrai, ou exécuter Autopilot, supprime l'unique endroit où vous voyez ce que l'agent exécute. La solution est un objet chat.tools.terminal.autoApprove à portée qui ne liste que les commandes sûres en lecture seule, donc les invites apparaissent toujours pour les commandes qui peuvent changer ou détruire l'état.
• Mode Agent pour une ligne. Utiliser Agent pour un renommage ou une petite modification transforme un changement chirurgical en un diff tentaculaire qui prend plus de temps à réviser qu'à écrire. La solution est de par défaut utiliser le mode Édition et d'escalader à Agent uniquement lorsque vous ne pouvez pas nommer les fichiers vous-même.
• Pas de fichier d'instructions. Sans un AGENTS.md, l'agent devine à nouveau vos conventions à chaque tâche et s'écarte du style du projet. La solution est un fichier court versionné à la racine, pas un long, car un fichier ciblé que le modèle lit réellement vaut mieux qu'un exhaustif qu'il ignore.

Deux véritables cas limites se situent au-delà des règles simples. La dépendance hallucinée. Les agents importent parfois ou installent un package qui n'existe pas ou est abandonné, et environ un échantillon de code IA sur cinq fait référence à une dépendance qui n'est pas réelle. La règle AGENTS.md de Maya et son installation refusée sont la garde, puisque l'invite d'approbation est précisément l'endroit où un npm install inventé devient visible. Traitez toute nouvelle dépendance que l'agent propose comme une affirmation à vérifier, pas un fait.

Le grand diff qui submerge la révision. En 2026, la contrainte est la capacité de révision, pas la vitesse à laquelle le code peut être généré. Un agent peut produire un changement de 600 lignes en une minute que personne ne peut lire de manière significative. La gestion consiste à limiter les tâches pour que le diff reste petit, et à demander à l'assistant « quelles hypothèses ce code fait-il, et sont-elles sûres ? » plutôt que « cela semble-t-il raisonnable ? ». Un plan révisé à l'avance garde le diff éventuel à une taille qu'un humain peut réellement gérer. Ces habitudes deviennent plus difficiles lorsque plus d'une personne partage le dépôt, c'est là que l'échelle entre en jeu.

Un développeur peut garder ses propres conventions en tête. Dès qu'un dépôt a plusieurs contributeurs et un agent générant des changements, la pratique doit vivre dans des fichiers versionnés et une habitude de révision partagée, sinon elle cesse discrètement de se produire.

L'artéfact durable est le fichier d'instructions sous contrôle de version. Un seul AGENTS.md à la racine porte les conventions que chaque contributeur et chaque agent doit suivre, et parce qu'il est reconnu par plusieurs outils d'IA, le même fichier fonctionne qu'un coéquipier utilise Copilot ou un autre assistant. Pour un monorepo, les fichiers *.instructions.md à portée de chemin sous .github/instructions/ avec un glob applyTo permettent au dossier backend et au dossier frontend d'avoir des règles différentes. Une responsable, appelons-la Priya, possède ces fichiers de la même manière qu'elle possède la configuration de lint : ils sont révisés dans les pull requests et changent au fur et à mesure que le projet évolue.

Le deuxième artéfact d'équipe est une convention de pull request qui enregistre le rôle de l'IA. Lorsqu'un changement provient du mode agent, la description du PR le nomme et inclut le prompt ou le plan, afin qu'un réviseur sache quoi examiner. Ce n'est pas de la bureaucratie. Cela indique au réviseur s'il lit du code qu'un humain a raisonné ligne par ligne ou du code qu'un agent a généré à partir d'un objectif d'une ligne, et le second mérite des questions plus difficiles.

Le troisième est une limite de taille. Garder les pull requests sous environ 400 lignes est la pratique de révision la plus efficace, et cela corrèle avec des cycles de révision matériellement plus rapides. L'IA rend les grands diff bon marché à produire, ce qui rend la limite plus importante, pas moins. L'équipe de Priya traite un diff d'agent de 600 lignes comme un signal pour diviser la tâche, pas comme une raison de survoler.

Le principe durable à garder, quelle que soit la taille de l'équipe : l'assistant prédit une sortie plausible, et vos trois leviers sont le contexte que vous chargez, le plan que vous acceptez avant qu'il n'écrive, et le diff et les commandes que vous révisez avant de conserver quoi que ce soit. Commencez par une petite chose. Ajoutez un AGENTS.md à un dépôt cette semaine, privilégiez le mode Édition sur Agent, et n'élargissez les approbations terminales que lorsque vous faites confiance à la boucle.